Persistence:
Adversaries/attackers are trying to remain inside your system even after you remove them.
After the attacker gains access, they may try to keep their access alive for a long time adding access keys, backdoor users, or modifying startup scripts. then try to find or exfiltrate sensitive data
Attack :
Guard duty detected a finding in AWS and triggered an alert.
Persistence: IAMUser/AnomalousBehavior
The IAM user is behaving more suspiciously than usual—maybe trying to stay logged in longer, access services not used before, or use unusual regions.
If guard duty detects a finding, it generates an alert in the AWS GuardDuty console as a finding ID.
Defense:
Generally, an attacker is trying to maintain long-term access to a compromised AWS environment. That means user credentials were logged in without the actual user's knowledge.
Attackers keep sessions longer; hence, to find this, check the start and end times of the activity.
If the same user activity, deviating from the general baseline activity, is observed repeatedly or unusual activity with an updated end time is seen, we can suspect persistence.
Kindly check for any threat or alert detections on the user account.
These could also be benign true positive, or false positive alerts.
Hence, check the logs of the user's previous activities. If no threat indication or alerts are present, the user can be treated as risk-less. Check the historical logs; If the same API access is observed from the user previously, the alert can be closed because the user already has access.
It is important to investigate the AWS logs for the reason why GuardDuty detected a threat.
Need to check with the team managing AWS for access information, or with the user, to easily classify and triage this activity.
If compromise identified or its not user activity
We need to revoke sessions, reset access keys, and rotate passwords for the user
We also need to strengthen security rules for initial access, such as implementing MFA or a 2FA mechanism.
Payload Explanation:
{"schemaVersion":"2.0","accountId":"123456789012","region":"us-east-1","partition":"aws","id":"abcd1234-5678-90ab-cdef-EXAMPLE11111","arn":"arn:aws:guardduty:us-east-1:123456789012:detector/12abc34d567e8f9012g3h456789i012j/finding/abcd1234-5678-90ab-cdef-EXAMPLE11111","type":"Persistence:IAMUser/AnomalousBehavior","resource":{"resourceType":"AccessKey","accessKeyDetails":{"accessKeyId":"AKIAEXAMPLE","principalId":"AIDAEXAMPLE","userType":"IAMUser","userName":"example-user"},"instanceDetails":null},"service":{"serviceName":"guardduty","detectorId":"12abc34d567e8f9012g3h456789i012j","action":{"actionType":"AWS_API_CALL","awsApiCallAction":{"api":"ListBuckets","serviceName":"s3.amazonaws.com","callerType":"remote IP","remoteIpDetails":{"ipAddressV4":"203.0.113.42","organization":{"asn":"64512","asnOrg":"EXAMPLE ISP","isp":"EXAMPLE ISP","org":"EXAMPLE ORG"},"country":{"countryName":"Russia"},"city":{"cityName":"Moscow"},"geoLocation":{"lat":55.7558,"lon":37.6173}},"userAgent":"aws-sdk-java/1.11.100","domainDetails":{"domain":"s3.amazonaws.com"},"additionalInfo":{"anomalousApi":"ListBuckets","apiCount":37,""apiUsedByUser":"GetObject,PutObject,CreateBucket,DeleteBucket","unusualServiceAccess":"S3","userAccessPatterns":"This user typically accesses EC2, but is now accessing S3","unusualCountryAccess":"true"}}},"eventFirstSeen":"2025-05-07T00:00:00Z","eventLastSeen":"2025-06-07T00:05:00Z","archived":false,"count":1},"severity":5,"title":"IAM user is exhibiting anomalous behavior","description":"An IAM user has accessed services in an unexpected way, including API calls not normally used and from a geolocation not previously associated with this user. This could indicate credential compromise or attacker persistence."}
Lets discuss on payload
IAM user / Assumed role user has a principal ID. The user is accessing S3 buckets from the user agent aws-sdk-java/1.11.100, which seems to be anomalous behavior because the user generally accesses EC2. However, new activity is observed: accessing S3 buckets and also from a geo location not previously associated with this user (this is identified in the description field).
Persistence can be identified from timestamps: the first event seen and the last event seen.
first activity of this behaviour seen for the 2025-05-07T00:00:00Z and the last even seen :"2025-06-07T00:05:00Z"
First anomalous detection from the user deviated from the baseline observed on the first event seen, and a new activity deviation from the base line was observed on the last event seen.
The user first deviated from their baseline behavior on the eventFirstSeen date, and a new deviation was detected on the eventLastSeen date, indicating persistent anomalous activity.
Please write all the analysis observed and follow defense mentioned above.
Some other findings on AWS GuardDuty are mentioned below.
Persistence: ResourcePermission/ Bitcoin Tool.B
Persistence: EC2/SSHBruteForceSuccess
