* [New Rules] AWS Long-Term Creds Abuse Coverage
This adds a two-layer approach to long-term IAM access key (AKIA*) abuse, aligned with reporting on stolen or leaked keys often abused as seen in Kudelski Security — Trivy supply-chain report.
### Layer 1 — AWS Long-Term Access Key First Seen from Source IP (9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f)
New Terms on CloudTrail when a given AKIA succeeds from a new `source.ip` in the history window.
Goal: catch novel use of a durable key (travel, new egress, or attacker infrastructure).
### Layer 2 — AWS Long-Term Access Key Correlated with Elevated Detection Alerts
Higher-order rule on open alerts that requires both the Layer 1 rule and at least one other open alert on the same `source.ip` at medium+ severity (or equivalent risk score).
Goal: raise priority when “new IP for this key” happens together with stronger, post-compromise-style signals.
The higher-order rule correlates on `source.ip` in .alerts-security.* index. In testing, I chose to tie the same sessions together using `source.ip` vs `access_key.id` because the alerts index did not expose this field for queries.
Screenshots below show testing that verified the approach. The same operator/session across Layer 1 rule, the sibling alert, and the Layer 2 correlation rule for two separate lab scenarios (e.g. a high-severity sibling rule and a medium-severity sibling rule).
* adding IAM to rule names
* removing unnecessary ref
* Fixed Mitre tactics and tags
---------
Co-authored-by: Terrance DeJesus <99630311+terrancedejesus@users.noreply.github.com>
Isai
a6d31d7dfd