What Is a Compromise Assessment?

A vulnerability scan asks whether your patch is missing. A compromise assessment asks whether someone already used the missing patch to get in. The difference is the whole job. One grades what could go wrong; the other assumes something already did and goes looking for the intruder who exploited it. You run a compromise assessment when you have no specific alert but a real reason to doubt that "no alerts" means "no attacker": after a peer in your industry gets breached by a group that may have hit you too, before an acquisition closes, when a supplier discloses that credentials touching your environment leaked, or simply because the median attacker sits inside undetected long enough that silence proves nothing.

A compromise assessment is a structured, evidence-driven hunt across an environment for signs of past or present unauthorized access. It collects the telemetry that records what actually happened (endpoint data, network traffic, authentication events, and logs), then searches it for indicators of compromise and attacker behavior that monitoring missed or never had a rule for. This guide covers what the assessment inspects, the four-phase process from collection to advice, the attacker behaviors it hunts for, how it differs from threat hunting and an incident response engagement, and what the deliverable tells a defender. It is written for the SOC analysts, threat hunters, and DFIR teams who run these and inherit their findings. For cloud-specific scope, see the dedicated cloud compromise assessment.

What is a compromise assessment?

A compromise assessment is a point-in-time investigation that assumes breach and looks for proof, rather than assuming safety and looking for weakness. Its question is narrow and uncomfortable: is there evidence that an unauthorized actor has accessed, persisted in, or moved through this environment, now or in the recent past? It does not grade your controls against a benchmark. It reads the record those controls left behind and decides whether that record shows an intruder.

The distinction from a vulnerability assessment or penetration test is the point. Those are forward-looking and preventive: they find the weakness an attacker could use. A compromise assessment is backward-looking and investigative: it checks whether anyone already used the weakness, and what they did once inside. The two are complementary, and a mature program runs both, but they answer different questions and produce different deliverables.

The reason this matters is dwell time. An attacker who gets in does not announce it; they sit quietly, escalate, establish persistence, and move toward whatever they came for, often for weeks before anyone notices, if anyone notices at all. A compromise assessment is the deliberate check that shortens that window when monitoring has not. CISA recommends compromise assessments as a baseline practice for exactly this reason: the absence of an alert is not the same as the absence of an adversary.

What a compromise assessment inspects

The value is in correlating sources, not in any single log. An intrusion rarely shows up as one obvious event; it shows up as an unusual login followed by a new scheduled task followed by an outbound connection to infrastructure no one recognizes. So the assessment pulls every relevant telemetry source and looks for the story they tell together.

Endpoint and host data. The system of record for what ran where. Process execution, command-line arguments, service and scheduled-task creation, registry and startup changes, and on-disk artifacts surface the malware, web shells, and living-off-the-land binaries an attacker uses to operate. This is where execution actually lands, so it is read closely.

Network traffic and flow records. What talked to what. Flow logs, proxy records, and DNS queries expose connections to known-bad infrastructure, beaconing to command-and-control, data egress to unexpected destinations, and internal traffic patterns that suggest lateral movement between hosts that have no business communicating.

Authentication and identity events. Where much compromise begins or spreads. Domain controller logs, sign-in records, and Kerberos and NTLM activity reveal logins from unfamiliar hosts, off-hours access, failed-then-successful brute force, anomalous service-account use, and the creation of accounts that grant an attacker a durable way back in.

Logs and security telemetry. SIEM data, application and server logs, and the alerts that fired but were closed or never triaged. A compromise assessment frequently finds the intrusion already recorded in logs nobody read, which is why it pulls the full record rather than trusting that monitoring caught what mattered.

Known indicators of compromise. Any indicators of compromise already in hand from threat intelligence, a prior incident, or a partner disclosure: file hashes, domains, IPs, and behavioral signatures. These seed the hunt, giving it specific things to sweep for before it widens into open-ended analysis.

The compromise assessment process

A compromise assessment is a defined investigation, not a scan. CrowdStrike frames it as four phases, and that arc holds regardless of vendor: assess the evidence, analyze it to confirm or rule out compromise, assist with response, then advise on hardening. Most engagements move through these stages in order.

