Sie sind an Cloud Computing interessiert? Legen Sie jetzt los

Dark background with blue code overlay

Blog

RSS

Ransomware-Angriff auf die Kaseya-Lieferkette

Ryan Barnett

Verfasser

Ryan Barnett

July 15, 2021

Ryan Barnett

Verfasser

Ryan Barnett

Ryan Barnett arbeitet als Principal Security Researcher im Akamai Threat Research Team an der Sicherheitslösung App & API Protector. Neben seiner hauptberuflichen Arbeit bei Akamai ist er Mitglied des WASC Board Member und OWASP-Projektleiter für: Web Hacking Incident Database (WHID) und Distributed Web Honeypots. Herr Barnett hält regelmäßig Vorträge auf Konferenzen der Sicherheitsbranche wie der Black Hat und hat zwei Bücher über Internetsicherheit geschrieben: „Preventing Web Attacks with Apache“ (Pearson) und „The Web Application Defender's Cookbook: Battling Hackers and Defending Users“ (Wiley).

Am 2. Juli 2021 gab Kaseya bekannt, dass über das unternehmenseigene VSA-Produkt ein aktiver Angriff auf Kunden erfolgt war, und wies alle On‑Premise-Kunden an, Kaseya VSA auszuschalten. Kurz vor dieser Warnung gab es erste Nutzermeldungen auf Reddit zu Ransomware-Vorfällen gegen Managed Security Provider (MSP), wobei alle Angriffe auf On‑Premise-Bereitstellungen von VSA gerichtet waren. In den darauffolgenden Stunden wurden mehrere Indicators of Compromise (IOCs) veröffentlicht und Akamai war in der Lage, einen Teil dieses Traffics zu beobachten. Am 11. Juli wurde von Kaseya ein Patch für das VSA-Produkt veröffentlicht.

Angriffsausführung:

Die Angreifer gehörten zur Ransomware-Gruppe REvil und nutzten Schwachstellen bei Authentifizierungsumgehung und willkürlicher Befehlsausführung (CVE-2021-30116) aus, um Ransomware-Verschlüsselungen auf den Zielsystemen einzuschleusen. Als Abhilfe veröffentlichte Kaseya eine Reihe von IOCs zu den Ransomware-Angriffen.

Trafficanalyse:

Anhand dieser IOCs kann Akamai durch unseren umfassenden Einblick in den Internettraffic und die Abfrage von Petabytes an Trafficdaten wichtige Muster identifizieren und Einblicke in Quellen, Verteilung und Verbreitung des Angriffs erhalten. Wir haben den HTTPS-Traffic aus dem zeitlichen Verlauf der Kaseya-Angriffe (1. bis 6. Juli 2021) analysiert und so den gesamten Traffic ermittelt, der auf die in den IOCs beschriebenen URLs zugegriffen hat.

Mit der Analyse sollte geklärt werden, wer diese URLs durchsucht hat und ob der Traffic im Rahmen von Ausspähaktivitäten (Zielidentifizierung) durchgeführt wurde oder es sich um tatsächliche Ausbeutungsversuche handelte. Grundlegend gilt dabei, dass GET-/HEAD-Anfragen dem Ausspähen und der Identifizierung dienen, während POST-Anfragen eine Ausnutzung bedeuten. Wir stellten fest, dass der Traffic im Wesentlichen GET-/HEAD-basiert war, d. h., dass es sich um Zielscanning-Traffic handelte und nicht um Exploit-Versuche.

Im Sinne der Transparenz ist jedoch zu erwähnen, dass die geringe Anzahl von POST-Anfragen ein Hinweis darauf sein könnte, dass es zum Zeitpunkt des Scannens keine VSA-Server hinter der Akamai-Plattform gab.

Trafficdetails:

Nach Abschluss der Analyse identifizierte Akamai im Dataset zu den Trafficdetails 372 HTTP‑Anfragen. Fast alle Anfragen waren GET (97,85 %), gefolgt von HEAD (1,88 %) und schließlich POST (0,27 %). Wie bereits erwähnt, deutet das Vorhandensein von GET-/HEAD-Anfragen darauf hin, dass der Traffic auf Identifizierung und nicht auf Ausnutzung konzentriert war. Wir konnten auch 88 eindeutige IP-Adressen identifizieren. Details dazu finden Sie am Ende dieses Beitrags.

Abbildung 1: Aufschlüsselung der IOC-URL-Zugriffe vom 1. bis zum 6. Juli 2021 Abbildung 1: Aufschlüsselung der IOC-URL-Zugriffe vom 1. bis zum 6. Juli 2021

Wir haben den 1. Juli 2021 in unsere Analyse aufgenommen, da dies der Tag vor der Veröffentlichung des Angriffs durch Kaseya war. Die Grafik zeigt, dass es wahrscheinlich eine gewisse Menge an normalem Traffic gegeben hat. Die Daten verdeutlichen auch, dass viele Unternehmen die Warnung von Kaseya ernst genommen und die VSA-Software heruntergefahren oder deaktiviert haben.

