Chapter 95 · Tricks

Endpoint Security — Exam Tricks

Four high-yield patterns: selecting the correct NAC agent type from scenario keywords, distinguishing EDR from traditional AV on the key behavioral-vs-signature axis, identifying XDR from cross-domain correlation language, and recognizing UBA as the answer when legitimate credentials perform anomalous actions.

Trick 1 Three NAC Agent Types — Three Scenario Keywords

The exam describes a device access scenario and asks which NAC agent type to use. The answer is determined entirely by two keywords in the scenario: who owns the device and whether software can be installed.

  • Corporate-managed device, software installation permittedPersistent agent. Permanently installed, continuously monitors, receives updates.
  • Guest, contractor, BYOD, or “no software installation allowed”Dissolvable agent. Downloaded at login, runs without installation, self-terminates when session ends.
  • Active Directory environment, assessment only at login/logoffAgentless NAC. No agent at all; uses AD integration. Cannot assess non-domain devices or check real-time process state.

Common distractors to reject:

  • “EDR agent” as an answer to a posture assessment question — EDR is a behavioral monitoring tool, not a NAC posture assessment mechanism. Wrong category entirely.
  • Agentless NAC for contractors — contractors are typically not in the corporate AD, so agentless NAC cannot assess them at all.
  • Persistent agent for guest devices — guest devices cannot have software permanently installed by the host organization.
Rule: Managed device = persistent. No install allowed = dissolvable. AD-only environment = agentless. Match device ownership to agent type.
Trick 2 EDR vs. Antivirus — Behavioral vs. Signature Is the Only Axis That Matters

The exam will present a scenario where traditional antivirus did NOT detect an attack and ask what technology would have. The answer structure is always the same:

  • New malware binary, no prior signature → AV fails (no signature) → EDR succeeds (behavioral analysis + ML detect the behavior)
  • Fileless attack in memory (no file written to disk) → AV fails (nothing to scan) → EDR succeeds (monitors memory and process behavior)
  • Polymorphic malware (changes signature each run) → AV fails (signature never matches) → EDR succeeds (behavior remains consistent even if binary changes)
  • Office macro spawning a shell process → AV fails (macro is in a legitimate document) → EDR succeeds (abnormal parent-child process relationship is detectable)

Key EDR capability question mappings:

  • “How did the attacker get in and what exactly did they do?” → Root cause analysis
  • “Ransomware encrypted files; restore them automatically” → Automated rollback (VSS snapshots)
  • “Isolate the infected endpoint immediately” → Automated isolation
  • “Trigger a SOAR playbook when EDR detects a threat” → API-driven response
Rule: AV = signature (known threats only). EDR = behavior + ML (known AND unknown threats). Any question where AV failed or where a novel attack must be detected = EDR.
Trick 3 XDR — Look for Cross-Domain Language

The exam will use specific language patterns that signal XDR is the answer. The signal is always some combination of multiple security domains being mentioned together in the same detection or investigation context:

  • Endpoint + network + cloud mentioned together → XDR correlates all three domains
  • “Unified view”, “single pane of glass”, or “single platform” covering multiple tool types → XDR
  • Multi-stage attack spanning email, endpoint, lateral movement, cloud storage → XDR detects the connected chain; no single tool would see all stages
  • “Reduces false positives by correlating context across tools” → XDR (context from multiple domains validates or dismisses single-domain alerts)

XDR vs. SIEM distinction (the exam may offer both):

  • SIEM also collects multi-source logs — but SIEM relies on manually written correlation rules, requires analyst effort to connect cross-domain events, and is primarily a log aggregation and alerting platform.
  • XDR natively integrates with security tools, automatically correlates cross-domain events, and provides automated response capabilities — not just alerting.
  • Exam language: “automatically correlates”, “natively integrated”, “cross-domain detection” = XDR. “Aggregates logs”, “correlation rules”, “analyst reviews alerts” = SIEM.
Rule: XDR = EDR + network + cloud + identity in one platform with automated cross-domain correlation. If the scenario mentions multiple security domains being correlated automatically, the answer is XDR.
Trick 4 UBA — The Answer When Credentials Are Valid but Behavior Is Wrong

The exam uses UBA in scenarios where all traditional controls have been bypassed because the attacker is using legitimate credentials or a legitimate user is behaving badly. The trigger is: no rule was broken, no signature was matched, but something is clearly wrong.

  • “Impossible travel” — same account authenticated from two countries within minutes → UBA detects the physical impossibility
  • Unusual access volume — user accessed 10× more files than normal average → UBA detects statistical anomaly
  • After-hours access — account that works 9–5 connects at 3 AM → UBA detects time-of-day deviation
  • New resource access — user accesses a database or server they have never touched before → UBA detects scope expansion
  • Service account interactive login — an account that never generates interactive sessions authenticates to a workstation → UBA detects account type behavioral mismatch

Why UBA is the answer for insider threat and credential theft: Both involve an account with valid permissions performing actions those permissions technically allow. No ACL is violated. No malware signature fires. No rule is broken. Only a deviation from established behavioral baseline is visible — which is exactly what UBA monitors.

