Many target AWS from afar, but this #redteam played the long game:
1. Physical access to a laptop via a retail store
2. Persisted via a @Raspberry_Pi under a table
3. Lat. movement via SSH through OSX
4. Recon via Bash history
5. Used stolen .boto to access AWS
👇Thread 👇
1. Physical access to a laptop via a retail store
2. Persisted via a @Raspberry_Pi under a table
3. Lat. movement via SSH through OSX
4. Recon via Bash history
5. Used stolen .boto to access AWS
👇Thread 👇
1. Lock your laptops! Lower the password timeout window so your users don't have to think about it. With this access the red team was able to gain not only their initial access, but credentials they could use to SSH to several machines across the org.
2. Strong case for asset inventory, especially if a non-standard device such as a Raspberry Pi joins the network. Identifying and alerting on such devices would have caught this much earlier (especially if on a retail/guest wifi).
3. If there is not a strong case for needing SSH on OSX laptops, lock it down. Additionally, the attacker dumped several OSX keychains using github.com/juuso/keychain… and continued to use stolen credentials from the OSX keychain to move laterally and further their access.
4. Bash history is a trove of good information for an attacker. Specifically we noticed the red team target AWS CLI commands where specific users/keys were being referenced to administer AWS.
5. We were alerted to the stolen credentials via abnormal logins/access key generation alerts from #GuardDuty. Pivoting back to endpoint analysis revealed the API creds were being stolen from OSX laptops when we noticed attempts to access .boto files by a known compromised user.
