ES0.10 Attacker Perspective: What the Adversary Sees

· Module 0 · Free

Operational Objective

A skilled attacker's first action on a compromised endpoint is not to deploy malware — it is to assess the endpoint security posture. What AV is running? What version? Are ASR rules active? Is EDR present? What logging is configured? This reconnaissance takes seconds and determines the attacker's next move: proceed with standard tradecraft, switch to evasion techniques, pivot to a less protected system, or abort. Understanding what the attacker checks — and what they conclude from your configuration — turns the endpoint security assessment from a compliance exercise into an adversarial one. You are not configuring controls to satisfy an auditor. You are configuring controls to present the attacker with the most hostile environment possible, forcing them to use noisier techniques that increase the probability of detection.

Deliverable: Understanding of the attacker's endpoint reconnaissance methodology, the specific configuration checks attackers perform after initial access, and how each endpoint security control changes the attacker's cost-benefit calculation.

Estimated completion: 25 minutes

Figure ES0.10 — The attacker's first 60 seconds on a compromised endpoint. Four checks determine the attack path: AV/EDR presence, ASR enforcement state, logging configuration, and credential protection. Each "no protection" result simplifies the attacker's next step. Each "protected" result forces the attacker to use noisier, more detectable alternatives.

The attacker’s cost-benefit calculation

Attackers are rational operators. Every technique has a cost (complexity, time, noise generated, risk of detection) and a benefit (capability gained, objective advanced). The endpoint security configuration directly affects this calculation.

On an endpoint with default Defender settings, no ASR rules, no Credential Guard, and no Sysmon, the attacker’s cost-benefit calculation is straightforward: use standard tools (Mimikatz, Cobalt Strike default configs, PowerShell Empire) with minimal modification. The cost is low because the defense is low. The risk of detection is moderate — MDE’s built-in detections may catch known tool signatures, but default cloud protection and the absence of custom detections leave significant gaps.

On an endpoint with ASR rules in block mode, Credential Guard enabled, Sysmon deployed, and custom detection rules in MDE, the calculation changes dramatically. Standard tools fail — Mimikatz cannot access LSASS because the ASR rule blocks it and Credential Guard isolates the secrets. The attacker must use alternative credential access techniques (token theft, Kerberoasting, DCSync from a remote system) which are more complex and generate more detectable artifacts. The AMSI bypass required to execute obfuscated PowerShell generates its own detection opportunity. The process injection required to evade EDR’s userland hooks generates Sysmon Event ID 8 (CreateRemoteThread) and Event ID 10 (ProcessAccess). Every workaround the attacker uses to bypass a security control creates a new detection opportunity.

This is the principle that underlies the adversary-aware approach in this course: every defensive control you deploy does not just prevent one technique — it forces the attacker to use an alternative technique that creates additional detection opportunities. The layered stack multiplies detection surface.

Expand for Deeper Context

The reconnaissance commands attackers use are worth knowing because they reveal what the attacker values:

Get-MpComputerStatus reveals: AV engine version, signature version, real-time protection state, behavior monitoring state, AMSI status, tamper protection status, and cloud protection level. An attacker who sees tamper protection enabled knows they cannot disable Defender without Microsoft’s cloud service detecting the attempt. An attacker who sees cloud protection at default knows that a newly generated binary has a better chance of passing cloud analysis than against High+ or Zero Tolerance.

Get-MpPreference | select AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions reveals the exact ASR configuration. Each rule ID maps to a specific technique. The attacker reads this output and knows exactly which techniques will be blocked (action = 1), which will be logged but not blocked (action = 2), and which are not configured (absent from the list). An ASR configuration where all rules show action = 2 (audit) tells the attacker: “all of these techniques will work, they will just generate a log entry that someone may or may not read.”

sc query Sysmon64 or checking for the Sysmon service reveals whether enhanced logging is present. Sysmon’s presence does not block the attacker, but it significantly increases the evidence trail. An attacker who sees Sysmon deployed knows that process creation (Event ID 1), network connections (Event ID 3), and process access (Event ID 10) are being recorded with full command-line detail. This changes operational decisions: the attacker may choose to inject into an existing process rather than creating a new one, or use less suspicious-looking command lines.

How each control changes the attacker’s path