Rule: Legitimate credentials + anomalous behavior = UBA. If the scenario says “no alert was triggered but the activity looks wrong” and uses valid credentials, UBA is the detection technology that catches it.
Practice Scenarios
Scenario A: A mid-size company has three access requirements to address simultaneously: (1) corporate laptops must be continuously assessed for patch compliance and AV status; (2) visiting vendors plug personal laptops into a guest network port and need a one-time posture check before internet access is granted; (3) internal managed desktops are all domain-joined and only need to verify domain membership at login time. Which NAC agent type should be deployed for each scenario, and why?
Answer: Scenario 1 — corporate laptops: Persistent agent. The organization manages these devices and can install software on them. A persistent agent continuously monitors patch compliance and AV status, providing real-time health data and receiving ongoing policy updates from the NAC server. It performs both initial access assessment and ongoing compliance monitoring, which is what “continuously assessed” requires. Scenario 2 — visiting vendors with personal laptops: Dissolvable agent. The organization cannot install permanent software on vendor-owned devices. A dissolvable agent is downloaded through a browser redirect when the vendor connects. It runs without installation, checks basic posture requirements (OS patch level, firewall status), and self-terminates when the session ends. Nothing is left on the device. Scenario 3 — internal domain-joined desktops: Agentless NAC. All devices are in Active Directory, and assessment only needs to verify domain membership at login and logoff. Agentless NAC integrates with AD to perform this check without installing any agent software. This is the most operationally simple solution for a fully managed, domain-joined environment where deep health inspection is handled by Group Policy rather than the NAC agent.
Scenario B: A healthcare organization’s EDR platform generates an alert: the medical records application (medrecords.exe) spawned PowerShell, which executed an obfuscated script that contacted an external IP address, created a new local admin account, and modified the Windows registry for persistence. Antivirus reported nothing suspicious. Describe what EDR capabilities are involved in detecting this attack, what the automated response steps should be, and what information root cause analysis would provide to the incident response team.
Answer: Detection: EDR behavioral analysis and machine learning identified the attack. The abnormal parent-child process relationship (medrecords.exe spawning PowerShell) is a high-confidence indicator of compromise regardless of signature — a medical records application has no legitimate reason to execute PowerShell. The ML model recognized the combination of obfuscated script execution, outbound connection to an external IP, local admin account creation, and registry modification as a multi-step attack pattern consistent with known attacker techniques (initial execution + persistence). Because the detection is behavior-based, no prior signature of this specific script was needed. Automated response: EDR should trigger (1) automated isolation of the endpoint from the network at the OS level to prevent lateral movement and further C2 communication, while retaining the management channel so the EDR console remains accessible; (2) automated quarantine of any malicious files identified during the attack sequence, preserving them for forensic analysis; (3) API-driven alerting to the SIEM and ticketing system to open a priority incident. The new local admin account and registry persistence key should be flagged for manual review and remediation. Root cause analysis findings: The IR team receives a complete timeline showing: medrecords.exe was the parent process; it received input (possibly from a crafted patient record or a vulnerable field in the application); PowerShell was spawned with specific arguments; the obfuscated script decoded and executed; a C2 connection was established; a new local admin account was created with a specific name; a specific registry key was modified at a specific path for persistence. This allows the team to answer: when did the attack begin, what is the exact scope of compromise, was any patient data accessed or exfiltrated, is this a vulnerability in the medrecords application or an exploitation of credentials, and what remediation steps are needed beyond this single endpoint.
Scenario C: A financial institution’s UBA platform generates a high-severity alert for a senior analyst account. The alert notes: the account authenticated from London at 9 AM GMT; the same account authenticated from New York at 9:45 AM GMT; the account then accessed the trading database (never accessed before by this account); downloaded 4.2 GB of data (historical average: 180 MB per month); and connected to a cloud storage service not on the approved list. No antivirus alert, no firewall rule violation, and no access control denial occurred. What does UBA conclude, why did no other tool alert, and what should the security team do?
Answer: UBA conclusion: The account is exhibiting multiple simultaneous anomalies that strongly indicate credential theft. Impossible travel (London to New York in 45 minutes is physically impossible) is the highest-confidence indicator — the legitimate user and an attacker using stolen credentials cannot both be logged in from different countries at the same time. The trading database access, extreme data volume (4.2 GB vs. 180 MB historical average = 23× normal), and connection to an unauthorized cloud service are consistent with data staging and exfiltration. UBA flags this as a high-severity insider threat or credential compromise incident. Why no other tool alerted: The account has valid credentials and valid permissions to authenticate, access network resources, and connect to cloud services (even though this specific service is not approved). No ACL was violated because the trading database permissions may exist for this account tier. No malware signature fired because the attacker used legitimate tools (browser, OS file transfer). No firewall rule was violated because the cloud service uses HTTPS on port 443, which is typically allowed. Traditional rule-based controls require a specific prohibited action; UBA detects the deviation from established behavioral normal regardless of whether individual actions are technically permitted. Security team response: (1) Immediately disable the account pending investigation. (2) Invalidate all active sessions for the account across all systems and cloud services. (3) Notify the legitimate user through an out-of-band channel (phone) to confirm whether they are in London or New York and whether they recognize the activity. (4) Preserve forensic evidence: capture the cloud storage destination, the full list of downloaded files, the authentication logs showing both source IPs, and the trading database query history. (5) Investigate how credentials were compromised (phishing, credential stuffing, malware on a personal device). (6) Review what data was staged and whether it left the organization through the unauthorized cloud service.