Compromise Assessment: tracking down hidden attackers

A compromise assessment is a point-in-time, forensically supported investigation of an IT environment for traces of active or past compromises. It follows the "assume breach" principle: what is examined is not the absence of vulnerabilities but the presence or absence of attacker activity – on endpoints and servers, in identity services, and in network and cloud logs. The investigation is limited in time and delivers a snapshot for a defined scope and observation period. It replaces neither continuous detection nor a security operations center; rather, it answers a point-in-time question that day-to-day operations alone cannot answer.

In mergers & acquisitions, the buyer verifies before integration whether it is taking over an existing compromise along with the target company – according to M-Trends 2026, a prior compromise was the third most common initial attack vector at 10%, rising to 30% in ransomware cases. A second trigger is concrete suspicion, for example following notifications from authorities or CERTs, anomalous telemetry, or an extortion message. After a security incident has been handled, an assessment demonstrates before systems go back online that no residual access remains – a building block of incident handling, which NIS2, for instance, requires of affected entities in Art. 21(2)(b). In the context of cyber insurance as well, for example during risk dialogues or after a claim, a documented compromise status may be required or helpful.

After scoping, forensic artifacts are collected broadly: process and autostart information, scheduled tasks and services, logon and event logs, command-line and PowerShell histories, network connections, and traces in identity and cloud services. Two complementary search strategies build on this: IOC sweeps match the data against known indicators of compromise (file hashes, IP addresses, domains), while TTP-based analyses search behaviorally for attack techniques along the MITRE ATT&CK knowledge base, thereby also capturing activity without a known signature. Existing EDR telemetry is analyzed or temporarily rolled out for the duration of the investigation; suspicious hits are validated manually to separate genuine findings from noise.

A penetration test answers the question of where an attacker could break in – it is vulnerability-oriented and simulates the attack. A compromise assessment answers the question of whether an attacker has already broken in or did so in the past – it is evidence-oriented and looks backward. Threat hunting, in turn, is a continuous, hypothesis-driven process within an established security operations practice; the compromise assessment, by contrast, is a one-off, broad-based stocktake that can be carried out even without an in-house SOC. The three formats do not replace one another – they complement each other.

The central deliverable is the compromise statement: a documented assessment of whether indications of active or past attacker activity were found within the examined scope and period – including the limits of that statement, since a negative result does not prove the absolute absence of compromise but refers to the data actually available. This is complemented by a findings report with rated individual findings and affected systems, as well as prioritized hardening and detection recommendations. If active compromises are found, the assessment transitions into structured incident response; the handover points should be defined in advance – in line with the integration of incident response into cybersecurity risk management described in NIST SP 800-61 Rev. 3.

Active attackers are the rarest but most critical finding. More common are traces of past, never-detected compromises, web shells on exposed systems, persistence mechanisms such as newly created services, scheduled tasks or autostart entries, as well as compromised or orphaned privileged accounts and unauthorized remote access tools. In addition, many assessments produce structural findings: gaps in logging and sensor coverage, log retention periods that are too short, or insecure configurations that would hamper later forensic analysis. These findings also feed into the recommendations – requirements for this kind of forensic readiness are described in module DER.2.2 of the BSI IT-Grundschutz.