Blinding the monitors: AWS Config and Inspector disabled before the breach

Attackers blind defenders before they act. Disabling CloudTrail and GuardDuty is well known, but AWS Config and Inspector are the quieter pair that kill compliance drift detection and vulnerability scanning.

How the attack works

An over-permissioned role calls StopConfigurationRecorder to halt configuration-item recording and compliance drift detection, then disables Inspector scanning to stop continuous vulnerability assessment of compute, container, and serverless workloads. With both services dark, the actor introduces new resources and permissive changes that would normally surface as drift or findings, and no new alerts appear despite material changes. This is Impair Defenses, T1562, through Valid Accounts: Cloud Accounts, T1078.004, with Indicator Removal, T1070.

Why it works

Any sufficiently privileged role can blind these detectors, and the very dashboards and findings that would show the change are the ones that went silent. The attacker is betting you will look to the monitoring they just turned off.

How to fix it

Do not ticket it and leave monitoring dark. Re-enable Config and Inspector from infrastructure-as-code for a known-good state, revoke the role session with a deny on the token issue time, and deploy a service control policy that denies the disable APIs even for privileged roles. For forensics, the stopped recorder leaves a gap, so reconstruct the blind window from CloudTrail, which still logs every change with the caller. The durable fix is SCP guardrails denying disablement of Config, Inspector, CloudTrail, and GuardDuty except through a controlled break-glass path, plus least-privilege on the roles that held those permissions.

Practice it

We built this as a GraphLattice Range scenario so security teams can rehearse finding the attack in CloudTrail when the detector is off, restoring visibility, and guarding the monitors with SCPs.