ASR LSASS rule in block mode → The attacker cannot dump LSASS memory using comsvcs.dll, Procdump, or other tools that open a handle to the LSASS process. Alternatives: Kerberoasting (request TGS tickets for service accounts and crack offline — generates Kerberos event 4769 with encryption type 0x17), DCSync from a remote system (requires domain admin — generates Directory Service Access event 4662), or token theft from running processes (does not require LSASS access but provides limited credentials). Each alternative is more complex, more detectable, and provides less comprehensive credential access than a simple LSASS dump.

Credential Guard enabled → Even if the attacker bypasses the ASR rule and dumps LSASS, the NTLM hashes and Kerberos tickets are not present in LSASS memory — they are isolated in a virtualization-based security container. The dump returns an empty or partial result. Alternatives: attack the VBS container (extremely difficult, requires kernel-level exploitation), use pass-the-ticket with existing tickets obtained through other means, or target credentials stored outside of LSASS (cached credentials in the registry, credential manager vault). Each alternative significantly raises the bar.

Sysmon deployed → The attacker’s operations generate detailed telemetry that persists in the event log. Process creation with full command-line detail (Event ID 1), network connections with source and destination (Event ID 3), registry modifications (Event ID 12/13), file creation (Event ID 11), and process access (Event ID 10, which catches injection attempts). The attacker can attempt to clear Sysmon logs — but the clearing attempt itself generates an event (Event ID 104 in System log, or Sysmon Event ID 23 for file deletion if configured), and if events are forwarded to Sentinel, the cleared events already exist in the SIEM.

The attacker’s first 5 minutes on an endpoint

When an attacker gains initial access to an endpoint (through a phishing attachment, a browser exploit, or stolen credentials), their first actions follow a predictable sequence that directly maps to the endpoint security controls from this course:

Minute 1: Environment assessment. The attacker checks: what AV is running? (Get-MpComputerStatus or checking for MsMpEng.exe in the process list). Is it Defender or third-party? Is real-time protection enabled? Is cloud protection at default or enhanced? The answer determines whether the attacker proceeds with their existing tooling or needs to modify their approach. An endpoint with default Defender AV is a softer target than one with High+ cloud protection and behavioral monitoring.

Minute 2: EDR check. The attacker checks for EDR agents: MsSense.exe (MDE), CsFalconService.exe (CrowdStrike), SentinelAgent.exe (SentinelOne), or cb.exe (Carbon Black). The presence of an EDR agent means every process the attacker runs, every network connection they make, and every file they create is being recorded. The attacker’s options: operate quickly and accept detection (smash-and-grab), use evasion techniques to blind the EDR (ES12), or pivot to a device without EDR (which is why 100% onboarding from ES2 matters).

Minute 3: Privilege assessment. The attacker checks their current privilege level: are they running as a standard user or local admin? whoami /priv reveals their token privileges. Standard user access limits the attacker to user-context operations — no LSASS access, no service installation, no driver loading. Local admin access opens the full attack path. This is why LAPS (ES11.10) matters: if the local admin password is unique to this device, the attacker cannot reuse it on other endpoints.

Minute 4: Logging check. The attacker checks what logging is configured: is PowerShell ScriptBlock logging enabled? (Get-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging). Is Sysmon installed? (Get-Service Sysmon64). Are advanced audit policies configured? The answers determine whether the attacker’s subsequent actions will be recorded in detail or leave minimal evidence.

Minute 5: Proceed or pivot. Based on the assessment: if the endpoint has full EDR + High+ AV + Sysmon + ScriptBlock logging + standard user context, the attacker is in a hostile environment where every action is monitored. They either use sophisticated evasion (costly, slower, higher risk of detection) or pivot to a less-protected endpoint. If the endpoint has default AV + no EDR + no logging + local admin, the attacker operates freely. The endpoint security architecture from this course makes every endpoint the hostile environment that forces the attacker to pivot, evade, or accept detection.

Decision Point

You discover that an attacker on your network is checking ASR rule states on compromised endpoints. This means they are adapting their techniques to your specific configuration. Is this a reason to hide your ASR configuration? No. The attacker can determine ASR state by testing techniques — attempting an Office→PowerShell execution reveals the block in real time. Hiding the configuration does not prevent reconnaissance; it only delays it by seconds. The correct response: ensure the ASR rules are in block mode (not just audit), so the reconnaissance reveals an actively hostile environment. The attacker’s check should return results that force them into noisier alternatives, not results that confirm their standard tools will work.

Try it: perform the attacker's reconnaissance on your own endpoint

