Het Israëlische securitybedrijf Mitiga heeft een nieuwe manier gevonden om AWS Systems Manager te misbruiken als een Remote Access Trojan (RAT).
AWS Systems Manager is normaal gesproken bedoeld om DevOps-engineers te helpen met het automatisch managen van besturingssystemen in EC2-instances. Nu blijkt echter dat kwaadwillenden met een vergevorderde toegang tot IT-systemen de tool in kunnen zeten om op een structurele manier aanvallen op te zetten.
Voordelen
Zodra aanvallers de Systems Manager kunnen overnemen, zijn er een aantal voordelen hiervoor. Allereerst wordt een SSM-agent vertrouwd door allerlei security-oplossingen waardoor er geen alerts worden getriggerd. Daarnaast hoeft er geen nieuwe RAT-binary gebruikt te worden, omdat de SSM-agent al aanwezig is en als een RAT fungeert. Via deze tool kunnen aanvallers legitiem overkomen terwijl men het gebruikt als command & control-centrum. Er is daarnaast geen programmeercode nodig om de infrastructuur aan te vallen.
De gecompromitteerde endpoint is ook nog eens eenvoudig te manipuleren met features als “RunCommand” en “StartSession” via een ander AWS-account.
Systems Manager is bovendien populair, waardoor de inzetbaarheid voor deze exploitatie groot is.
Exploitatie, detectie en mitigatie
Mitiga legt uit hoe de Systems Manager geëxploiteerd kan worden. De aanvaller moet toestemming hebben om commands uit te voeren op een Linux- of Windows-machine met een SSM Agent erop. Aanvallers kunnen vervolgens trojans of backdoors installeren om toegang te blijven houden tot de endpoint. Vervolgens zijn de mogelijkheden bekende vormen van exploitatie: het stelen of versleutelen van data, het installeren van een cryptominer of het verder verspreiden op het netwerk.
Mitiga heeft zijn bevindingen gedeeld met AWS en raadt aan om SSM-agents niet zomaar op de “allow list” te laten staan van EDR-oplossingen. Zo wordt voorkomen dat deze tool in feite als een RAT te werk kan gaan.
Ook is een aanval te detecteren omdat de instance ID verplaatst. Deze zijn te vinden in /var/lib/amazon/ssm/i-*** op Linux en in C:\ProgramData\Amazon\SSM\InstanceData\i-***. Er zou niet meer dan één directory moeten zijn met een andere isntance-naam dan de oorspronkelijke instance-ID. Ook zou er niet meer dan één proces moeten zijn dat “amazon-ssm-agent” heet.
Lees ook: VMware: patch kwetsbaarheid in Aria Operations for Logs
18 uur geleden
