# T1499.004 - Application or System Exploitation ## Descrição A sub-técnica **T1499.004 - Application or System Exploitation** representa uma das formas mais sofisticadas de ataque de negação de serviço (DoS) do catálogo MITRE ATT&CK. Ao contrário de ataques volumétricos que simplesmente inundam a rede com tráfego, esta técnica explora falhas específicas em aplicações ou sistemas operacionais para forçar travamentos, reinicializações ou estados de falha persistente. Adversários identificam e exploram vulnerabilidades - sejam elas conhecidas (CVEs públicados) ou zero-day - com o objetivo de derrubar serviços críticos. Quando um sistema trava repetidamente, mesmo que tenha mecanismos de reinicialização automática (`systemd`, `supervisord`, `Windows Services`), o serviço pode ser re-explorado a cada reinicialização, criando um ciclo de **Negação de Serviço Permanente (PDoS)**. Esta técnica é categorizada dentro da tática [[_impact|Impact]] e é sub-técnica de [[t1499-endpoint-denial-of-service|T1499 - Endpoint Denial of Service]]. Diferencia-se das sub-técnicas volumétricas porque requer conhecimento técnico profundo da aplicação alvo e é mais difícil de mitigar apenas com controles de rede. O impacto vai além da indisponibilidade: um crash provocado pode desencadear efeitos colaterais graves, como [[t1485-data-destruction|destruição de dados em disco]], [[t1495-firmware-corruption|corrupção de firmware]] em sistemas embarcados ou [[t1489-service-stop|interrupção definitiva de serviços]]. Em infraestruturas críticas (energia, saúde, financeiro), esses efeitos podem ter consequências catastróficas. O malware [[s0604-industroyer|Industroyer]] (também conhecido como Crashoverride), responsável pelo apagão na Ucrânia em 2016, exemplifica o uso desta técnica contra sistemas de controle industrial (ICS/SCADA). O software enviava comandos maliciosos para substações elétricas, explorando protocolos legítimos de forma a provocar falhas no equipamento. --- ## Como Funciona A exploração para DoS funciona em múltiplas etapas técnicas: **1. Reconhecimento de Vulnerabilidades** O adversário levanta informações sobre a pilha tecnológica do alvo - versões de software, bibliotecas, serviços expostos. Ferramentas como Shodan, Censys e OSINT são utilizadas para identificar versões desatualizadas. Scanners especializados (Nessus, Qualys, OpenVAS) podem ser usados se o adversário já tiver acesso interno. **2. Identificação ou Desenvolvimento do Exploit** O atacante busca CVEs conhecidos para as versões identificadas, ou desenvolve um exploit próprio (zero-day). Exploits de DoS tipicamente causam: - **Buffer overflow** - escrita além dos limites de memória alocada, corrompendo o heap ou stack - **Null pointer dereference** - referência a endereço de memória inválido, causando segfault - **Integer overflow** - cálculos que excedem o tamanho de variáveis, gerando comportamento indefinido - **Use-after-free** - acesso a memória já liberada, corrompendo estruturas internas - **Infinite loop / resource exhaustion** - consumo progressivo de CPU, memória ou descritores de arquivo **3. Entrega do Payload** Dependendo da superfície de ataque, o exploit pode ser entregue via: - Requisição HTTP/HTTPS malformada para aplicações web - Pacote de rede especialmente crafted para serviços de rede (DNS, SMB, RDP) - Arquivo malicioso (PDF, Office, imagem) que aciona o crash ao ser processado - Input malicioso via API REST ou endpoint GraphQL **4. Exploração e Crash** O exploit aciona a vulnerabilidade, causando o travamento da aplicação ou do kernel. Em sistemas com supervisão automática, o processo é reiniciado - mas o adversário pode acionar o exploit novamente de forma automática ou semiautomática. **5. Manutenção do Estado DoS** Para um DoS persistente, o adversário pode automatizar o envio do exploit em loop, garantindo que a aplicação nunca permaneça operacional por tempo suficiente para aténder usuários legítimos. --- ## Attack Flow ```mermaid graph TB A[Reconhecimento da pilha tecnológica] --> B[Identificação de CVEs ou desenvolvimento de zero-day] B --> C[Desenvolvimento ou adaptação do exploit] C --> D{Vetor de entrega} D --> E[Rede - pacote crafted] D --> F[Web - requisição malformada] D --> G[Arquivo - input malicioso] E --> H[Exploração da vulnerabilidade] F --> H G --> H H --> I[Crash da aplicação ou kernel] I --> J{Mecanismo de reinicialização?} J -- Sim --> K[Re-exploração automática em loop] K --> I J -- Não --> L[Negação de Serviço Permanente PDoS] I --> M[Efeitos colaterais] M --> N[Destruição de dados - T1485] M --> O[Corrupção de firmware - T1495] M --> P[Interrupção de serviços - T1489] ``` --- ## Exemplos de Uso ### Industroyer / Crashoverride - Ataques à Rede Elétrica Ucraniana (2016) O malware [[s0604-industroyer|Industroyer]], atribuído ao grupo Sandworm (associado ao GRU russo), foi projetado específicamente para explorar protocolos industriais legítimos (IEC 101, IEC 104, IEC 61850, OPC DA) de forma a forçar falhas em equipamentos de subprestação elétrica. O componente de "wiper" do Industroyer sobrescreva registros de configuração, tornando os sistemas inoperantes mesmo após reinicialização. O ataque resultou em um apagão de aproximadamente 1 hora que afetou centenas de milhares de pessoas em Kiev. ### Exploração de Vulnerabilidades em Servidores Web (CVE amplo) Grupos APT e atores de ransomware frequentemente exploram vulnerabilidades em servidores web (Apache, Nginx, IIS) ou frameworks de aplicação (Log4j, Spring, Struts) para provocar crashes como primeiro passo de um comprometimento maior. CVEs como [[cve-2021-44228|CVE-2021-44228]] (Log4Shell) e [[cve-2021-26855|CVE-2021-26855]] (ProxyLogon/Exchange) foram explorados para diversas finalidades, incluindo DoS. ### Exploração de Vulnerabilidades ICS/SCADA Sistemas de controle industrial possuem superfícies de ataque amplas: CLPs (Controladores Lógicos Programáveis), HMIs, historiadores de dados. Adversários motivados por sabotagem (grupos patrocinados por estados-nação) investem em desenvolver exploits para esses sistemas, que frequentemente rodam software desatualizado sem patches regulares. ### Crash de Aplicações Financeiras No contexto de [[financial|setor financeiro]], exploits direcionados a sistemas de trading de alta frequência (HFT) ou sistemas de core banking podem ter impacto massivo. Um crash de poucos minutos pode causar prejuízos de milhões de reais em perdas de transações e danos reputacionais. --- ## Detecção ### Indicadores Comportamentais - Picos anômalos de uso de CPU/memória seguidos de crash - Reinicializações repetidas de processos críticos em curto intervalo - Logs de `segfault`, `access violation` ou `OOM killer` acionados - Presença de entradas anômalas em logs de aplicação imediatamente antes do crash - Tráfego de rede com payloads malformados ou fora do padrão esperado ### Sigma Rule - Reinicialização Repetida de Processo ```yaml title: Repeated Process Crash and Restart Indicating Exploitation DoS status: experimental logsource: category: process_creation product: windows detection: selection: EventID: 7031 Channel: System filter_normal: Service: - 'Windows Updaté' - 'Windows Defender' condition: selection and not filter_normal level: high tags: - attack.impact - attack.t1499.004 falsepositives: - Serviços legítimos reiniciando após atualização - Falhas de hardware não relacionadas a ataques ``` ### Sigma Rule - Crash de Aplicação Web (Linux) ```yaml title: Web Application Crash Indicating Possible Exploitation for DoS status: experimental logsource: category: syslog product: linux detection: selection: message|contains: - 'segfault' - 'Killed process' - 'Out of memory' - 'core dumped' filter_webserver: message|contains: - 'nginx' - 'apache2' - 'httpd' - 'tomcat' condition: selection and filter_webserver level: high tags: - attack.impact - attack.t1499.004 ``` ### Fontes de Dados Recomendadas - **Endpoint:** Logs de eventos do sistema (Windows Event ID 7031, 7034), `journalctl` no Linux, crash dumps (`.dmp`, `core`) - **Rede:** IDS/IPS para detecção de payloads malformados; análise de anomalias com ML - **Aplicação:** APM (Application Performance Monitoring) como Datadog, Dynatrace, New Relic para detecção de picos e crashes - **ICS/SCADA:** Monitoramento de protocolos industriais com Dragos, Claroty, Nozomi Networks --- ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | M1037 | [[m1037-filter-network-traffic\|M1037 - Filter Network Traffic]] | Filtrar tráfego de rede malformado ou anômalo usando firewalls de próxima geração (NGFW), WAF e IPS. Bloquear payloads que exploram vulnerabilidades conhecidas. | | - | Gestão de Patches | Aplicar patches de segurança prontamente. Priorizar CVEs com CVSS ≥ 7.0 e presença no CISA KEV. Sistemas ICS/OT requerem jánelas de manutenção planejadas. | | - | Redundância e Alta Disponibilidade | Implementar arquiteturas HA (clusters, load balancers, failover automático) para reduzir impacto de crashes individuais. | | - | Monitoramento de Integridade | Usar checksums e verificação de integridade de binários para detectar modificações maliciosas que possam induzir crashes. | | - | Isolamento de Serviços Críticos | Segregar serviços críticos em redes separadas. Limitar superfície de ataque com princípio do menor privilégio. | | - | Análise de Crash Dumps | Configurar coleta automática de crash dumps e análise forense. Crashdumps podem revelar o exploit utilizado. | --- ## Contexto Brasil / LATAM O Brasil possui infraestrutura crítica significativa que é alvo potencial desta técnica: **Setor Elétrico:** A [[Aneel]] supervisiona operadores de rede elétrica distribuídos por todo o país. Sistemas SCADA utilizados por concessionárias (Cemig, Copel, Elektro, Enel Brasil) frequentemente rodam software industrial desatualizado com ciclos de patch longos. O precedente ucraniano (Industroyer) demonstra a viabilidade de ataques a redes elétricas via exploração de aplicações ICS. **Setor Financeiro:** Bancos brasileiros operam sistemas de alto volume transacional. Ataques de DoS direcionados a sistemas de core banking ou plataformas de pagamento (como o Pix, operado pelo Banco Central) podem causar impacto econômico significativo. O grupo [[lapsusbr|Lapsus$]], que operou extensivamente no Brasil, demonstrou capacidade de atingir infraestruturas financeiras críticas. **Setor de Saúde:** Hospitais e sistemas de prontuário eletrônico (como o Tasy, amplamente usado no Brasil) têm sido alvo de grupos de ransomware. Um crash induzido em sistemas de monitoramento hospitalar pode colocar vidas em risco. **Ameaças APT Regionais:** Grupos como [[g0099-blind-eagle-apt-c-36|Blind Eagle]] (APT-C-36) têm demonstrado capacidade de comprometer infraestrutura corporativa brasileira e colombiana. Embora historicamente focados em espionagem, a escalada para sabotagem via exploração de aplicações é técnicamente viável. **Regulação:** A [[lgpd|LGPD]] e as normas do Banco Central (Resolução CMN 4.893) exigem planos de continuidade de negócios (PCN) e gestão de incidentes, o que inclui respostas a ataques DoS via exploração de aplicações. --- ## Referências - [MITRE ATT&CK - T1499.004](https://attack.mitre.org/techniques/T1499/004) - [Industroyer/Crashoverride - ESET Research](https://www.welivesecurity.com/2017/06/12/industroyer-biggest-threat-industrial-control-systems-since-stuxnet/) - [CISA Advisory - ICS Threat Landscape](https://www.cisa.gov/ics-cert) - [[t1499-endpoint-denial-of-service|T1499 - Endpoint Denial of Service]] (técnica pai) - [[t1485-data-destruction|T1485 - Data Destruction]] (efeito colateral) - [[t1495-firmware-corruption|T1495 - Firmware Corruption]] (efeito colateral) - [[t1489-service-stop|T1489 - Service Stop]] (efeito colateral) - [[m1037-filter-network-traffic|M1037 - Filter Network Traffic]] (mitigação) - [[s0604-industroyer|Industroyer]] (malware associado) - [[_impact|Tática: Impact]] --- *Fonte: [MITRE ATT&CK - T1499.004](https://attack.mitre.org/techniques/T1499/004)*