Campanha atribuída ao grupo DarkCrewFriends instala web shells PHP, aciona arquivos disfarçados com extensão.aff e usa canais IRC para receber comandos, executar ações no servidor e apoiar ataques DDoS.
| Componente | Servidores PHP que hospedam sites de CMS vulneráveis a upload irrestrito de arquivos, com instalação posterior de web shell PHP e bot em PHP/Perl. |
| Vetor | Requisição especialmente construída para contornar validação de extensão e carregar arquivo malicioso no servidor; após o upload, o operador aciona parâmetros definidos no web shell. |
| Impacto | Execução arbitrária de código no sistema afetado, execução de comandos de shell, integração do host a uma botnet controlada por IRC e uso potencial em ataques DDoS e outras ações contra a infraestrutura. |
| Prioridade | Inventariar aplicações PHP com upload de arquivos, validar controles de extensão e tipo de conteúdo, procurar web shells recém-criados, bloquear comunicação IRC suspeita e remover artefatos persistentes. |
| Artefatos | Web shells PHP com parâmetros como osc e anon, arquivos com extensão .aff que na prática continham código PHP ou Perl, e remoção posterior desses arquivos para reduzir rastros. |
| IoCs | Exemplos observados incluem lubrisabana[.]com, pkalexeivic[.]com e o endereço 190[.]145[.]107[.]220; indicadores devem ser tratados como ponto de partida para caça, não como lista completa. |
A campanha DarkCrewBot tem como foco servidores PHP que hospedam sites de gerenciamento de conteúdo e expõem funcionalidades de upload de arquivos sem validação suficiente. O fluxo observado combina uma vulnerabilidade de upload irrestrito, instalação de web shell, carregamento de artefatos disfarçados e comunicação com infraestrutura de comando e controle por IRC. O objetivo operacional é transformar servidores comprometidos em nós de uma botnet capaz de receber instruções remotas, executar comandos no sistema e participar de diferentes modalidades de negação de serviço distribuída.
A atividade foi associada ao grupo DarkCrewFriends, que já mantinha histórico de oferta de bots, serviços de tráfego e exploração de servidores. A atribuição se apoia em elementos técnicos e operacionais presentes nos artefatos, incluindo referências visuais do próprio grupo, uso recorrente de explorações de upload, comentários e nomes de variáveis em italiano, além de relações com fóruns onde serviços de exploração e botnets eram anunciados. A análise deve ser tratada com o limite normal de atribuição em inteligência de ameaças: os indícios conectam a campanha ao ecossistema DarkCrewFriends, mas a resposta defensiva deve priorizar os comportamentos observáveis no servidor, na rede e nos arquivos.
O risco central não está apenas no web shell inicial. Uma vez que o arquivo PHP é aceito pela aplicação vulnerável e pode ser acessado pelo atacante, o servidor passa a executar lógica controlada remotamente. Essa lógica aciona código codificado, prepara a obtenção de componentes adicionais e remove arquivos temporários para dificultar a análise posterior. O canal IRC amplia o impacto porque permite que operadores enviem comandos, recebam menus de capacidade e coordenem ações em múltiplos hosts comprometidos. Em ambientes com muitos sites PHP antigos, plugins sem manutenção ou diretórios de upload executáveis, a campanha encontra uma superfície favorável para persistir e escalar em volume.
O ponto de entrada descrito é uma falha de upload irrestrito de arquivos. Muitas aplicações web aceitam imagens, documentos ou outros anexos de usuários, mas a segurança depende de controles consistentes sobre extensão, tipo MIME, localização de armazenamento e permissão de execução. No caso explorado, o atacante envia uma requisição preparada para contornar a verificação de extensão e fazer com que o servidor aceite um arquivo PHP malicioso. Se esse arquivo é salvo em um caminho acessível pelo servidor web e interpretado pelo motor PHP, a operação deixa de ser simples gravação de arquivo e passa a permitir execução de código no lado do servidor.
Após o upload, o operador acessa o arquivo implantado e usa parâmetros definidos no próprio web shell, como osc ou anon, para acionar a lógica escondida. O código analisado continha conteúdo codificado em base64 e compactado, uma técnica comum para reduzir legibilidade, evitar inspeção superficial e esconder a funcionalidade real de administradores que encontrem o arquivo. Quando essa camada é resolvida, o comportamento observado inclui a preparação de dois arquivos com extensão .aff. A extensão aparente não correspondia ao conteúdo real: os arquivos continham código PHP e Perl, o que indica tentativa de confundir controles simples baseados em nome de arquivo ou extensão.
A etapa seguinte envolve a execução desses componentes e a limpeza dos artefatos .aff usados no carregamento. A remoção posterior dos arquivos temporários reduz a chance de descoberta por varreduras manuais ou por ferramentas que examinam apenas arquivos recentes em diretórios de upload. Mesmo assim, a sequência deixa rastros úteis: criação e acesso a arquivos PHP em diretórios de upload, parâmetros HTTP incomuns, respostas contendo marcações do grupo, conexões para domínios usados no armazenamento dos componentes e atividade de rede compatível com IRC.
A comunicação de comando e controle usa IRC, um protocolo antigo, simples e ainda encontrado em famílias de bots por sua facilidade de automação. O bot utiliza comandos e mensagens do IRC para receber instruções do operador. A funcionalidade inclui envio de informações por PRIVMSG, interpretação da resposta do controlador e acionamento de rotinas de ataque. Entre as capacidades descritas estão ataques DDoS por UDP e TCP, variantes de flood HTTP, flood IRC CTCP e uso de proxies abertos para concentrar tráfego. Também há capacidade de executar comandos de shell no sistema afetado, o que torna o host comprometido útil tanto como nó de ataque quanto como ponto de controle operacional.
A superfície mais exposta é formada por sites PHP com CMS, extensões, temas ou módulos que aceitam upload de arquivos e não impõem separação forte entre armazenamento de conteúdo e execução de código. O risco aumenta quando diretórios de upload permitem interpretação PHP, quando a aplicação valida apenas a extensão declarada pelo usuário, quando não há renomeação segura do arquivo, ou quando o servidor permite acesso direto ao caminho onde o arquivo foi salvo. A ausência de registro detalhado de uploads e acessos também favorece o atacante, porque o web shell pode permanecer ativo sem produzir alertas óbvios.
O cenário não depende de uma versão específica informada no material analisado. Por isso, a defesa não deve procurar apenas um identificador de CVE ou um plugin determinado. A condição relevante é a combinação de aplicação PHP exposta à internet, funcionalidade de upload e execução indevida de conteúdo carregado. Plataformas de CMS costumam concentrar esse risco porque adicionam extensões de terceiros, bibliotecas antigas e áreas administrativas usadas por múltiplos perfis de usuário. Um invasor que obtenha qualquer caminho para carregar um arquivo interpretável pode estabelecer o primeiro estágio sem precisar comprometer credenciais administrativas, desde que a falha de upload permita o bypass necessário.
Também são relevantes servidores que permitem tráfego de saída irrestrito. A botnet depende de contato com infraestrutura externa para buscar componentes e se comunicar com o controlador IRC. Em redes onde o servidor web pode iniciar conexões arbitrárias para a internet, o comprometimento ganha continuidade e comando remoto. Em redes segmentadas, com egress filtering e bloqueio de protocolos não necessários, a cadeia pode ser interrompida mesmo que o upload inicial tenha sido bem-sucedido.
- Aplicações PHP e CMS com endpoints de upload acessíveis por usuários autenticados ou não autenticados, conforme a falha específica de cada plataforma.
- Diretórios de upload que aceitam execução de PHP ou permitem acesso direto a arquivos recém-carregados por URL pública.
- Servidores web com tráfego de saída liberado para domínios externos, endereços desconhecidos ou canais IRC não justificados pela função do ativo.
- Ambientes sem monitoramento de integridade em arquivos PHP, sem inventário de plugins e sem revisão periódica de permissões no filesystem.
A investigação deve começar pelos logs HTTP do servidor e do proxy reverso. Procure requisições de upload seguidas por acessos diretos a arquivos PHP em diretórios normalmente destinados a imagens, anexos ou mídia. A sequência é importante: criação ou alteração de arquivo, primeira execução via GET, uso de parâmetros incomuns e respostas fora do padrão da aplicação. Parâmetros como osc e anon são exemplos concretos observados, mas a caça não deve depender apenas deles, pois pequenas alterações no web shell podem trocar nomes de variáveis sem mudar a lógica operacional.
No endpoint, sinais úteis incluem arquivos PHP recém-criados em caminhos de upload, arquivos com extensão .aff aparecendo e desaparecendo em curto intervalo, processos do servidor web iniciando interpretadores ou utilitários fora do padrão, e conexões de saída iniciadas pelo usuário do serviço web. A presença de código codificado em base64 dentro de arquivos PHP também merece inspeção, especialmente quando combinada com funções de avaliação dinâmica, descompressão ou execução de comandos. A análise deve preservar evidências antes da remoção, pois timestamps, proprietário do arquivo e caminho de criação ajudam a reconstruir a linha do tempo.
Na rede, o foco deve estar em conexões IRC ou tráfego com características compatíveis, principalmente a partir de servidores web que não têm justificativa operacional para esse protocolo. Também vale revisar DNS histórico e resolução para domínios associados ao armazenamento de componentes, como pkalexeivic[.]com, e relações com infraestrutura como lubrisabana[.]com. O endereço 190[.]145[.]107[.]220 foi observado em registro de ataque e pode ser usado como pivô inicial, mas a defesa deve evitar uma visão estreita baseada em um único indicador. O comportamento de botnet, a execução remota e o padrão de upload são mais resilientes para detecção do que listas estáticas de IPs.
- Requisições HTTP de upload seguidas por acesso a arquivo PHP em diretórios de mídia, anexos, cache ou conteúdo gerado pelo usuário.
- Uso de parâmetros GET incomuns em arquivos PHP recém-criados, incluindo nomes como
osceanonquando aparecerem nos logs. - Criação, execução e remoção de arquivos com extensão
.aff, especialmente quando o conteúdo real for PHP ou Perl. - Conexões de saída do servidor web para canais IRC, domínios recém-observados ou infraestrutura sem relação com a aplicação hospedada.
- Arquivos PHP com cadeias codificadas em base64, lógica compactada ou chamadas que resultem em execução de comandos no sistema.
A contenção deve priorizar a retirada do web shell e o bloqueio do canal de comando antes de uma simples limpeza de arquivos. Isole servidores com sinais de comprometimento, preserve logs HTTP, DNS, proxy, EDR e filesystem, e identifique todos os arquivos modificados no período provável de intrusão. Remover apenas o arquivo visível pode não ser suficiente, porque o operador pode ter implantado componentes adicionais, criado novas rotas de acesso ou usado o host para participar de ataques externos. A análise precisa cobrir webroot, diretórios temporários, áreas de upload, cron jobs, tarefas agendadas e processos iniciados pelo usuário do servidor web.
A correção estrutural exige endurecer o fluxo de upload. Arquivos enviados por usuários devem ser armazenados fora de diretórios executáveis, renomeados por identificadores gerados pelo servidor, validados por conteúdo e não apenas por extensão, e servidos como objetos estáticos. Quando a aplicação precisa aceitar imagens, o processamento deve regravar o arquivo em formato controlado, removendo metadados e impedindo que conteúdo arbitrário seja interpretado como código. Permissões do filesystem devem impedir que o usuário do servidor web escreva em caminhos onde PHP possa ser executado.
Na rede, servidores web devem ter saída restrita ao mínimo necessário. Bloqueio de IRC, validação de DNS, allowlists para atualizações legítimas e inspeção de conexões incomuns reduzem a utilidade do host comprometido para a botnet. Para ambientes com muitos CMS, a resposta deve incluir inventário de versões e extensões, remoção de componentes sem manutenção e revisão de plugins que implementam upload. Como não há uma versão única indicada para correção, o controle mais eficaz é validar a classe de falha em todos os pontos de upload expostos.
Após a contenção, a organização deve revisar logs para determinar se o servidor participou de DDoS, executou comandos remotos ou tentou alcançar outros ativos. A capacidade de execução de comandos significa que a investigação não deve se limitar à aplicação web. Verifique credenciais locais, chaves de acesso armazenadas no servidor, arquivos de configuração do CMS e permissões de banco de dados. Quando houver segredos no host, a rotação deve ser considerada, especialmente se os logs indicarem leitura de arquivos, execução de comandos de enumeração ou acesso a configurações sensíveis.
- Desabilitar execução de PHP em diretórios de upload e mover anexos para armazenamento não executável.
- Revisar todos os endpoints de upload para validação por conteúdo, renomeação segura e bloqueio de extensões interpretáveis.
- Bloquear tráfego IRC e restringir conexões de saída de servidores web a destinos estritamente necessários.
- Procurar e remover web shells, artefatos
.aff, arquivos PHP anômalos e processos iniciados pelo usuário do serviço web. - Rotacionar segredos presentes no servidor quando houver indício de execução de comandos ou acesso a arquivos de configuração.
- Aplicar atualizações do CMS, temas, plugins e bibliotecas, removendo componentes abandonados ou sem necessidade operacional.
0 Comentários