When AWS Fires Your MFA Detection For You

When AWS Fires Your MFA Detection For You



Tópico: When AWS Fires Your MFA Detection For You
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
An attacker stripping MFA off an account is exactly the kind of thing you want to catch. Remove the second factor, and a stolen password is the whole game. So you write the rule: alert when someone calls DeactivateMFADevice or DeleteVirtualMFADevice.

It fires. Good. Then it fires again. Then it fires every single time someone leaves the company.

Because AWS removes MFA for you when you delete a user, and CloudTrail records the cleanup as the same event an attacker would generate.



The detection that looks correct


MFA removal maps cleanly to a real technique – credential access, account manipulation, T1556. Alerting on it is a defensible call that passes review without a second look. The rule is about as simple as detection gets:

index=aws sourcetype=aws:cloudtrail eventName IN (DeactivateMFADevice, DeleteVirtualMFADevice)

Specific. Low volume on paper. Maps to the matrix. Nothing about it looks wrong, which is exactly the problem.



What AWS actually does


You cannot delete an IAM user that still has an MFA device attached. AWS rejects the DeleteUser call until the device is gone. So deletion has a precondition: remove the MFA first.

It doesn't matter whether the offboarding runs through the console, the CLI, or a Lambda someone wrote two years ago. The sequence CloudTrail records is the same every time:

DeactivateMFADevice    (actor: offboarding-role, target: jdoe)
DeleteVirtualMFADevice (actor: offboarding-role, target: jdoe)
DeleteUser             (actor: offboarding-role, target: jdoe)

Same actor. Same target. Seconds apart. Every legitimate offboarding produces the precise event your "attacker stripped MFA" rule was built to catch. The detection can't tell the two apart because there is nothing to tell apart. It's the same API call. No threshold, no severity tweak, no field you've overlooked changes that.



Why the docs won't save you


AWS documents its API calls one at a time. DeactivateMFADevice does what it says. DeleteUser does what it says. What the docs don't tell you is that the second one emits the first as a precondition – that deleting a user fans out into a cascade of events, and the cascade members are indistinguishable from standalone malicious activity.

Most AWS detection content has the same blind spot. It treats CloudTrail events atomically, one rule per eventName. But the truth here doesn't live in any single event. It lives in the relationship between three of them, and that relationship is exactly what nobody writes down.

You don't learn this from reading. You learn it from triaging your own false positives until the pattern is obvious.



Detect the action, not the side effect


The benign case has a signature: the MFA removal is always followed by a DeleteUser for the same person. So correlate, and let the benign pattern suppress itself.

index=aws sourcetype=aws:cloudtrail eventName IN (DeactivateMFADevice, DeleteVirtualMFADevice)
| eval target_user=coalesce('requestParameters.userName', 'requestParameters.serialNumber')
| join type=left target_user
[ search index=aws sourcetype=aws:cloudtrail eventName=DeleteUser earliest=-60m latest=+60m
| eval target_user='requestParameters.userName'
| eval deleted=1
| fields target_user deleted ]
| where isnull(deleted)

The window is two-sided on purpose. CloudTrail timestamps and delivery aren't strictly sequential – don't assume the DeleteUser always lands after the MFA events. Look both directions.

What survives the suppression is MFA removal that is NOT part of a deletion. Someone stripped a second factor off a user who is still active. That's the thing you actually wanted to know about, and now it's the only thing left in the queue.



The lesson generalizes


Cloud control planes emit cascades. One human action fans out into a handful of API calls, and the side-effect calls in that fan-out look identical to the same calls fired in isolation by an attacker. MFA removal on offboarding is one instance. Snapshot sharing during a backup job is another. Key rotation, role teardown, bucket policy changes during a decommission – every one of them has a benign cascade that mimics an attack.

Detect the originating action where one exists. Where it doesn't, correlate the cascade members so the benign sequence cancels itself out. And catalog the cascades for your high-value events the same way you'd catalog the noisy controller roles in your environment – the cascade map is a reusable artifact, not a one-time tuning pass.



The actual lesson


The detection wasn't catching attackers. It was catching HR. AWS generated the smoking gun on every offboarding, and the rule dutifully reported routine cleanup as an intrusion.

Detect the action a human took, not the side effect the platform emitted to carry it out. The platform's side effects look exactly like the attack, and they always will.