> [!warning] Aviso Importante
> Este playbook é um ponto de partida. Deve ser revisado, testado e adaptado ao ambiente da sua organização. Não substitui um plano formal de Incident Response. Queries e comandos devem ser válidados em ambiente de homologação antes do uso em produção. Itens marcados com `# [VALIDAR NO SEU AMBIENTE]` exigem ajuste obrigatório antes do uso operacional.
## Visão Geral
Uma webshell é um script malicioso implantado em um servidor web que concede ao atacante acesso remoto persistente via requisições HTTP normais — tornando o tráfego de comando e controle práticamente indistinguível de tráfego legítimo à primeira vista. O comprometimento de aplicações web via [[t1190-exploit-public-facing-application|T1190 — Exploit Public-Facing Application]] seguido de implantação de webshell via [[t1505-003-web-shell|T1505.003 — Web Shell]] é um dos vetores de acesso inicial mais explorados por atores de ameaça avançados, especialmente aqueles com motivação de espionagem.
**Por que este playbook é crítico:**
- Webshells sobrevivem a reinicializações de servidor, rotação de credenciais e até reinstalações parciais do sistema operacional
- Atores como [[g0125-silk-typhoon]] exploram vulnerabilidades ProxyShell/ProxyLogon no Microsoft Exchange (CVE-2021-34473, CVE-2021-26855) para implantar webshells em servidores de e-mail corporativo
- [[g1017-volt-typhoon]] utiliza webshells para manter acesso de longa duração (dwell time medido em meses) em infraestrutura crítica
- No Brasil, portais `.gov.br`, sistemas de universidades federais e aplicações corporativas em Apache Tomcat / Nginx / IIS são alvos frequentes
- Webshells em PHP, ASPX e JSP podem ser extremamente compactas (uma única linha de código) e facilmente camufladas como arquivos legítimos
- O tráfego C2 ocorre via HTTP/HTTPS padrão - bypassa firewalls e proxies que não realizam deep packet inspection
**Notas relacionadas:** [[g0125-silk-typhoon]] · [[g1017-volt-typhoon]] · [[t1505-003-web-shell|T1505.003 — Web Shell]] · [[t1190-exploit-public-facing-application|T1190 — Exploit Public-Facing Application]] · [[t1059-001-powershell|T1059.001 — PowerShell]] · [[t1059-004-unix-shell|T1059.004 — Unix Shell]] · [[t1105-ingress-tool-transfer|T1105 — Ingress Tool Transfer]] · [[t1071-001-web-protocols|T1071.001 — Web Protocols]] · [[t1078-valid-accounts|T1078 — Valid Accounts]]
---
## Fluxo de Resposta
```mermaid
flowchart TD
A(["🚨 Alerta: Webshell Detectada"]) --> B{Confirmar Comprometimento}
B -->|IoCs confirmados| C[DECLARAR INCIDENTE P1]
B -->|Incerto| D["Análise Forense Rápida<br/>20 minutos"]
D --> C
C --> E[Notificar CISO + On-call IR]
E --> F{"Acesso ainda<br/>ativo?"}
F -->|Sim| G["Bloquear IP/Range<br/>no WAF e Firewall"]
F -->|"Não/Desconhecido"| H["Monitorar e Coletar<br/>Evidências"]
G --> I[CONTENÇÃO]
H --> I
I --> I1["Isolar Servidor Web<br/>em VLAN de Quarentena"]
I1 --> I2["Preservar Logs IIS/Apache<br/>Nginx antes de rotacionar"]
I2 --> I3["Capturar Imagem de Disco<br/>e RAM do Servidor"]
I3 --> J[COLETA FORENSE]
J --> J1["Localizar Todos os<br/>Arquivos Suspeitos"]
J1 --> J2["Analisar Logs de Acesso<br/>para TTPs e IoCs"]
J2 --> J3["Mapear Comandos<br/>Executados via Shell"]
J3 --> K[ERRADICAÇÃO]
K --> K1["Remover Webshells<br/>e Backdoors"]
K1 --> K2["Identificar e Corrigir<br/>Vulnerabilidade Explorada"]
K2 --> K3["Auditar Todos os<br/>Arquivos Web"]
K3 --> L[RECUPERAÇÃO]
L --> L1["Restaurar de Backup<br/>ou Reimaging"]
L1 --> L2["Implementar WAF<br/>e FIM"]
L2 --> L3["Monitoramento<br/>Intensivo 30 dias"]
L3 --> M(["✅ Incidente Encerrado"])
style A fill:#ff4444,color:#fff
style C fill:#ff6600,color:#fff
style M fill:#00aa44,color:#fff
style I fill:#ffaa00,color:#000
style K fill:#0066cc,color:#fff
style L fill:#006633,color:#fff
```
---
## Diagrama de Comúnicação
```mermaid
sequenceDiagram
participant SOC as SOC Analyst
participant IR as IR Lead
participant CISO as CISO
participant DevOps as DevOps/AppSec
participant Legal as Jurídico/DPO
participant Exec as Executivos
participant CERT as CERT.br / CTIR.gov
SOC->>IR: T+0min: Webshell confirmada — servidor comprometido
IR->>CISO: T+10min: Declaração de incidente P1
IR->>DevOps: T+15min: Isolar servidor — não reiniciar
Note over IR,DevOps: Preservar evidências antes de qualquer ação
CISO->>Exec: T+30min: Briefing inicial — escopo e serviços impactados
IR->>Legal: T+30min: Avaliação LGPD — dados pessoais acessados?
DevOps->>IR: T+1h: Inventário de arquivos suspeitos no servidor
IR->>CISO: T+2h: Relatório de contenção — TTPs identificados
Legal->>CISO: T+3h: Parecer regulatório LGPD/ANPD
IR->>CERT: T+24h: Notificação ao CERT.br (se infraestrutura crítica)
IR->>CISO: T+48h: Relatório de erradicação completo
IR->>Exec: T+72h: Relatório preliminar de post-mortem
```
---
## Indicadores de Comprometimento
> [!danger] Atenção
> Detectar webshells cedo é crucial. Muitos grupos mantêm acesso por semanas ou meses antes de agir. Priorize a identificação de todos os arquivos implantados — uma webshell não removida anula toda a erradicação.
### Fase 1 - Exploração da Aplicação Web
Os vetores de exploração mais comuns para implantação de webshells:
1. **Vulnerabilidades de upload irrestrito de arquivos** - formulários que permitem upload de `.php`, `.aspx`, `.jsp` sem válidação de tipo MIME no servidor
2. **Remote Code Execution (RCE)** em frameworks desatualizados - Apache Struts, Drupal (Drupalgeddon), WordPress com plugins vulneráveis
3. **SQL Injection com escrita de arquivo** - instrução OUTFILE para gravar webshell diretamente no diretório web
4. **Exploração de Exchange** - ProxyShell (CVE-2021-34473 + CVE-2021-34523 + CVE-2021-31207) e ProxyLogon (CVE-2021-26855 + CVE-2021-27065) explorados massivamente por [[g0125-silk-typhoon]] e afiliados
5. **LFI/RFI** - Local/Remote File Inclusion que permitem execução de código arbitrário
6. **Deserialização insegura** - Java, .NET e PHP com bibliotecas de deserialização vulneráveis
**Indicadores de exploração inicial nos logs de acesso:**
```
Padrões suspeitos em logs IIS/Apache/Nginx:
- POST para caminhos não convencionais (/owa/auth/x.js, /aspnet_client/shell.aspx)
- Requisições com parâmetros longos (> 1000 chars) indicando tentativa de injection
- User-Agents genéricos (python-requests, curl) em horários anômalos
- Respostas HTTP 200 em endpoints que deveriam retornar 404 ou 403
- Múltiplas requisições POST de um IP para o mesmo recurso em menos de 1 segundo
```
### Fase 2 - Implantação da Webshell
| Indicador | Descrição | Nível de Risco |
|-----------|-----------|---------------|
| Novos arquivos `.php`, `.aspx`, `.jsp`, `.jspx` em diretórios web | Especialmente em subdiretórios não criados pelo deploy | Crítico |
| China Chopper (ASPX/PHP de 1 linha) | Webshell extremamente compacta e difícil de detectar visualmente | Crítico |
| Arquivos com nomes que imitam arquivos legítimos | `web.config.aspx`, `error.php`, `login.bak.php` | Alto |
| Timestamps de criação discrepantes | Arquivo criado fora da janela de deploy ou manutenção | Alto |
| Hash MD5/SHA256 não mapeado no inventário de deploy | Arquivo não presente na árvore de baseline | Crítico |
| Permissões de arquivo anômalas em servidor Linux | Arquivo `.php` com permissões de escrita para outros | Médio |
**Padrões de webshell documentados publicamente (referência para regras YARA e detecção):**
```
Padrões PHP suspeitos — funções perigosas combinadas com entradas do usuário:
- eval() + base64_decode() com dados de $_POST ou $_REQUEST
- system(), passthru(), shell_exec() recebendo parâmetros via GET/POST
- assert() com strings de entrada do usuário
Padrões ASPX (IIS/Exchange):
- eval(Request.Item["parametro"],"unsafe")
- HttpContext.Current.Request com execução de código dinâmico
Padrões JSP (Tomcat/JBoss):
- Runtime.getRuntime() com parâmetro de request HTTP
- ProcessBuilder recebendo parâmetro da requisição
```
### Fase 3 - Pós-Exploração
Após implantar a webshell, o atacante tipicamente executa ações via [[t1059-001-powershell|T1059.001]] ou [[t1059-004-unix-shell|T1059.004]]:
| Ação | Linux | Windows |
|------|-------|---------|
| Reconhecimento | `id`, `whoami`, `uname -a` | `whoami`, `systeminfo` |
| Enumeração de rede | `ifconfig`, `netstat -an` | `ipconfig /all`, `netstat -ano` |
| Escalada de privilégio | `sudo -l`, exploit de kernel | `whoami /priv`, `net localgroup administrators` |
| Download de ferramentas via [[t1105-ingress-tool-transfer\|T1105]] | curl/wget para /tmp | certutil, Invoke-WebRequest |
| Movimento lateral | `ssh user@host`, credential dump | wmiexec, psexec, mimikatz |
| Persistência adicional | Crontab, `.bashrc`, SSH keys | Scheduled Tasks, serviços, registry Run keys |
| Exfiltração via [[t1071-001-web-protocols\|T1071.001]] | tar + POST para C2 | Compressão + HTTP PUT |
---
## Ferramentas Recomendadas
### Detecção e Análise de Webshells
| Ferramenta | Uso | Comando Chave |
|------------|-----|---------------|
| **NeoPI** | Detecta webshells por análise estatística (entropia, IC) | `python neopi.py /var/www/html -a` |
| **PHP Malware Finder** | Detecta webshells PHP com YARA + heurísticas | `./phpmalwarefinder /var/www/html` |
| **THOR Lite** | Scanner de IOC/YARA para servidores comprometidos | `thor-lite-linux -p /var/www/html` |
| **ClamAV** | Antivírus com assinaturas para webshells conhecidas | `clamscan -r /var/www/html --log=/tmp/clamav.log` |
| **Velociraptor** | Coleta forense remota em escala | `velociraptor artifacts collect Linux.Detection.Webshell` |
| **Loki** | Scanner de IoC com regras YARA para webshells | `python loki.py -p /var/www/html` |
### Forense de Servidor Web
| Ferramenta | Uso | Comando/Exemplo |
|------------|-----|----------------|
| **Volatility 3** | Análise de memória - identificar processos filhos de webserver | `python3 vol.py -f mem.raw linux.pstree` |
| **KAPE** | Triage forense rápida (Windows/IIS) | `kape.exe --tsource C: --tdest D:\evidence --target IISLogs` |
| **GoAccess** | Análise visual de logs de acesso HTTP | `goaccess /var/log/nginx/access.log -o report.html` |
| **LogParser** | Parse de logs IIS (Windows) | `logparser "SELECT * FROM ex*.log WHERE cs-uri-stem LIKE '%.aspx%'" -i:iisw3c` |
| **Magnet RAM Capture** | Captura de memória RAM (Windows) | `MagnetRAMCapture.exe /accepteula /go` |
### Rede e Tráfego
| Ferramenta | Uso |
|------------|-----|
| **Wireshark** | Analisar tráfego capturado - filtrar `http.request.method == "POST"` para endpoints suspeitos |
| **Zeek (Bro)** | Análise de logs de rede - detectar padrões de C2 via HTTP |
| **ModSecurity** | WAF open-source - regras OWASP CRS para bloquear webshells em tempo real |
| **tcpdump** | Captura de tráfego em tempo real nas portas 80 e 443 |
---
## Queries de Detecção
### KQL - Microsoft Sentinel - Criação de Arquivo em Diretório Web (Windows/IIS)
```kql
// Detecta criação de arquivos executáveis em diretórios IIS por processos não autorizados
DeviceFileEvents
| where ActionType == "FileCreated"
| where FolderPath has_any (@"inetpub\wwwroot", @"inetpub\scripts", @"aspnet_client")
| where FileName endswith_cs ".aspx"
or FileName endswith_cs ".asp"
or FileName endswith_cs ".php"
or FileName endswith_cs ".jsp"
| where InitiatingProcessFileName !in~ ("msdeploy.exe", "devenv.exe", "robocopy.exe")
| project Timestamp, DeviceName, FolderPath, FileName,
InitiatingProcessFileName, InitiatingProcessAccountName
| order by Timestamp desc
```
### KQL - Microsoft Sentinel - Processos Filhos de w3wp.exe (IIS Worker Process)
```kql
// w3wp.exe não deve spawnar cmd.exe, powershell.exe ou certutil.exe em operação normal
DeviceProcessEvents
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "powershell_ise.exe",
"certutil.exe", "wscript.exe", "cscript.exe",
"rundll32.exe", "regsvr32.exe", "mshta.exe",
"curl.exe", "wget.exe", "bitsadmin.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc
```
### KQL - Microsoft Sentinel - Comandos de Reconhecimento a partir de Webserver
```kql
// Detecta comandos de reconhecimento executados a partir de processos de webserver
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("w3wp.exe", "php-cgi.exe", "httpd.exe", "java.exe")
| where ProcessCommandLine has_any (
"whoami", "ipconfig", "systeminfo", "net user", "net group",
"nltest", "quser", "tasklist", "netstat", "arp -a", "route print"
)
| project Timestamp, DeviceName, AccountName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc
```
### SPL - Splunk - Processos Filhos de Webserver (Linux)
```spl
index=linux sourcetype=syslog
(parentprocess="apache2" OR parentprocess="httpd" OR parentprocess="nginx" OR parentprocess="php-fpm")
(process="bash" OR process="sh" OR process="python*" OR process="perl"
OR process="wget" OR process="curl" OR process="nc" OR process="ncat")
| stats count by host, parentprocess, process, cmd
| sort -count
```
### SPL - Splunk - POST com Resposta 200 em Recurso Suspeito (Logs de Acesso)
```spl
index=web sourcetype="access_combined"
method=POST status=200
(uri_path="*.php" OR uri_path="*.aspx" OR uri_path="*.jsp")
| eval bytes_int=tonumber(bytes)
| where bytes_int > 500
| stats count avg(bytes_int) AS avg_response_size by uri_path, clientip
| where count > 5
| sort -count
```
### SPL - Splunk - Upload de Arquivo com Extensão Executável
```spl
index=web sourcetype="access_combined"
method=POST
(uri_path="*upload*" OR uri_path="*file*" OR uri_path="*attach*" OR uri_path="*import*")
| rex field=uri_query "filename=(?<uploaded_filename>[^&]+)"
| where match(uploaded_filename, "\.(php|aspx|asp|jsp|jspx|phtml|php5|shtml)
quot;)
| stats count by clientip, uri_path, uploaded_filename, http_user_agent
| sort -count
```
### SPL - Splunk - Download de Ferramentas via Webshell (Windows EventCode 4688)
```spl
index=windows EventCode=4688
(CommandLine="*certutil*-urlcache*" OR CommandLine="*certutil*-decode*"
OR CommandLine="*Invoke-WebRequest*" OR CommandLine="*bitsadmin*/transfer*")
ParentImage IN ("*w3wp.exe*", "*httpd.exe*", "*php-cgi.exe*", "*tomcat*.exe*")
| table _time, ComputerName, User, CommandLine, ParentImage
| sort -_time
```
---
## Contenção
> [!danger] Execute na ordem exata — não reinicie o servidor antes de capturar evidências em memória
### Checklist de Contenção
- [ ] **T+0** - Confirmar via logs e EDR: webshell está ativa? Comandos sendo executados no momento?
- [ ] **T+5min** - Declarar incidente P1 e acionar IR Lead e CISO
- [ ] **T+10min** - Capturar imagem de memória RAM do servidor **antes** de qualquer outra ação - LiME (Linux) ou Magnet RAM Capture (Windows)
- [ ] **T+15min** - Preservar logs de acesso: copiar `/var/log/nginx/`, `/var/log/apache2/`, logs IIS para storage isolado e imutável
- [ ] **T+20min** - Isolar servidor em VLAN de quarentena - manter ligado para preservar evidências voláteis
- [ ] **T+25min** - Bloquear IPs de origem das requisições maliciosas no WAF e firewall perimetral
- [ ] **T+30min** - Desabilitar o virtual host ou aplicação afetada (sem derrubar todo o servidor, se possível)
- [ ] **T+35min** - Identificar todos os arquivos criados/modificados na janela de comprometimento estimada
- [ ] **T+40min** - Verificar se há outros servidores comprometidos com o mesmo vetor de ataque
- [ ] **T+45min** - Revogar credenciais de contas de serviço usadas pelo servidor web
- [ ] **T+1h** - Acionar DevOps para inventário completo de arquivos via comparação de hash com baseline de deploy
- [ ] **T+1h** - Acionar jurídico/DPO: banco de dados acessível pelo servidor comprometido contém dados pessoais?
### Templaté - Notificação para Executivos (T+30min)
```
DATA: [data/hora]
CLASSIFICAÇÃO: CONFIDENCIAL — INCIDENTE DE SEGURANÇA
SUMÁRIO
Identificamos um comprometimento ativo em nosso servidor web.
Uma webshell foi implantada por agente externo não autorizado.
SITUAÇÃO ATUAL
- Servidor afetado: [hostname/IP]
- Jánela de comprometimento: [período estimado]
- Dados possívelmente acessados: [avaliação preliminar]
- Serviços impactados: [lista]
- Contenção: [em andamento / concluída às HH:MM]
AÇÕES EM CURSO
- Servidor isolado em rede de quarentena
- Evidências forenses preservadas
- Investigação em andamento
PRÓXIMOS PASSOS
- Próximo updaté em: [horário]
- Estimativa de recuperação: [timeframe]
- Avaliação de notificação regulatória: em andamento
PONTO DE CONTATO: [nome, telefone]
```
> [!danger] Use canal out-of-band (Signal, telefone) — o e-mail corporativo pode estar comprometido
---
## Erradicação
### Checklist de Erradicação
- [ ] Identificar **todos** os arquivos webshell - usar múltiplos scanners (NeoPI + THOR Lite + ClamAV)
- [ ] Verificar diretórios não óbvios: diretório de uploads, arquivos de templaté, pastas de cache, diretórios temporários
- [ ] Comparar hash de todos os arquivos web com o inventário de deploy (pipeline CI/CD)
- [ ] Identificar a vulnerabilidade explorada no acesso inicial - sem corrigir o vetor, a erradicação é incompleta
- [ ] Aplicar patch ou implementar mitigação temporária (WAF rule) para a vulnerabilidade explorada
- [ ] Verificar persistência adicional: crontabs, serviços, chaves SSH não autorizadas, arquivos de perfil de shell modificados
- [ ] Verificar se há reverse shells ativos: processos filhos do webserver com conexões externas estabelecidas
- [ ] Auditar banco de dados: o atacante executou queries? Criou usuários? Exfiltrou dados?
- [ ] Remover todas as webshells identificadas e documentar hashes SHA256 de cada artefato
- [ ] Verificar integridade de arquivos de configuração do servidor (httpd.conf, nginx.conf, web.config)
- [ ] Resetar credenciais de contas de serviço, banco de dados e qualquer credencial acessível pelo servidor comprometido
- [ ] Validar que o repositório de código-fonte não foi comprometido (supply chain check)
### Comandos de Investigação Forense
```bash
# Encontrar arquivos PHP modificados nas últimas 72 horas [VALIDAR NO SEU AMBIENTE]
find /var/www/html -name "*.php" -mtime -3 -ls
# Gerar hash SHA256 de todos os arquivos PHP para comparação com baseline
find /var/www/html -name "*.php" -exec sha256sum {} \; > /tmp/current_hashes.txt
diff /tmp/baseline_hashes.txt /tmp/current_hashes.txt
# Verificar conexões de rede abertas por processos do webserver
ss -tlnp | grep -E "(apache|nginx|httpd|php)"
# Listar todos os processos filhos do servidor web
ps auxf | grep -A 20 "apache\|nginx\|httpd\|php-fpm"
```
---
## Recuperação
### Checklist de Recuperação
- [ ] Definir estratégia: reimaging completo (recomendado para comprometimento profundo) ou restauração de arquivos específicos
- [ ] Se reimaging: provisionar novo servidor a partir de imagem limpa e fazer deploy via pipeline CI/CD auditado
- [ ] Se restauração parcial: válidar integridade de cada arquivo restaurado com hash do repositório de origem
- [ ] Aplicar todos os patches de segurança pendentes **antes** de reconectar à rede de produção
- [ ] Implementar ou fortalecer WAF com regras OWASP CRS (ModSecurity, AWS WAF, Cloudflare)
- [ ] Configurar File Integrity Monitoring (FIM) em todos os diretórios web: OSSEC, Wazuh, Tripwire
- [ ] Habilitar logging detalhado: acesso, erro, slow log - e encaminhar para SIEM em tempo real
- [ ] Implementar Content Security Policy (CSP) e outros headers de segurança HTTP
- [ ] Revisar e restringir permissões de diretórios web: webserver não deve ter permissão de escrita em diretórios de código
- [ ] Implementar separação entre diretório de uploads e código executável
- [ ] Configurar alertas no SIEM específicos para IoCs de webshell
- [ ] Realizar scan de vulnerabilidades (DAST) na aplicação antes de retornar ao ar
- [ ] Documentar escopo de dados possívelmente acessados para avaliação regulatória LGPD
### Hardening Pós-Incidente (Nginx)
```nginx
# Bloquear execução de PHP em diretórios de upload (Nginx) [VALIDAR NO SEU AMBIENTE]
location ~* /uploads/.*\.(php|aspx|asp|jsp)$ {
deny all;
return 403;
}
# Headers de segurança HTTP obrigatórios
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "default-src 'self'" always;
add_header X-XSS-Protection "1; mode=block" always;
```
### Notificação LGPD / ANPD
Se dados pessoais foram acessados ou exfiltrados, a notificação à **ANPD** deve ocorrer em prazo razoável (máximo 72h após confirmação) conforme Art. 48 da LGPD. Consulte o DPO antes de qualquer comunicação externa. Para infraestrutura pública (`.gov.br`), notificar também o **CTIR.gov** e o **CERT.br**.
---
## Lições Aprendidas - Templaté de Post-Mortem
### Cronologia do Incidente
| Evento | Data/Hora | Responsável |
|--------|-----------|-------------|
| Primeiro acesso malicioso (retroativo) | | |
| Implantação da webshell | | |
| Primeiro comando executado via webshell | | |
| Alerta gerado no SIEM/EDR/WAF | | |
| Confirmação de comprometimento | | |
| Declaração de incidente P1 | | |
| Isolamento do servidor | | |
| Erradicação concluída | | |
| Recuperação completa | | |
### Métricas de Impacto
| Métrica | Valor |
|---------|-------|
| Tempo de dwell (presença antes da detecção) | |
| MTTD - Mean Time to Detect | |
| MTTC - Mean Time to Contain | |
| MTTR - Mean Time to Recover | |
| Número de webshells encontradas | |
| Dados possívelmente exfiltrados (GB / registros) | |
| Número de sistemas atingidos por movimento lateral | |
### Questões Obrigatórias
1. Qual foi a vulnerabilidade explorada no acesso inicial?
2. Por quanto tempo a webshell esteve ativa antes da detecção?
3. O atacante acessou o banco de dados? Quais dados foram expostos?
4. Houve movimento lateral para outros sistemas internos?
5. O FIM (File Integrity Monitoring) estava configurado? Por que não detectou?
6. O WAF estava ativo? As regras cobriam o vetor explorado?
7. O playbook foi eficaz? O que precisa ser atualizado?
### Melhorias Recomendadas
- [ ] Implementar File Integrity Monitoring (Wazuh/OSSEC) em 100% dos servidores web
- [ ] Configurar WAF com regras OWASP CRS em modo bloqueio (não apenas detecção)
- [ ] Habilitar logging detalhado de processos em servidores Linux (auditd) e Windows (Sysmon)
- [ ] Implementar pipeline CI/CD com verificação de hash de todos os artefatos de deploy
- [ ] Restringir permissões: webserver nunca deve ter escrita em diretórios de código
- [ ] Scan de vulnerabilidades (DAST) semanal nas aplicações públicas
- [ ] Separar ambientes: banco de dados não deve ser acessível diretamente do servidor web
---
## Contexto LATAM/Brasil
> [!info] Relevância Regional
> Webshells são um vetor predominante em ataques contra infraestrutura brasileira e latino-americana, especialmente contra alvos governamentais e acadêmicos.
**Alvos prioritários no Brasil:**
- **Portais `.gov.br`** - Sistemas de prefeituras, autarquias e ministérios frequentemente executam versões desatualizadas de Joomla, Drupal e WordPress, com plugins vulneráveis e sem manutenção regular
- **Universidades federais (UFMG, USP, UNICAMP, UFSC)** - Servidores Apache com PHP legacy, Moodle desatualizado, sistemas acadêmicos proprietários sem ciclo de patch
- **Setor financeiro** - APIs públicas e portais de aténdimento com frameworks Java (Struts, Spring) vulneráveis
- **Provedores de saúde (SUS/DATASUS)** - Aplicações com décadas de legado técnico e superfície de ataque significativa
**Campanhas documentadas com impacto LATAM:**
- **[[g0125-silk-typhoon]]** explorou ProxyShell/ProxyLogon em servidores Exchange de órgãos governamentais brasileiros em 2021, implantando webshells ASPX para acesso persistente a e-mails institucionais
- Grupos de hacktivismo alinhados politicamente utilizam webshells em ataques de defacement e exfiltração de dados de portais `.gov.br` durante períodos eleitorais e de crise política
- **[[g1017-volt-typhoon]]** mantém foco em infraestrutura crítica - a técnica de webshells de longa duração (dwell time de meses) é uma assinatura do grupo, com potencial impacto em setores de energia e telecomúnicações no Brasil
**Características específicas do ambiente brasileiro:**
- Alta prevalência de WordPress com plugins desatualizados (WooCommerce, Elementor, Contact Form 7 com vulnerabilidades conhecidas)
- Servidores PHP 5.x ainda em produção em pequenas prefeituras e autarquias - sem suporte oficial desde 2018
- Apache Tomcat sem autenticação no manager exposto à internet em sistemas legados
- Sistemas desenvolvidos internamente sem processos formais de SDLC seguro (SAST/DAST)
- Baixa adoção de WAF em organizações de médio porte - a maioria depende exclusivamente de firewall de rede
**Recomendação específica:** Organizações brasileiras devem monitorar o **CTIR.gov** (Centro de Tratamento de Incidentes de Redes do Governo) e o **CERT.br** para alertas sobre webshells em domínios `.gov.br`. O CERT.br mantém estatísticas de incidentes reportados e boletins de segurança relevantes para o contexto nacional.
---
## Referências
- [[t1505-003-web-shell|T1505.003 - Web Shell]] - técnica MITRE ATT&CK de persistência via webshell
- [[t1190-exploit-public-facing-application|T1190 - Exploit Public-Facing Application]] - vetor de acesso inicial
- [[t1059-001-powershell|T1059.001 - PowerShell]] - execução pós-exploração em ambientes Windows
- [[t1059-004-unix-shell|T1059.004 - Unix Shell]] - execução pós-exploração em ambientes Linux
- [[t1105-ingress-tool-transfer|T1105 - Ingress Tool Transfer]] - download de ferramentas via webshell
- [[t1071-001-web-protocols|T1071.001 - Web Protocols]] - C2 camuflado em tráfego HTTP/HTTPS legítimo
- [[t1078-valid-accounts|T1078 - Valid Accounts]] - uso de credenciais roubadas em escalada pós-webshell
- [[g0125-silk-typhoon]] - grupo APT que explorou ProxyShell/ProxyLogon em Exchange globalmente
- [[g1017-volt-typhoon]] - grupo APT com foco em persistência de longo prazo via webshells em infraestrutura crítica
- [CISA Advisory AA21-062A - HAFNIUM Targeting Exchange Servers](https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-062a)
- [CISA Advisory AA24-038A - Volt Typhoon Pre-Positioning](https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a)
- [NSA/CISA - Mitigating Web Shells (GitHub)](https://github.com/nsacyber/Mitigating-Web-Shells)
- [CERT.br - Estatísticas de Incidentes](https://www.cert.br/stats/)
- [OWASP - File Upload Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html)
---
*Última revisão: 2026-03-26 | Próxima revisão recomendada: 2026-09-26*