Bei der Trafficanalyse wurde festgestellt, dass das am häufigsten verwendete Tool Fuzz Faster U Fool war, gefolgt von GoBuster. Wie der Name schon sagt, ist Fuzz Faster U Fool – oder Ffuf – ein Fuzzing-Tool zur Identifizierung. GoBuster wird für Brute‑Force-Angriffe auf URIs und DNS-Subdomains verwendet. Beide sind beliebte Tools für Bug-Bounty-Jäger. In diesem Fall legt die Trafficanalyse nahe, dass diese Tools zur Suche nach URLs genutzt wurden, die mit den IOC-Zeichenfolgen übereinstimmen, um anfällige Ressourcen zu finden.

Fazit:

Scans und Analysen decken zwar nur ein kleines Zeitfenster ab, es muss aber betont werden, dass Schwachstellen-Scans und das Ausspähen von Zielen fortlaufend erfolgen. Angreifer untersuchen und testen Ihr Netzwerk kontinuierlich auf Anfälligkeiten.

Lieferkettenangriffe wie die auf die MSP-Kunden von Kaseya und deren Kunden sind ein Albtraumszenario. Daher müssen Patches so schnell wie möglich angewendet und die Abwehrfunktionen gegen schädlichen Traffic überwacht und richtig eingestellt werden.

Im Fall von Kaseya wurde jedoch eine Zero‑Day-Schwachstelle ausgenutzt, sodass kein Patch vorhanden war. In solchen Situationen sind mehrschichtige Abwehrmechanismen, Netzwerksegmentierung und Notfallwiederherstellungspläne von entscheidender Bedeutung (einschließlich segmentierter Sicherungen). Die für Notfallwiederherstellung und Betrieb Verantwortlichen sollten Szenarien für Lieferkettenprobleme berücksichtigen, darunter den vollständigen Verlust oder Unterbrechungen der gemanagten Ressourcen.

Das Team von Akamai Threat Research verfolgt auch weiterhin Traffic im Zusammenhang mit dem Kaseya-Angriff. Bei Bedarf wird der Blogbeitrag weiter aktualisiert.

Identifizierte IP-Adressen:

104.200.29.139

113.173.149.48

117.61.242.70

117.95.232.62

122.178.156.152

123.204.13.110

134.122.114.190

143.110.241.135

143.244.128.87

147.182.172.145

151.244.4.153

154.185.203.234

155.138.162.201

156.217.110.66

159.65.228.100

159.89.177.106

161.35.136.251

161.97.70.207

165.22.205.38

165.22.41.30

167.99.49.144

17.253.80.103

175.101.68.80

175.16.145.28

177.86.198.242

178.128.224.80

178.128.28.156

178.239.173.161

180.94.33.200

183.22.250.36

185.195.19.218

185.65.135.167

188.166.61.213

192.254.65.235

192.40.57.233

193.169.30.10

193.56.252.132

194.195.219.144

194.233.64.67

194.44.192.200

194.5.52.4

194.5.53.98

195.95.131.110

196.64.76.3

199.247.23.87

2.16.186.103

2.16.186.86

2.59.134.200

2.59.135.105

2.92.124.237

20.73.12.15

20.73.12.60

20.74.134.159

202.142.79.81

204.4.182.16

207.244.245.21

222.76.0.230

2604:a880:0400:00d0:0000:0000:1d1b:7001

2a01:04f8:010b:0710:0000:0000:0000:0002

2a01:04f8:1c1c:cc87:0000:0000:0000:0001

2a01:7e00:0000:0000:f03c:92ff:fe12:3d0a

2a0d:5940:0006:01d9:0000:0000:0000:7abe

2a0d:5940:0006:01ea:0000:0000:0000:498d

34.132.164.221

34.132.182.60

34.71.132.48

35.202.142.60

35.232.137.16

35.232.55.163

37.220.119.221

45.124.6.219

45.14.71.9

45.86.201.85

46.19.225.91

50.35.184.96

51.83.140.186

52.15.133.71

52.151.244.28

52.188.217.115

52.20.26.200

52.205.190.252

54.37.72.253

66.23.228.62

76.76.14.36

85.203.46.145

89.39.107.195

91.90.44.22

94.68.117.73



Ryan Barnett

Verfasser

Ryan Barnett

July 15, 2021

Ryan Barnett

Verfasser

Ryan Barnett

Ryan Barnett arbeitet als Principal Security Researcher im Akamai Threat Research Team an der Sicherheitslösung App & API Protector. Neben seiner hauptberuflichen Arbeit bei Akamai ist er Mitglied des WASC Board Member und OWASP-Projektleiter für: Web Hacking Incident Database (WHID) und Distributed Web Honeypots. Herr Barnett hält regelmäßig Vorträge auf Konferenzen der Sicherheitsbranche wie der Black Hat und hat zwei Bücher über Internetsicherheit geschrieben: „Preventing Web Attacks with Apache“ (Pearson) und „The Web Application Defender's Cookbook: Battling Hackers and Defending Users“ (Wiley).