Run these commands on a test endpoint (not in production during business hours — some may trigger alerts if your EDR is well-configured, which is a good sign):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# Check AV/EDR status
Get-MpComputerStatus | Select-Object AMRunningMode, RealTimeProtectionEnabled, BehaviorMonitorEnabled, IoavProtectionEnabled, AntivirusEnabled, AMServiceEnabled

# Check cloud protection level
Get-MpPreference | Select-Object CloudBlockLevel, CloudExtendedTimeout

# Check ASR rule states
Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions

# Check for Sysmon
Get-Service Sysmon64 -ErrorAction SilentlyContinue | Select-Object Status

# Check LSASS protection (RunAsPPL)
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL" -ErrorAction SilentlyContinue

# Check Credential Guard
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object SecurityServicesRunning

Read the output as the attacker would. For each “not configured” or “default” result, identify the attack technique it enables. For each “configured” or “enabled” result, identify the alternative technique the attacker must use and the detection opportunity that alternative creates. This exercise builds the adversary-aware mindset that this course applies to every security control.

Compliance Myth: "Attackers do not check endpoint security configuration — they just run their tools"

The myth: Attacker tradecraft is automated. They do not manually assess each endpoint before proceeding.

The reality: Commodity malware does not check — it runs and either succeeds or fails. But human-operated attacks (ransomware operators, nation-state actors, red teams) absolutely check the endpoint security posture before deploying their primary tooling. Publicly documented post-exploitation frameworks (Cobalt Strike, Sliver, Brute Ratel) include built-in commands for AV enumeration and evasion assessment. Ransomware operator playbooks (leaked from Conti, LockBit, BlackBasta) explicitly include endpoint security assessment steps. The attacker who checks your configuration and adapts is more dangerous than the automated malware that blindly runs — and it is the attacker your configuration must be designed to frustrate.

Troubleshooting

“If the attacker can see our ASR configuration, what is the point of ASR?” ASR rules are not security through obscurity. They are active prevention. An attacker who discovers LSASS ASR protection in block mode cannot bypass it by knowing it exists — they must use a different technique entirely. Knowing the rule exists tells them they need an alternative. Having to use an alternative costs them time, complexity, and generates detectable artifacts. The point of ASR is not to hide your defenses — it is to force the attacker into worse options.

“Should we block the reconnaissance commands themselves?” Generally no. Get-MpComputerStatus and Get-MpPreference are legitimate PowerShell commands that administrators use daily. Blocking them would impair administration. The better approach: create custom detection rules that alert when these commands are executed in suspicious contexts (e.g., executed by a process spawned from Office, or executed immediately after a new process is created from a suspicious parent chain).

Operational Artifact — Adversary Reconnaissance to Defense Control Mapping

For each attacker reconnaissance check, document: the command used, what the attacker learns, the defensive response (what you want the result to show), and the detection opportunity (can you alert when this command is executed in a suspicious context?). AV/EDR check → ensure tamper protection active + cloud protection High+. ASR check → ensure rules in block mode, not audit. Logging check → ensure Sysmon present + audit policies configured. Credential check → ensure LSASS protection + Credential Guard + LAPS. Each “protected” result the attacker sees is a technique they cannot use — which is a technique you do not need to detect.

An attacker compromises an NE endpoint and runs Get-MpPreference. The output shows all ASR rules in audit mode (action = 2). What does this tell the attacker, and how does it change their operations?

The attacker sees ASR is active and assumes their techniques will be blocked — they switch to more evasive tools immediately.

The attacker sees that all ASR rules are in audit mode, which means every technique those rules would block will succeed. Audit mode generates log entries but does not prevent execution. The attacker knows they can use Office→PowerShell chains, dump LSASS directly, use WMI for persistence, and abuse LOLBins without any ASR prevention. The audit logs are being generated — but the attacker bets (usually correctly) that nobody is actively monitoring ASR audit events in real time. The operational impact: the attacker proceeds with standard tradecraft, no evasion required, no additional noise generated. This is worse than having no ASR rules at all in one sense — the organisation invested time configuring audit mode but gets zero prevention value while potentially having a false sense of security from the audit data.

The attacker cannot tell the difference between audit mode and block mode from the Get-MpPreference output — they must test each technique individually.

The attacker sees audit mode and assumes the security team is actively monitoring — they abort the operation to avoid detection.

You're reading the free modules of this course

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus

← Previous Next →