Os cookies viraram controle remoto pros hackers.
O time do Defender da Microsoft jogou uma bomba: atores de ameaça tão usando cookies HTTP pra pilotar shells web PHP controladas por cookies em servidores Linux, driblando detecção como pros. Esquece parâmetros de URL ou bodies de POST — essas shells chupam instruções direto do $_COOKIE, ligando só quando os valores certos batem. Furtivo? Pode apostar. E eles casam isso com jobs cron pra uma persistência que se cura sozinha e zoa as equipes de limpeza.
Aí vai o esquema cru, direto da pesquisa. Atacantes pegam acesso inicial — credenciais válidas ou exploit de vuln — e plantam um job cron que chama um loader PHP ofuscado a cada poucos minutos. Esse loader? Dorme no tráfego normal. Mas joga o cookie mágico, e pá: execução remota de código, upload de arquivos, drop de payloads. A Microsoft cravou:
“Ao mover o controle de execução pros cookies, a shell web fica escondida no tráfego normal, ativando só em interações deliberadas.”
Três versões na jogada. Uma é uma fera de ofuscação em camadas, parseando dados de cookie pra desempacotar payloads secundários. Outra reconstrói funções de pedaços de cookie, escreve no disco, roda. A mais simples? Um cookie só como gatilho pro caos que você mandar.
Por Que Cookies Ganham dos Truques Clássicos de Shell Web?
Olha, shells web não são novidade — lembra das ondas dos anos 2010 batendo em servidores Apache. Mas cookies? Pivô genial. Eles vêm em toda request legítima, sem dor de cabeça pra parsear, sem grito nos logs. Acesso em runtime via superglobais significa zero código extra. Mistura com o papo normal do app, e seu EDR boceja.
Compara com os truques velhos de URL: aqueles acendem tipo Natal nos logs de acesso. Cookies? Enterrados nos headers, muitas vezes cortados ou ignorados. Fora que o gatilho mantém a shell inerte — ideal pra C2 de longo prazo sem pings constantes.
Mas minha visão, que a Microsoft pula: isso fede a playbooks de backdoors Unix reciclados dos anos 90. Lembra aqueles worms acadêmicos que se agendavam no cron em /tmp? Mesma vibe — caminhos legítimos (procs web, painéis de controle, crons) pra staging. Não é inovador, só reuso brutalmente efetivo. Aposto: isso vai migrar pra nuvens containerizadas, cron mutado em jobs Kubernetes.
O Pesadelo do Cron Auto-Regenerativo
Persistência é o app matador aqui. Apaga o loader? Cron recria. Sem writes barulhentos durante as ops, só hits agendados. Microsoft viu isso em ambientes Linux hospedados — pensa em vítimas de cPanel.
“Essa arquitetura ‘auto-regenerativa’ permite que o loader PHP seja recriado repetidamente pela tarefa agendada, mesmo se removido na limpeza e remediação.”
Brilhante operacional. Separa persistência (cron) do controle (cookies), calando os logs. Sem chains de exploit; sequestra o que já tá lá. A gente viu picos de shells Linux pós-Log4j — isso encaixa no padrão, atores turbinando tempos de dwell pós-breach.
Detectores patinam. Scans estáticos perdem código dormente. Comportamental? Cookies parecem baunilha. Footprint minúsculo: ofuscação pra todo lado, sem binários gordos.
E sim, o PR da Microsoft pinta como ‘tradecraft estabelecido’ — justo, mas subestimam o lado econômico. Barreira baixa: qualquer script-kiddie com noção de PHP clona isso. Dinâmica de mercado? Provedores de hosting sangram primeiro — servidores Linux compartilhados são doces.
Isso Detona as Defesas Tradicionais?
Resposta curta: em boa parte. WAFs? Cookies muitas vezes isentos. Volume de log afoga sinais. Mas tem frestas.
Playbook da Microsoft — base sólida. MFA em tudo (SSH, painéis). Auditorias de cron. Restrições de shell. Watches de arquivos nas raízes web.
Mas afia isso. Eles pecam em proteções de runtime. Caça acessos a $_COOKIE em PHP — raro em código legítimo. Baselines comportamentais: flag jobs cron parindo arquivos web. Regras SIEM pra picos de entropia em cookies (payloads base64-ish). E shifts pra containers? Scan por jobs rogue no K8s.
Vantagem única: casa com forense de host. Crons