1. Assess (collect and triage). Pull the telemetry that records the environment's recent history: endpoint and host data, network traffic, authentication events, and logs across the estate. Sweep it against known indicators of compromise and known-bad infrastructure to surface the events worth a human's attention. This stage is only as good as the data behind it: thirty days of logs answers a different question than a year of logs, and an endpoint with no recording agent answers almost nothing.

1. Analyze (confirm and scope). Investigate the surfaced events to decide whether they are an intrusion or noise, and if they are an intrusion, the who, what, when, and how. This is the threat-hunting core of the work: pivoting from one suspicious login to the account it created, to the host it reached, to the data it touched. Analysis confirms whether a compromise happened, when it started, what the attacker did, and what they reached, separating "this process looks odd" from "this process is a backdoor that is still beaconing."

1. Assist (respond and remediate). If the assessment confirms an active compromise, it does not stop at the verdict. It helps contain and remediate what was found: isolate affected hosts, revoke and rotate exposed credentials, remove attacker accounts and artifacts, and close the path that allowed entry. A confirmed, live intrusion is where the engagement hands off to a full incident response effort for containment, eviction, and recovery.

1. Advise (harden and prevent). Turn the findings into lasting change. The assessment produces hardening steps and process improvements: the monitoring gaps the hunt exposed, the logging that should have been on, the detections that should have fired, and the controls that would have stopped or surfaced the intrusion earlier. This is the phase that makes the next assessment cleaner.

What it hunts for: attacker behavior

A compromise assessment is only useful if it knows what intrusion actually looks like. The hunt is organized around the behaviors attackers repeatedly use once they are inside an environment.

Initial access and footholds. Phished credentials, exploited internet-facing services, malicious attachments, and the web shells or implants dropped on first entry. The assessment looks for the artifact that marks where the attacker came in.

Privilege escalation. An attacker with a low-privilege foothold looking for the unpatched local exploit, the misconfigured service, the cached domain-admin credential, or the token to impersonate that turns a single host into control of the domain.

Persistence. New accounts, scheduled tasks, run keys, services, modified group policy, and implanted backdoors, all the ways an attacker keeps a way back in even after the original entry point is closed or the malware is removed.

Defense evasion. Cleared event logs, disabled endpoint agents, timestomped files, and living-off-the-land use of legitimate tools like PowerShell and PsExec, all aimed at making sure the assessment finds nothing.

Collection and exfiltration. Staging and archiving files, querying databases, and egress to external destinations or cloud storage, the actions that turn an intrusion into a data breach and the ones a defender most wants confirmed or ruled out.

Compromise assessment vs threat hunting vs incident response

These three get conflated, and treating them as interchangeable leads to running the wrong one. They differ on their starting assumption, their cadence, and their output.

The relationships matter more than the table. Threat hunting is the continuous, hypothesis-driven practice that runs all the time inside the SOC; a compromise assessment is a scoped, point-in-time engagement that sweeps the whole environment for a verdict, often quarterly or after a specific trigger. The assessment uses hunting techniques but bounds them in time and scope and ends in a yes-or-no answer. Incident response takes over once that answer is yes and the intrusion is live. A compromise assessment sits between proactive hygiene and active firefighting: more adversarial and evidence-driven than a vulnerability scan, but not the full containment-and-recovery effort of an incident. When it confirms an active breach, it does not replace incident response, it triggers it.

Why organizations run them

The case for a compromise assessment comes down to what it catches that nothing else does, and the gaps it forces into the open.

It shrinks dwell time. The longer an attacker operates undetected, the more they escalate, spread, and exfiltrate. A periodic assessment is a deliberate floor on how long an intrusion can run before someone looks, independent of whether a rule happened to fire.

It validates the security program. The assessment frequently finds the intrusion already sitting in logs nobody read or alerts nobody triaged. That is a finding about the monitoring as much as the attacker, and it is the kind of gap a program cannot see from the inside.

It answers a specific question on demand. After a supply-chain breach, a leaked-credential disclosure, or a merger, leadership needs a defensible answer to "are we compromised?" A compromise assessment produces that answer with evidence behind it, rather than a shrug. Some regulated industries and cyber-insurance programs expect one for the same reason.

It maps the blind spots. Every place the hunt went dark for lack of logging or an endpoint agent is a place the next attacker operates unseen, which is why a compromise assessment so often ends with a telemetry and retention overhaul rather than a clean bill of health.

Deliverables

