When an attacker turns off your alarms: PagerDuty key abuse

Not every attacker is after data first. Some are after silence. A PagerDuty REST API key can turn paging on and off, and a stolen one lets an attacker blind the responders while an attack runs elsewhere.

How the attack works

The key is used from a host outside the automation infrastructure, late at night. It creates broad maintenance windows over critical services, suppressing alerting so incidents will not page anyone. It then reads on-call schedules, escalation policies, and user contact methods, mapping who responds and how to reach them for social engineering. Under that cover, a parallel attack on the suppressed services proceeds without triggering a response. In ATT&CK terms this is T1562, Impair Defenses, paired with T1213, Data from Information Repositories, and T1098 for account-level manipulation.

Why it works

Legitimate automation creates narrow, scheduled maintenance windows during change windows from known hosts. Broad windows over critical services plus on-call contact reads from a new source at an odd hour is the deviation. A long-lived, broadly scoped key with no source restriction, and the ability to suppress alerting without approval, makes the silence possible.

How to fix it

Containment is two-part: revoke and rotate the key to stop further changes, then delete the malicious maintenance windows to re-enable paging. Acknowledging the suppressed alerts does not undo the suppression, and an IP block is bypassed. Correlate the audit log with service telemetry to find what ran under the blind window, because the absence of alerts is the engineered outcome, not evidence of safety. For the class, least-privilege and source-restrict keys, and alert on the act of suppressing alerts.

Practice it

We built this as a GraphLattice Range scenario so responders can rehearse the two-part containment and learn to alert on suppression itself.