Etiqueta: WAZUH

  • Como o Wazuh Pode Detectar e Prevenir o Ataque APT ao Notepad++

    Como o Wazuh Pode Detectar e Prevenir o Ataque APT ao Notepad++

    Visão Geral da Proteção

    O Wazuh SIEM oferece múltiplas camadas de deteção para identificar e prevenir ataques de cadeia de fornecimento como o comprometimento do Notepad++. Apresento uma implementação prática para o seu ambiente.


    1. Monitorização de Integridade de Ficheiros (FIM)

    Configuração para Detetar Instaladores Maliciosos NSIS

    xml

    <!-- /var/ossec/etc/ossec.conf -->
    <syscheck>
      <directories check_all="yes" realtime="yes" report_changes="yes">
        C:\Users\*\AppData\Local\Temp
      </directories>
      
      <!-- Detetar criação do diretório característico NSIS -->
      <directories check_all="yes" realtime="yes" report_changes="yes">
        C:\Users\*\AppData\Local\Temp\ns*.tmp
      </directories>
      
      <!-- Monitorizar diretórios de dropper identificados -->
      <directories check_all="yes" realtime="yes" report_changes="yes">
        C:\Users\*\AppData\Roaming\ProShow
        C:\Users\*\AppData\Roaming\Adobe\Scripts
        C:\Users\*\AppData\Roaming\Bluetooth
      </directories>
    </syscheck>

    Regra Personalizada para NSIS Suspeito

    xml

    <!-- /var/ossec/etc/rules/local_rules.xml -->
    <group name="notepad_apt,">
      
      <!-- Deteção de diretório NSIS temporário -->
      <rule id="100001" level="10">
        <if_sid>550</if_sid>
        <field name="file">ns\.tmp</field>
        <description>Possível instalador NSIS malicioso detetado (Notepad++ APT)</description>
        <mitre>
          <id>T1027</id>
          <id>T1195.002</id>
        </mitre>
      </rule>
    
      <!-- Deteção de ficheiros em diretórios de dropper -->
      <rule id="100002" level="12">
        <if_sid>550</if_sid>
        <field name="file">ProShow\\load$|Adobe\\Scripts\\alien\.ini$|Bluetooth\\BluetoothService$</field>
        <description>Ficheiro malicioso de cadeia de infeção Notepad++ detetado</description>
        <mitre>
          <id>T1574.002</id>
        </mitre>
      </rule>
    
    </group>

    2. Deteção de Processos Suspeitos

    Monitorização Sysmon para DLL Sideloading

    xml

    <!-- C:\Program Files (x86)\ossec-agent\sysmon-config.xml -->
    <Sysmon schemaversion="4.82">
      <EventFiltering>
        
        <!-- Detetar carregamento de DLLs maliciosas -->
        <ImageLoad onmatch="include">
          <ImageLoaded condition="end with">log.dll</ImageLoaded>
          <ImageLoaded condition="end with">alien.dll</ImageLoaded>
          <ImageLoaded condition="end with">lua5.1.dll</ImageLoaded>
        </ImageLoad>
        
        <!-- Detetar processos legítimos abusados -->
        <ProcessCreate onmatch="include">
          <Image condition="end with">ProShow.exe</Image>
          <Image condition="end with">script.exe</Image>
          <Image condition="end with">BluetoothService.exe</Image>
          <ParentImage condition="contains">AppData\Roaming</ParentImage>
        </ProcessCreate>
        
      </EventFiltering>
    </Sysmon>

    Regras Wazuh para Sysmon

    xml

    <!-- /var/ossec/etc/rules/local_rules.xml -->
    <group name="sysmon,notepad_apt">
    
      <!-- Deteção de DLL sideloading -->
      <rule id="100010" level="12">
        <if_sid>61603</if_sid>
        <field name="win.eventdata.imageLoaded">\\log\.dll$|\\alien\.dll$</field>
        <description>DLL sideloading detetado - Cadeia de infeção Notepad++ APT</description>
        <mitre>
          <id>T1574.002</id>
        </mitre>
      </rule>
    
      <!-- Processo legítimo em localização suspeita -->
      <rule id="100011" level="10">
        <if_sid>61603</if_sid>
        <field name="win.eventdata.image">ProShow\.exe|BluetoothService\.exe</field>
        <field name="win.eventdata.image">AppData\\Roaming</field>
        <description>Executável legítimo em localização anómala (Notepad++ APT)</description>
        <mitre>
          <id>T1036</id>
        </mitre>
      </rule>
    
    </group>

    3. Deteção de Comandos de Reconhecimento

    Monitorização de CommandLine via Sysmon

    xml

    <!-- Regras para comandos de reconhecimento -->
    <group name="reconnaissance,notepad_apt">
    
      <!-- Sequência de comandos característica -->
      <rule id="100020" level="8">
        <if_sid>61603</if_sid>
        <field name="win.eventdata.commandLine">cmd\.exe.*whoami</field>
        <description>Comando de reconhecimento: whoami</description>
        <mitre>
          <id>T1033</id>
        </mitre>
      </rule>
    
      <rule id="100021" level="8">
        <if_sid>61603</if_sid>
        <field name="win.eventdata.commandLine">cmd\.exe.*tasklist</field>
        <description>Comando de reconhecimento: tasklist</description>
        <mitre>
          <id>T1057</id>
        </mitre>
      </rule>
    
      <rule id="100022" level="8">
        <if_sid>61603</if_sid>
        <field name="win.eventdata.commandLine">cmd\.exe.*systeminfo</field>
        <description>Comando de reconhecimento: systeminfo</description>
        <mitre>
          <id>T1082</id>
        </mitre>
      </rule>
    
      <rule id="100023" level="8">
        <if_sid>61603</if_sid>
        <field name="win.eventdata.commandLine">cmd\.exe.*netstat.*-ano</field>
        <description>Comando de reconhecimento: netstat</description>
        <mitre>
          <id>T1049</id>
        </mitre>
      </rule>
    
      <!-- Correlação: múltiplos comandos em sequência -->
      <rule id="100024" level="15" frequency="3" timeframe="60">
        <if_matched_sid>100020</if_matched_sid>
        <if_matched_sid>100021</if_matched_sid>
        <if_matched_sid>100022</if_matched_sid>
        <same_source_ip />
        <description>ALERTA CRÍTICO: Sequência de reconhecimento APT Notepad++ detetada</description>
        <mitre>
          <id>T1595</id>
        </mitre>
      </rule>
    
    </group>

    4. Deteção de Rede e DNS

    Monitorização de Domínios Maliciosos

    xml

    <!-- /var/ossec/etc/lists/notepad_apt_iocs.txt -->
    # Domínios C2 identificados pela Kaspersky
    temp.sh
    cdncheck.it.com
    safe-dns.it.com
    self-dns.it.com
    api.skycloudcenter.com
    api.wiresguard.com
    
    # IPs maliciosos
    45.76.155.202
    45.32.144.255
    95.179.213.0
    45.77.31.210
    59.110.7.32
    124.222.137.114

    Regras para Deteção DNS/HTTP

    xml

    <group name="network,notepad_apt">
    
      <!-- Deteção de resolução DNS suspeita -->
      <rule id="100030" level="12">
        <if_group>web</if_group>
        <list field="url" lookup="match_key_value">etc/lists/notepad_apt_iocs.txt</list>
        <description>Conexão a domínio C2 conhecido (Notepad++ APT)</description>
        <mitre>
          <id>T1071.001</id>
        </mitre>
      </rule>
    
      <!-- Deteção de temp.sh (exfiltração) -->
      <rule id="100031" level="13">
        <if_group>web</if_group>
        <match>temp.sh</match>
        <description>CRÍTICO: Tentativa de exfiltração via temp.sh (Notepad++ APT)</description>
        <mitre>
          <id>T1567.002</id>
        </mitre>
      </rule>
    
      <!-- Deteção de User-Agent suspeito em requisições HTTP -->
      <rule id="100032" level="10">
        <if_group>web</if_group>
        <field name="user_agent">temp\.sh</field>
        <description>User-Agent malicioso detetado (Notepad++ APT C2)</description>
        <mitre>
          <id>T1071.001</id>
        </mitre>
      </rule>
    
    </group>

    5. Integração com Active Response

    Resposta Automática a Ameaças

    xml

    <!-- /var/ossec/etc/ossec.conf -->
    <active-response>
      
      <!-- Isolar máquina em caso de deteção crítica -->
      <command>firewall-drop</command>
      <location>local</location>
      <rules_id>100024,100031</rules_id>
      <timeout>3600</timeout>
    </active-response>
    
    <active-response>
      
      <!-- Matar processos maliciosos -->
      <command>kill-process</command>
      <location>local</location>
      <rules_id>100011</rules_id>
      <timeout>no</timeout>
    </active-response>
    
    <!-- Script personalizado para quarentena -->
    <command>
      <name>quarantine-file</name>
      <executable>quarantine.sh</executable>
      <timeout_allowed>no</timeout_allowed>
    </command>
    
    <active-response>
      <command>quarantine-file</command>
      <location>local</location>
      <rules_id>100002</rules_id>
    </active-response>

    Script de Quarentena

    bash

    #!/bin/bash
    # /var/ossec/active-response/bin/quarantine.sh
    
    ACTION=$1
    USER=$2
    IP=$3
    ALERTID=$4
    RULEID=$5
    
    # Extrair caminho do ficheiro do alerta
    FILENAME=$(echo "$6" | jq -r '.syscheck.path')
    
    if [ "$ACTION" = "add" ]; then
        # Criar diretório de quarentena
        QUARANTINE_DIR="/var/ossec/quarantine/$(date +%Y%m%d)"
        mkdir -p "$QUARANTINE_DIR"
        
        # Mover ficheiro malicioso
        if [ -f "$FILENAME" ]; then
            mv "$FILENAME" "$QUARANTINE_DIR/$(basename $FILENAME)_$(date +%s)"
            
            # Registar ação
            echo "$(date): Ficheiro $FILENAME colocado em quarentena por regra $RULEID" >> /var/ossec/logs/quarantine.log
        fi
    fi

    6. Dashboard Kibana para Visualização

    Query Elasticsearch para Análise

    json

    {
      "query": {
        "bool": {
          "should": [
            { "match": { "rule.groups": "notepad_apt" }},
            { "match": { "rule.mitre.id": "T1195.002" }},
            { "match": { "data.win.eventdata.image": "notepad" }}
          ]
        }
      },
      "aggs": {
        "top_agents": {
          "terms": { "field": "agent.name" }
        },
        "attack_timeline": {
          "date_histogram": {
            "field": "@timestamp",
            "interval": "1h"
          }
        }
      }
    }

    7. Implementação Prática – Script de Deploy

    bash

    #!/bin/bash
    # deploy_notepad_apt_protection.sh
    
    echo "[+] A instalar proteção APT Notepad++ no Wazuh..."
    
    # 1. Copiar regras personalizadas
    cat >> /var/ossec/etc/rules/local_rules.xml << 'EOF'
    <!-- Incluir todas as regras acima -->
    EOF
    
    # 2. Criar lista de IOCs
    cat > /var/ossec/etc/lists/notepad_apt_iocs.txt << 'EOF'
    temp.sh
    cdncheck.it.com
    safe-dns.it.com
    self-dns.it.com
    EOF
    
    # 3. Atualizar CDB
    cd /var/ossec/etc/lists/
    /var/ossec/bin/ossec-makelists
    
    # 4. Reiniciar Wazuh Manager
    systemctl restart wazuh-manager
    
    echo "[+] Proteção implementada com sucesso!"
    echo "[+] Verificar logs em: /var/ossec/logs/alerts/alerts.json"

    8. Configuração de Agentes Windows

    PowerShell – Deploy em Agentes

    powershell

    # install_sysmon_notepad_protection.ps1
    
    # Download Sysmon
    Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" -OutFile "C:\Temp\Sysmon.zip"
    Expand-Archive -Path "C:\Temp\Sysmon.zip" -DestinationPath "C:\Temp\Sysmon"
    
    # Instalar Sysmon com configuração personalizada
    C:\Temp\Sysmon\Sysmon64.exe -accepteula -i C:\sysmon-config.xml
    
    # Configurar forwarding para Wazuh
    Add-Content -Path "C:\Program Files (x86)\ossec-agent\ossec.conf" -Value @"
    <localfile>
      <location>Microsoft-Windows-Sysmon/Operational</location>
      <log_format>eventchannel</log_format>
    </localfile>
    "@
    
    # Reiniciar agente
    Restart-Service -Name wazuh

    9. Alertas e Notificações

    Integração com Sistemas de Alerta

    xml

    <!-- /var/ossec/etc/ossec.conf -->
    <integration>
      <name>slack</name>
      <hook_url>https://hooks.slack.com/services/YOUR/WEBHOOK/URL</hook_url>
      <level>12</level>
      <rule_id>100024,100031</rule_id>
      <alert_format>json</alert_format>
    </integration>
    
    <integration>
      <name>custom-email</name>
      <hook_url>https://api.hjfr.info/wazuh/alert</hook_url>
      <level>10</level>
      <group>notepad_apt</group>
      <alert_format>json</alert_format>
    </integration>

    10. Testes de Validação

    Script de Teste (ATENÇÃO: Apenas em ambiente controlado!)

    powershell

    # test_notepad_apt_detection.ps1
    # EXECUTAR APENAS EM AMBIENTE DE TESTE!
    
    # Teste 1: Criar diretório NSIS
    New-Item -Path "$env:LOCALAPPDATA\Temp\ns1234.tmp" -ItemType Directory
    
    # Teste 2: Simular comandos de reconhecimento
    cmd /c whoami > C:\Temp\test.txt
    cmd /c tasklist >> C:\Temp\test.txt
    cmd /c systeminfo >> C:\Temp\test.txt
    cmd /c netstat -ano >> C:\Temp\test.txt
    
    # Teste 3: Tentativa de resolução DNS (modo seguro)
    nslookup temp.sh
    
    Write-Host "[+] Testes concluídos. Verificar alertas no Wazuh."

    Resultados Esperados

    Alertas Gerados no Wazuh

    json

    {
      "timestamp": "2026-02-04T10:30:00.000Z",
      "rule": {
        "level": 15,
        "description": "ALERTA CRÍTICO: Sequência de reconhecimento APT Notepad++ detetada",
        "id": "100024",
        "mitre": {
          "id": ["T1595"],
          "tactic": ["Reconnaissance"],
          "technique": ["Active Scanning"]
        }
      },
      "agent": {
        "name": "WORKSTATION-001",
        "ip": "192.168.1.50"
      },
      "full_log": "cmd /c whoami&&tasklist&&systeminfo&&netstat -ano"
    }

    Benefícios da Implementação

    Capacidades de Deteção

    Deteção Proativa:

    • Identificação de instaladores NSIS maliciosos em tempo real
    • Monitorização de DLL sideloading
    • Correlação de comandos de reconhecimento

    Resposta Automática:

    • Isolamento imediato de sistemas comprometidos
    • Quarentena automática de ficheiros maliciosos
    • Bloqueio de comunicações C2

    Visibilidade Completa:

    • Timeline de ataque em dashboard Kibana
    • Mapeamento MITRE ATT&CK
    • Relatórios de conformidade RGPD

    Manutenção Contínua

    Atualização de IOCs

    bash

    # update_iocs.sh - Executar semanalmente
    #!/bin/bash
    
    # Download de feeds de threat intelligence
    curl -s https://securelist.com/feed/iocs/latest | \
      grep -E "notepad|temp.sh" >> /var/ossec/etc/lists/notepad_apt_iocs.txt
    
    # Remover duplicados
    sort -u /var/ossec/etc/lists/notepad_apt_iocs.txt -o /var/ossec/etc/lists/notepad_apt_iocs.txt
    
    # Recompilar CDB
    /var/ossec/bin/ossec-makelists
    
    # Reiniciar manager
    systemctl restart wazuh-manager

    Conclusão

    Esta implementação fornece proteção em profundidade contra ataques APT à cadeia de fornecimento, especificamente configurada para detetar as três cadeias de infeção do Notepad++. O Wazuh oferece:

    • Deteção em tempo real de indicadores de compromisso
    • Resposta automática a ameaças críticas
    • Conformidade com frameworks de segurança (NIST, MITRE ATT&CK)
    • Visibilidade centralizada para equipas SOC

    Recomendação HJFR: Implementar esta configuração em todos os ambientes corporativos que utilizem Notepad++ ou editores de texto similares.


    Documentação Técnica HJFR
    Versão: 1.0
    Data: 4 de fevereiro de 2026
    Suporte: security@hjfr.info

  • Ataque à Cadeia de Fornecimento do Notepad++

    Ataque à Cadeia de Fornecimento do Notepad++

    A equipa de investigação Kaspersky GReAT (Global Research and Analysis Team) revelou detalhes inéditos sobre o comprometimento da infraestrutura de atualização do Notepad++, um editor de texto amplamente utilizado por programadores. Entre julho e outubro de 2025, os atacantes implementaram três cadeias de infeção distintas, modificando constantemente seus métodos de distribuição, servidores de comando e controlo (C2) e payloads maliciosos.

    Principais Descobertas:

    Escopo do Ataque:

    • Período: Junho a dezembro de 2025
    • Alvos confirmados:
      • Organização governamental nas Filipinas
      • Instituição financeira em El Salvador
      • Fornecedor de serviços de TI no Vietname
      • Indivíduos no Vietname, El Salvador e Austrália

    Modus Operandi: Os atacantes comprometeram a infraestrutura do provedor de hospedagem do Notepad++, permitindo redirecionamento seletivo de tráfego de atualização para servidores maliciosos. Durante quatro meses, renovaram constantemente:

    • Endereços de servidores C2
    • Downloaders utilizados para entrega de implantes
    • Payloads finais (Metasploit, Cobalt Strike Beacon, backdoor Chrysalis)

    Três Cadeias de Infeção Identificadas

    Cadeia #1 (Final de julho – início de agosto 2025)

    • Utilizou instalador NSIS (~1 MB)
    • Explorou vulnerabilidade antiga do software ProShow
    • Implementou downloader Metasploit → Cobalt Strike Beacon
    • C2 inicial: 45.77.31[.]210 e cdncheck.it[.]com

    Cadeia #2 (Setembro – outubro 2025)

    • Instalador NSIS reduzido (~140 KB)
    • Empregou interpretador Lua legítimo para execução de shellcode
    • Recolha expandida de informações do sistema
    • Novos domínios C2: safe-dns.it[.]com e self-dns.it[.]com

    Cadeia #3 (Outubro 2025)

    • Técnica de DLL sideloading
    • Implementação do backdoor personalizado Chrysalis
    • Abusou de executável legítimo da Bitdefender
    • Nova infraestrutura C2: 95.179.213[.]0 e api.skycloudcenter[.]com

    Indicadores Técnicos

    • Websites de upload temporário: temp[.]sh (utilizado para exfiltração de dados)
    • User-agents personalizados: Variações de Mozilla/Chrome para evasão
    • Comandos de reconhecimento: whoami, tasklist, systeminfo, netstat -ano

    Medidas de Proteção

    A Kaspersky recomenda:

    1. Verificar logs para criação de diretórios %localappdata%\Temp\ns.tmp
    2. Monitorizar resoluções DNS para temp[.]sh
    3. Auditar execuções de instaladores NSIS não autorizados
    4. Implementar detecção de DLL sideloading
    5. Atualizar para Notepad++ versão 8.9.1+ (inclui validação XMLDSig)

    Atribuição

    Múltiplos investigadores de segurança atribuem o ataque ao grupo Lotus Blossom (também conhecido como Bilbug, Raspberry Typhoon ou Thrip), um ator de ameaças chinês ativo desde 2009.

    Referências e Recursos Originais

    Análises Técnicas Primárias:

    1. Kaspersky Securelist – Relatório técnico completo
      “The Notepad++ supply chain attack – unnoticed execution chains and new IoCs”
      Autores: Georgy Kucherin, Anton Kargin
      Publicado: 3 de fevereiro de 2026
    2. Rapid7 Research – Análise do backdoor Chrysalis
      “Notepad++ Hosting Breach Attributed to Lotus Blossom”
      Identificação inicial da cadeia de infeção #3
    3. Notepad++ Comunicado Oficial
      “Notepad++ Hijacked by State-Sponsored Hackers”
      Declaração do desenvolvedor Don Ho
      2 de fevereiro de 2026

    Análises de Segurança Complementares:

    1. Kaspersky Official Press Release
      “Kaspersky GReAT uncovers hidden attack chains”
    2. Tenable Research FAQ
      “Notepad++ Supply Chain Compromise”
    3. Help Net Security
      “Notepad++ supply chain attack: Researchers reveal details, IoCs, targets”

    IOCs e Detecção:

    • Lista completa de Indicadores de Compromisso disponível no relatório da Kaspersky Securelist
    • 6 hashes de atualizadores maliciosos
    • 14 URLs de servidores C2
    • 8 hashes de ficheiros maliciosos não relatados anteriormente

    Contexto para Organizações Portuguesas

    Este incidente sublinha a importância de:

    • Validação rigorosa de atualizações de software
    • Monitorização de infraestrutura de rede
    • Implementação de EDR (Endpoint Detection and Response)
    • Conformidade com requisitos RGPD em auditoria de segurança

    A HJFR recomenda revisão imediata de sistemas que utilizem Notepad++ e implementação de controlos de segurança adequados.

  • Anatomia de um Ataque:

    Anatomia de um Ataque:

    Como Detetar e Bloquear Tentativas de Acesso a Ficheiros de Backup

    Introdução

    Recentemente, durante a análise rotineira dos logs do servidor, deparei-me com uma entrada que ilustra perfeitamente um dos vetores de ataque mais comuns (e perigosos) na web:

    a tentativa de acesso a ficheiros de backup.

    Neste artigo, vou analisar em detalhe esta tentativa de ataque, explicar porque representa um risco crítico de segurança e mostrar como podemos implementar mecanismos de deteção com Wazuh e proteção com ModSecurity.

    A Entrada de Log Maliciosa

    Vamos começar por examinar a entrada que acionou os nossos alertas de segurança:

    À primeira vista, pode parecer apenas mais uma entrada num oceano de logs.

    No entanto, uma análise cuidadosa revela várias red flags críticas que identificam esta como uma tentativa de ataque deliberada.

    Análise Técnica: Porque é Malicioso?

    1. O Alvo: Ficheiros de Backup Expostos

    O elemento mais crítico desta tentativa de ataque é o caminho solicitado: /wwwroot.bak

    Ficheiros de backup são um dos alvos mais apetecíveis para atacantes porque frequentemente contêm:

    • Código-fonte completo da aplicação incluindo lógica de negócio sensível
    • Credenciais hardcoded como passwords de bases de dados, chaves API e tokens de autenticação
    • Informação sobre a estrutura da aplicação que facilita outros ataques
    • Dados sensíveis que não deveriam estar acessíveis publicamente
    • Vulnerabilidades conhecidas em versões antigas do código

    Extensões comuns de ficheiros de backup que os atacantes procuram:

    • .bak, .backup, .old, .orig, .copy
    • .zip, .tar.gz, .rar, .7z
    • .sql, .sql.gz, .dump
    • ~, .swp, .tmp

    2. User-Agent Spoofing: Disfarçado de Googlebot

    Outro indicador claro de atividade maliciosa é o User-Agent utilizado:

    O atacante está a tentar fazer-se passar pelo Googlebot, o crawler oficial do Google. Esta é uma técnica comum chamada User-Agent Spoofing com vários objetivos:

    • Evitar bloqueios automáticos: Muitos sistemas confiam em User-Agents legítimos
    • Contornar rate limiting: Bots de motores de busca geralmente têm limites mais elevados
    • Reduzir suspeitas: Administradores podem ignorar pedidos aparentemente do Google
    • Explorar whitelists: Alguns sistemas permitem acesso privilegiado a crawlers conhecidos

    Como verificar se é realmente o Googlebot: O Googlebot legítimo faz reverse DNS lookup para googlebot.com ou google.com. Pedidos do IP xxx.xxx.xxx.xxx nunca seriam do Google real.

    3. Padrão de Reconhecimento Automatizado

    Analisando o contexto mais amplo (embora não visível nesta entrada específica), este tipo de pedido faz parte de um scanning automatizado onde o atacante:

    1. Identifica websites potencialmente vulneráveis
    2. Testa múltiplos caminhos de ficheiros de backup comuns
    3. Procura por respostas que indiquem a existência de ficheiros (mesmo 403 Forbidden é útil)
    4. Faz download de qualquer ficheiro encontrado para análise offline

    4. O Código 404: Será que Estamos Seguros?

    Neste caso, o servidor respondeu com 404 Not Found, o que é positivo – o ficheiro não existe ou não está acessível.

    No entanto, isto não significa que estamos completamente seguros:

    • O atacante pode estar a testar centenas ou milhares de variações
    • Outros ficheiros de backup podem existir com nomes diferentes
    • A tentativa em si revela que o site está a ser ativamente alvo de reconhecimento
    • Múltiplas tentativas podem indicar uma campanha mais ampla de ataque

    Deteção com Wazuh SIEM

    Agora que compreendemos a anatomia do ataque, vamos implementar regras de deteção no Wazuh para identificar automaticamente estas tentativas.

    Regra personalizada hipotética para Ficheiros de Backup

    Adicione esta regra ao ficheiro /var/ossec/etc/rules/local_rules.xml:

    Configuração de Alertas e Respostas Ativas

    Configure respostas ativas para bloquear automaticamente IPs suspeitos:

    Dashboard Kibana para Monitorização

    Crie visualizações no Kibana para monitorizar:

    1. Mapa de calor geográfico de tentativas de acesso a backups
    2. Timeline de tentativas por hora/dia
    3. Top 10 IPs mais agressivos
    4. Top 10 ficheiros mais procurados
    5. Correlação entre User-Agents e padrões de ataque

    Proteção com ModSecurity WAF

    Enquanto o Wazuh nos ajuda a detetar ataques, o ModSecurity permite-nos prevenir ativamente estas tentativas antes que cheguem à aplicação.

    Regras personalizadas hipotéticas ModSecurity

    Crie o ficheiro /etc/modsecurity/custom_rules.conf:

    Criar Lista de IPs Legítimos do Google

    Configuração de Resposta Personalizada

    Edite /etc/modsecurity/modsecurity.conf:

    Boas Práticas de Prevenção

    Além da deteção e bloqueio ativo, é crucial implementar medidas preventivas:

    1. Gestão Segura de Ficheiros de Backup

    2. Configuração do Servidor Web

    Apache (.htaccess):

    Nginx:

    3. Automação com Scripts de Segurança

    Crie um script de auditoria /usr/local/bin/check-backup-files.sh:

    Agende com cron:

    4. Monitorização de File Integrity (FIM)

    Configure o Wazuh FIM para alertar sobre criação de ficheiros suspeitos:

    Conclusão e Recomendações

    A tentativa de acesso a ficheiros de backup que analisámos pode parecer inofensiva à primeira vista, mas representa um vetor de ataque sério que pode levar a:

    • Exposição de código-fonte e propriedade intelectual
    • Fuga de credenciais e chaves API
    • Comprometimento completo da aplicação
    • Exfiltração de dados sensíveis

    Checklist de Segurança:

    Implementar regras Wazuh para deteção pro-ativa
    Configurar ModSecurity para bloqueio em tempo real
    Auditar webroot regularmente para ficheiros expostos
    Criar backups seguros fora do webroot
    Configurar alertas para tentativas de acesso suspeitas
    Validar User-Agents contra listas de IPs conhecidos
    Implementar rate limiting para prevenir scanning automatizado
    Manter logs centralizados para análise forense

    Recursos Adicionais:


    Nota de Segurança: Os IPs e domínios mencionados neste artigo foram mascarados ou alterados para fins de privacidade. As configurações apresentadas devem ser adaptadas ao seu ambiente específico antes da implementação em produção.

    Sobre o Autor: Este artigo faz parte da série sobre segurança de infraestrutura e monitorização com SIEM. Para mais conteúdo técnico sobre cibersegurança, siga o blog.


    Última atualização: Janeiro 2026