The deliverable is what the engagement is bought for, and for a compromise assessment it has to answer the question that prompted it. A useful report has a few non-negotiable parts.

A clear verdict: was there evidence of compromise, yes or no, stated plainly and qualified by the data that was available to reach it. A timeline and scope if the answer is yes: when the intrusion started, what the attacker accessed, which hosts and accounts are implicated, and whether the access is still active. The evidence behind each conclusion, tied to specific log events and artifacts, so a defender can verify the finding rather than trust it. A remediation and hardening plan: credentials to rotate, attacker artifacts to remove, gaps to close, and detections and logging to add. And a frank visibility gap statement: where the assessment could not see, because that gap is both a limit on the verdict and the most important thing to fix before the next one.

For a defender, the report doubles as a map of the environment's weak spots. The most actionable line is often not "we found an attacker" but "here is where we could not have seen one if it were there."

Frequently Asked Questions

What is a compromise assessment?

A compromise assessment is a point-in-time, evidence-driven investigation of an environment for signs that an unauthorized actor has accessed, persisted in, or moved through it. It collects endpoint data, network traffic, authentication events, and logs, then hunts them for indicators of compromise and attacker behavior. It assumes breach and looks for proof, rather than grading controls against a benchmark.

How is a compromise assessment different from a vulnerability assessment?

A vulnerability assessment or penetration test is preventive and forward-looking: it finds the weaknesses an attacker could use. A compromise assessment is investigative and backward-looking: it checks whether an attacker already used those weaknesses and what they did inside. One finds the open door; the other checks whether anyone walked through it. Mature programs run both.

How often should you run a compromise assessment?

Run one on a periodic basis, often quarterly, and reactively whenever something raises suspicion without a confirmed incident: a peer or supply-chain breach, a leaked-credential disclosure, an upcoming merger or acquisition that needs the environment vetted, or unexplained activity that monitoring flagged but could not resolve. It is the check for when "no alerts" is not the same as "no attacker."

What does a compromise assessment inspect?

It inspects endpoint and host data (processes, scheduled tasks, registry, on-disk artifacts), network traffic and flow records, authentication and identity events, SIEM and application logs, and any known indicators of compromise. The value comes from correlating these sources, because an intrusion usually appears as a chain across them, an unusual login leading to a new scheduled task leading to an outbound connection, rather than a single obvious event.

Is a compromise assessment the same as threat hunting?

No. Threat hunting is continuous and hypothesis-driven, running inside the SOC all the time. A compromise assessment is a scoped, point-in-time engagement that sweeps the whole environment for a verdict, often quarterly or after a specific trigger. The assessment uses hunting techniques but bounds them in time and scope and ends in a yes-or-no answer about whether the environment is compromised.

Is a compromise assessment the same as incident response?

No. A compromise assessment determines whether a breach occurred when none is confirmed; incident response is what happens once a breach is confirmed and active. The assessment is the investigation that produces the verdict; if that verdict is a live intrusion, it assists with containment and hands off to incident response for eviction and recovery. The assessment triggers incident response, it does not replace it.

What is in a compromise assessment report?

A plain verdict on whether compromise was found, a timeline and scope if it was, the specific log and artifact evidence behind each conclusion, a remediation and hardening plan (credentials to rotate, attacker artifacts to remove, gaps to close), and a statement of where the assessment could not see for lack of telemetry. That visibility-gap section is often the most actionable part, because it maps where the next intrusion would go unseen.

The bottom line

A compromise assessment is an evidence-driven hunt that assumes an attacker is already inside and goes looking for proof, reading the endpoint data, network traffic, authentication events, and logs that record what actually happened. It moves through four phases, assess the evidence, analyze it to confirm or rule out compromise, assist with response, then advise on hardening, and it ends in a verdict rather than a list of weaknesses.

It is not a vulnerability scan, it is not continuous threat hunting, and it is not incident response, though it relates to all three: the scan finds the weaknesses, hunting watches continuously, the compromise assessment delivers a point-in-time verdict on whether anyone got in, and incident response takes over when the answer is yes. For a defender, the report is the most direct artifact you will get of whether your environment is clean and, just as usefully, of where you cannot tell. Run it periodically and after anything that raises doubt, pair it with continuous monitoring, and treat every visibility gap it finds as the place the next intruder will hide.