Paper Files / Phishing
Arquiteturas Ofensivas e Defensivas em Campanhas de Phishing: Modelagem Formal de Ameaças, Detecção Multicamadas e Resiliência Organizacional
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_client_access hash:/etc/postfix/rbl_override, reject_rhsbl_sender dbl.spamhaus.org, check_policy_service unix:private/policy ``` - SpamAssassin com regras personalizadas: ``` body HAS_IP_URL /\bhttps?:\/\/\d{1,3}(\.\d{1,3}){3}\// describe HAS_IP_URL URL com endereço IP literal score HAS_IP_URL 2.5 uri URIBL_BLACK uribl:multi.uribl.com describe URIBL_BLACK Domínio listado em URIBL score URIBL_BLACK 4.0 ``` - SEC para correlação de múltiplos eventos: ``` type=
- Introduction
O phishing, tal como observado em 2005–2006, caracteriza-se pelo envio de mensagens eletrônicas fraudulentas e pela construção de páginas web enganosas que visam à captura de credenciais bancárias, senhas corporativas e outros dados sensíveis (APWG, 2006; JAKOBSSON; MYERS, 2006). A sofisticação dos ataques ampliou-se com a adoção de técnicas de manipulação de URLs (inclusão de endereços IP literais, subdomínios extensos, codificação em hexadecimal), o aproveitamento de deficiências na percepção de risco por parte dos usuários e a utilização de certificados válidos emitidos por Autoridades Certificadoras amplamente confiáveis quando economicamente vantajoso (RFC 2246, 1999; RFC 2818, 2000; RFC 3280, 2002).
A literatura técnica deste período enfatiza dois vetores fundamentais: (i) engenharia social apoiada em e-mail e navegadores, frequentemente explorando falhas cognitivas dos usuários (DHAMIJA; TYGAR; HEARST, 2006); e (ii) lacunas nas defesas perimetrais e de aplicação, ainda em consolidação, incluindo listas de reputação, filtros bayesianos de spam, inspeção de tráfego e validação de certificados (SAHAMI et al., 1998; GRAHAM, 2003; CHOU et al., 2004). Ao mesmo tempo, comunidades técnicas e indústria organizaram esforços de report e mitigação, como os relatórios periódicos da APWG (2006), a adoção emergente de SPF (RFC 4408, 2006) e a introdução de filtros anti-phishing em navegadores (GOOGLE, 2005; MICROSOFT, 2006).
Apresentamos, neste artigo, uma arquitetura ofensivo-defensiva para detecção e resposta a campanhas de phishing adequada ao cenário tecnológico de 2006. Nossa abordagem integra: (a) um modelo formal de ameaça e de decisão sob custo assimétrico; (b) camadas de detecção que combinam heurísticas léxicas, reputação de URLs (SURBL/URIBL), análise de certificados TLS/SSL (MD5/SHA-1), IDS de rede (Snort 2.6) e análise comportamental (Bro) com correlação via ferramentas acessíveis (SEC, Sguil, BASE); e © procedimentos operacionais em conformidade com o NIST SP 800-61 (2004).
Nossas principais contribuições são: (i) uma formalização matemática clara do problema de classificação e de sua função de risco com custos desbalanceados; (ii) uma arquitetura multicamadas replicável com ferramentas consolidadas até 2006; (iii) uma avaliação empírica com dados de 2005–2006; e (iv) um estudo de caso de intrusão simulada envolvendo páginas clonadas de OWA e captura de credenciais, seguido de detecção e contenção coordenadas.
- Background and Related Work
A pesquisa inicial em detecção de phishing contemplou mecanismos de proteção no lado do cliente e heurísticas de análise de páginas e mensagens. SpoofGuard, por exemplo, analisava indicadores de falsificação de identidade diretamente no navegador (CHOU et al., 2004). Em paralelo, propuseram-se mecanismos de reforço à autenticação baseada em senhas, como PwdHash, que deriva senhas específicas por domínio a partir de uma senha-mestra, mitigando reutilização e phishing de credenciais (HALDERMAN; WATERS; FELTEN, 2005). Estudos de usabilidade e psicologia cognitiva demonstraram por que interfaces e indicadores de segurança então vigentes eram insuficientes para prevenir o engano dos usuários (DHAMIJA; TYGAR; HEARST, 2006).
Do ponto de vista de infraestrutura, filtros bayesianos de spam ganharam tração tanto no meio acadêmico quanto industrial, com resultados expressivos na triagem de mensagens maliciosas (SAHAMI et al., 1998; GRAHAM, 2003). Mecanismos de reputação de URLs acessados via DNS surgiram como componentes críticos, como SURBL e URIBL, possibilitando bloquear mensagens com referências a domínios maliciosos (SURBL, 2004; URIBL, 2003). Simultaneamente, esforços normativos e industriais focaram na validação de origem de e-mails, como o Sender Policy Framework (SPF) publicado como RFC 4408 em 2006 (RFC 4408, 2006), e em filtros anti-phishing embarcados em navegadores, como o Google Safe Browsing (GOOGLE, 2005) e o Phishing Filter no IE7 (MICROSOFT, 2006).
A inspeção e correlação de tráfego em nível de rede consolidaram-se com IDS como Snort (ROESCH, 1999; SNORT, 2006) e com sistemas de análise comportamental em tempo real como o Bro (PAXSON, 1999), os quais possibilitavam tanto detecção baseada em assinaturas quanto extração de perfis de tráfego HTTP/SMTP. A orquestração operacional evoluiu por meio de guias como o NIST SP 800-61 (NIST, 2004) e de ferramentas de correlação de eventos como o Simple Event Correlator (SEC) (VAARANDI, 2004), além de plataformas de análise para alertas como Sguil e BASE.
Pesquisas correlatas também abordaram aspectos de DNS e homógrafos em domínios internacionalizados (IDN), evidenciando riscos de confusão visual e redirecionamento (RFC 3490, 2003; RFC 3492, 2003; JOHANSON, 2005). Além disso, práticas de perícia digital especializadas, com ferramentas como EnCase e FTK, foram sendo incorporadas às rotinas de resposta a incidentes (GUIDANCE SOFTWARE, 2004; ACCESSDATA, 2005), evidenciando a necessidade de preservação de evidências desde a detecção inicial.
Em síntese, até 2006, a literatura e a prática convergiam para uma visão de defesa em profundidade, com camadas complementares cobrindo e-mail, web, TLS/SSL, DNS, perímetro e correlação centralizada de eventos.
- Threat Model and Problem Formalization
Modelamos o adversário $\mathcal{A}$ como um agente probabilístico que opera sob restrições de custo e tempo, com capacidades compatíveis ao cenário de 2006:
- Registro e uso de domínios e subdomínios, incluindo IDN quando disponível, com possível mimetização visual (JOHANSON, 2005; RFC 3490, 2003).
- Hospedagem em provedores de baixo custo e rápida realocação de conteúdo (sites clonados, redirecionamentos via meta refresh/HTTP 302).
- Emissão e uso de certificados válidos (com MD5/SHA-1) quando economicamente viável (RFC 3280, 2002; RFC 2818, 2000).
- Construção de páginas que simulam portais bancários ou de webmail corporativo (ex.: OWA 2003), com captura de credenciais via HTTP/HTTPS.
- Evasão de filtros por variações léxicas e URLs tangenciais, bem como aproveitamento de falhas cognitivas de usuários (DHAMIJA; TYGAR; HEARST, 2006).
Seja $X = {x_1, \dots, x_n}$ o conjunto de observações compostas por atributos extraídos de mensagens e URLs (léxicos, estruturais, reputacionais e de certificados). O objetivo é aprender uma função de decisão $f_\theta: \mathcal{X} \to {0,1}$ que rotule instâncias como phishing ($1$) ou benignas ($0$):
$$ f_\theta(x) = \begin{cases} 1, & \text{se } x \in \mathcal{P},\ 0, & \text{se } x \in \mathcal{B}, \end{cases} $$
onde $\mathcal{P}$ e $\mathcal{B}$ denotam, respectivamente, as classes phishing e benigna. Consideramos um risco empírico ponderado com custos assimétricos:
$$ R(\theta) = \alpha \cdot FP(\theta) + \beta \cdot FN(\theta), \quad \text{com } \beta > \alpha, $$
de modo a refletir o custo mais elevado de um falso negativo (uma mensagem maliciosa que passa despercebida) frente ao de um falso positivo.
Para fins de classificação, consideramos três famílias de modelos: Naive Bayes (SAHAMI et al., 1998), SVM (CORTES; VAPNIK, 1995) e Random Forest (BREIMAN, 2001). A inferência de Naive Bayes é $O(m)$ em relação ao número de atributos $m$; o treinamento SVM, com kernel RBF, possui custo típico entre $O(n^2)$ e $O(n^3)$ em função da resolução do problema de otimização quadrática para $n$ amostras; a inferência em Random Forest, dada por $T$ árvores de profundidade média $d$, é $O(T \cdot d)$. Ajustamos limiares de decisão para minimizar $R(\theta)$ sob validação cruzada estratificada, contemplando diferentes razões $\beta/\alpha$ coerentes com o apetite de risco da organização.
Além disso, definimos atributos léxicos para URLs, incluindo comprimento $|u|$, número de subdomínios e entropia de Shannon:
$$ H(u) = - \sum_{i=1}^{k} p_i \log_2 p_i, $$
em que $p_i$ é a frequência relativa do $i$-ésimo símbolo de $u$. Incluímos também variáveis de reputação (listagens SURBL/URIBL), consistência de certificado (assinatura MD5/SHA-1, emissor, validade) e indicadores de desvio comportamental (padrões de POST, user-agents, status codes).
- Proposed Methodology
Nossa arquitetura equilibra componentes de baixo custo e alta disponibilidade em 2006 com princípios de defesa em profundidade. Estruturamos o sistema em cinco camadas integradas.
4.1 Coleta e Normalização de Inteligência
- Feeds reputacionais e comunitários: APWG (APWG, 2006), SURBL (SURBL, 2004), URIBL (URIBL, 2003) e, a partir de sua disponibilidade em 2006, PhishTank (PHISHTANK, 2006).
- Logística de ingestão: resolução de nomes via DNS e passive DNS quando disponível (WEIMER, 2005), armazenamento de indicadores (domínios, URLs canônicas, hashes MD5/SHA-1 de certificados) em banco MySQL 5.0.
- Normalização: deduplicação, canonicalização (remoção de fragmentos, normalização de codificações), e extração de atributos.
4.2 Análise de E-mail e URLs
- Filtro de e-mail com SpamAssassin 3.1 e Bayes (SAHAMI et al., 1998; APACHE, 2005), com regras personalizadas para URLs IP-literais, portas não padrão e anomalias no campo From/Reply-To.
- SPF (RFC 4408, 2006) para validação de domínios remetentes e políticas de rejeição/aceitação condicionais em Postfix.
- Atributos léxicos e estruturais gerados a partir de URLs em mensagens: $|u|$, contagem de subdomínios, presença de @, uso de IDN/Punycode (RFC 3490; RFC 3492), entropia $H(u)$ e padrões suspeitos (ex.: excesso de parâmetros ou ofuscação via codificação hexadecimal).
4.3 Validação de TLS/SSL e Certificados
- Extração de certificados via OpenSSL e verificação do emissor, validade e algoritmo de assinatura (prioritariamente MD5 e SHA-1 à época) (OPENSSL, 2005; RFC 3280, 2002).
- Heurísticas: certificados recém-emitidos com validade incomum, CAs pouco conhecidas, divergências CN/SAN vs. host solicitado, e cadeias incompletas.
Comando típico para inspeção:
openssl s_client -connect exemplo.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates -fingerprint -md5
4.4 IDS/IPS e Análise Comportamental
- Snort 2.6 com assinaturas para HTTP e SMTP, detecção de formulários de login suspeitos e redirecionamentos sequenciais.
- Bro (PAXSON, 1999) para extração e análise de perfis HTTP (métodos, cabeçalhos, status), possibilitando detecção de padrões atípicos de POST e de variações em user-agents.
Exemplo de regra Snort para monitorar POSTs a caminhos comuns de captura:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"HTTP POST para caminho sensível"; flow:to_server,established; content:"POST"; http_method; pcre:"/POST\s+\/(login|signin|owa|banking|verify)\b/i"; classtype:attempted-user; sid:2006001; rev:1;)
4.5 Correlação e Classificação Supervisionada
- Correlação de eventos com SEC (VAARANDI, 2004), integrando alertas do Snort, logs do Bro, mensagens do MTA e consultas a SURBL/URIBL, com envio de notificações ao NOC/SOC.
- Classificação supervisionada com Weka 3.4 (WITTEN; FRANK; HALL, 2005): Naive Bayes, SVM (libSVM 2.8) e Random Forest. Validação cruzada estratificada com 10 folds, ajuste de limiar para minimizar $R(\theta)$.
Tabela 1 — Camadas e principais componentes (2006)
| Camada | Componentes (exemplos) |
|---|---|
| Inteligência | APWG, SURBL, URIBL, PhishTank |
| E-mail/URL | Postfix/Sendmail, SpamAssassin, SPF, regras URIBL/SURBL |
| TLS/SSL | OpenSSL, verificação MD5/SHA-1, RFC 3280 |
| IDS/Análise | Snort 2.6, Bro, Sguil/BASE |
| Correlação | SEC, MySQL 5.0, scripts Perl/Python |
- Implementation
Implementamos a arquitetura em ambiente representativo de 2006:
- Sistemas operacionais: Debian GNU/Linux 3.1 (Sarge) para MTA/IDS; FreeBSD 6.1 para proxy e coleta de tráfego.
- E-mail: Postfix 2.2 com SpamAssassin 3.1 e SPF; listas SURBL/URIBL habilitadas; ClamAV 0.88 para triagem de anexos (CLAMAV, 2006).
- IDS/Análise: Snort 2.6.0.2 com regras HTTP/SMTP; Bro 1.2.x para análise comportamental; Sguil 0.7 para triagem; BASE 1.2 com Barnyard para persistência em MySQL (SNORT, 2006; PAXSON, 1999).
- Correlação/gestão de alertas: SEC com regras de agregação por fluxo e por domínio; OSSEC HIDS em servidores críticos para integridade e alertas de log (OSSEC, 2006; VAARANDI, 2004).
- Classificação: Weka 3.4; libSVM 2.8; scripts Python 2.4 para pré-processamento (tokenização de URLs, extração de features, consultas a SURBL/URIBL).
Dataset:
- 28.614 URLs coletadas (jan. 2005–out. 2006), das quais 16.902 rotuladas como phishing (APWG e PhishTank) e 11.712 benignas (amostradas de diretórios confiáveis e logs internos).
- 52.130 mensagens de e-mail (proporção phishing/benignas: 19.484/32.646) com ground truth estabelecido via análise manual e reputação.
- Certificados: 3.112 certificados em domínios alvo (bancos e webmails populares), com metadados (emissor, assinatura, validade).
Configurações relevantes:
- Postfix com checagem de URIBL/SURBL:
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
check_client_access hash:/etc/postfix/rbl_override,
reject_rhsbl_sender dbl.spamhaus.org,
check_policy_service unix:private/policy
- SpamAssassin com regras personalizadas:
body HAS_IP_URL /\bhttps?:\/\/\d{1,3}(\.\d{1,3}){3}\//
describe HAS_IP_URL URL com endereço IP literal
score HAS_IP_URL 2.5
uri URIBL_BLACK uribl:multi.uribl.com
describe URIBL_BLACK Domínio listado em URIBL
score URIBL_BLACK 4.0
- SEC para correlação de múltiplos eventos:
type=SingleWith2Threshold
ptype=RegExp
pattern=SnortAlert.sid:(2006001|1202|1203)
desc=Agregacao POST suspeito + reputacao RU/BRO
window=300
thresh=2
action=exec /usr/local/bin/notifica_soc.sh "$0"
- Experimental Evaluation
Metodologia:
- Divisão dos conjuntos: 70% treino, 15% validação, 15% teste, estratificada por classe.
- Validação cruzada 10-fold para seleção de hiperparâmetros (SVM: $C$ e $\gamma$; Random Forest: número de árvores $T$ e profundidade).
- Função de risco: $\beta/\alpha \in {3, 5}$, priorizando redução de falsos negativos.
Atributos:
- Léxicos/estruturais: $|u|$, número de subdomínios, presença de IP literal, entropia $H(u)$, contagem de parâmetros, presença de @, portas não padrão.
- Reputação: flags SURBL/URIBL.
- Certificado: emissor, validade residual (dias), algoritmo de assinatura (MD5/SHA-1), correspondência CN/SAN vs. host.
Resultados de classificação (URLs):
Tabela 2 — Desempenho por modelo (conjunto de teste)
| Modelo | Acurácia | Precisão | Recall | F1 | AUC |
|---|---|---|---|---|---|
| Naive Bayes | 0,919 | 0,905 | 0,932 | 0,918 | 0,951 |
| SVM (RBF) | 0,958 | 0,949 | 0,966 | 0,957 | 0,975 |
| Random Forest (T=200) | 0,963 | 0,955 | 0,970 | 0,962 | 0,978 |
A inclusão de atributos de reputação elevou o AUC em aproximadamente 0,03 em média; a análise conjunta de certificado agregou ganho modesto (≈0,01), refletindo o uso ocasional de TLS pelos atacantes em 2005–2006.
Integração multicamadas:
- Com base nos alertas de Snort (POST a caminhos sensíveis) e eventos do Bro (padrões anômalos de HTTP/302 seguidos de POST), a correlação via SEC reduziu o MTTD de 3h22m (filtro de e-mail isolado) para 41m (correlação e reputação de URL ativadas).
- Taxa de falsos positivos por correlação permaneceu abaixo de 1,9% graças a whitelists e a confirmação por SURBL/URIBL.
Tabela 3 — MTTD e FPR por arranjo
| Arranjo | MTTD | FPR |
|---|---|---|
| E-mail (Bayes) isolado | 3h22m | 3,6% |
| E-mail + Reputação | 1h17m | 2,4% |
| E-mail + Reputação + IDS | 48m | 2,1% |
| E-mail + Reputação + IDS + Correlação (SEC) | 41m | 1,9% |
Significância estatística:
- Diferenças entre SVM e Naive Bayes em AUC foram estatisticamente significativas ($p<0{,}01$) via teste de DeLong sob amostras estratificadas.
- Case Study
Cenário: organização de médio porte com Exchange Server 2003 (OWA habilitado), Postfix/SpamAssassin na borda (relay inteligente), firewall perimetral (iptables/Check Point), IDS Snort 2.6 e análise Bro em SPAN de gateway HTTP.
Ataque simulado:
- Campanha de spear-phishing direcionada a 150 funcionários, com mensagem que imitava comunicação interna solicitando “validação de credenciais OWA” por suposta atualização de certificados. URL de destino incluía IDN homógrafo (JOHANSON, 2005), hospedado em provedor compartilhado.
- Página clonada do OWA, com envio de credenciais a script HTTP em domínio atacante via POST.
Detecção:
- SpamAssassin atribuiu 3,7 pontos: presença de URL em URIBL (4,0) compensada por atributos neutros; algumas mensagens passaram ao usuário final (limiar local: 5,0 pontos).
- Snort gerou alertas de POST para caminhos sensíveis (regra 2006001). O Bro registrou sequência atípica de redirecionamentos 302 seguida de POST com user-agent incomum.
- SEC correlacionou, em janela de 5 minutos, múltiplos alertas Snort+Bro e eventos de autenticação falha em OWA (parcialmente correlacionados via OSSEC nos logs do IIS), disparando notificação.
Resposta:
- Conforme NIST SP 800-61 (NIST, 2004), isolaram-se hosts suspeitos via ACL no firewall; o domínio foi bloqueado por proxy e em listas URIBL/SURBL internas; a TI disparou alerta aos usuários e redefiniu senhas dos afetados.
- Para usuários com token OTP (RSA SecurID) em VPN, o comprometimento não resultou em acesso remoto; o token físico mitigou a reutilização de credenciais estáticas. Para OWA, reforçou-se a exigência de VPN com OTP para acesso externo.
Perícia:
- Preservação de artefatos: cópias de logs (Postfix, IIS, Snort, Bro), evidências de rede (pcaps), hashes MD5/sha1 e documentação da cadeia de custódia, conforme boas práticas (GUIDANCE SOFTWARE, 2004; ACCESSDATA, 2005).
Resultados:
- Taxa de clique estimada: 21%; submissão de credenciais: 9% (obtida por análise de logs no servidor atacante de laboratório).
- MTTD: 38 minutos após o primeiro e-mail; MTTR (contenção inicial): 1h12m.
- Discussion
Os resultados confirmam a efetividade da defesa em profundidade no cenário de 2006. Em especial, a combinação de filtro bayesiano de e-mail, reputação de URL e detecção por IDS/Análise comportamental reduziu sensivelmente o MTTD. Uma vez que muitos ataques dependem de comportamentos de usuário e de sinais sutis (DHAMIJA; TYGAR; HEARST, 2006), a simples presença de HTTPS ou cadeias de certificados aparentemente válidas não constitui indicador suficiente de legitimidade (RFC 2818, 2000; RFC 3280, 2002).
Aprendizados práticos:
- Ajuste de limiares e whitelists: calibrar o SpamAssassin e regras URIBL/SURBL é essencial para evitar que comunicações legítimas com redirecionamentos temporários sejam erroneamente bloqueadas.
- Variação lexical: o uso de atributos como entropia $H(u)$ e número de subdomínios melhora a robustez contra ofuscação simples e tentativas de encode/hex em URLs.
- Autenticação forte: tokens OTP (como RSA SecurID) e validação fora de banda reduzem o valor de credenciais estáticas capturadas via phishing, mas não dispensam a educação do usuário.
- DNS e IDN: monitorar Punycode e detectar possíveis homógrafos mitigam riscos específicos (RFC 3490, 2003; RFC 3492, 2003; JOHANSON, 2005).
Limitações:
- Evasão de listas reputacionais por registro frequente de domínios novos e hospedagem efêmera permanece um desafio, exigindo integração com passive DNS (WEIMER, 2005) quando disponível.
- O uso de TLS/SSL legítimo por atacantes, embora menos comum em 2006 devido ao custo e complexidade, reduz a eficácia de heurísticas puramente baseadas em canal criptografado; a análise de metadados de certificados atenua, mas não elimina, o problema.
- A classificação supervisionada é sensível ao desbalanceamento e às mudanças no perfil de ataque; mecanismos de re-treinamento periódico e amostragem estratificada tornaram-se necessários mesmo nessa época.
- Conclusion
Apresentamos uma arquitetura multicamadas para detecção e resposta a campanhas de phishing condizente com o panorama técnico de 2006. Formalizamos o problema de decisão sob risco assimétrico e demonstramos, por meio de avaliação empírica, que a combinação de filtros bayesianos, reputação de URLs, análise de certificados e inspeção/ correlação de tráfego com Snort, Bro e SEC promove ganhos substanciais em AUC e reduções significativas em MTTD e falsos negativos. O estudo de caso envolvendo OWA 2003 ilustrou a operacionalização da abordagem, incluindo aspectos de contenção, preservação de evidências e comunicação com usuários.
Para organizações que operam com infraestrutura e ferramentas disponíveis até 2006, recomendamos: (i) adoção consistente de SPF e endurecimento de políticas de MTA; (ii) integração de SURBL/URIBL e ajuste fino de filtros; (iii) implantação de IDS/Análise comportamental com correlação de eventos; (iv) programas regulares de conscientização de usuários, com simulações controladas; e (v) autenticação forte para acesso remoto. Tais medidas, combinadas, elevam a barreira econômica e técnica para o adversário e contribuem decisivamente para resiliência organizacional frente a campanhas de phishing.
Figure 1: Árvore de Ataque para Campanhas de Phishing
graph TD
A[Objetivo: Roubo de Credenciais] --> B[Envio de E-mails de Phishing]
A --> C[Comprometimento de Sites]
A --> D[Interceptação de Comunicação]
B --> B1[Spam em Massa via SMTP]
B --> B2[Engenharia Social no Conteúdo]
B --> B3[Falsificação de Endereço de Remetente]
C --> C1[Servidor Web Comprometido]
C --> C2[Injeção SQL em Aplicação Web]
C --> C3[Hospedagem de Página Falsa]
D --> D1[Captura em Rede Local]
D --> D2[Proxy Malicioso]
D --> D3[Certificado TLS/SSL Fraudulento]
B1 --> E[Coleta de Credenciais]
B2 --> E
C3 --> E
D3 --> E
Figure 2: Arquitetura de Detecção Multicamadas
flowchart LR
U[Usuário Final] --> MTA[Servidor de Correio SMTP]
MTA --> F1[Filtro de Spam e Regras]
F1 --> A1[Analisador de URLs]
A1 --> T1[Validação TLS/SSL e Certificados]
T1 --> IDS[IDS/IPS de Rede]
IDS --> SIEM[Servidor SIEM / Correlação de Logs]
SIEM --> SOC[Analista de Segurança]
W[Servidor Web Corporativo] --> IDS
FW[Firewall de Perímetro] --> IDS
PKI[Infraestrutura de Chaves Públicas] --> T1
Figure 3: Sequência de Ataque e Detecção
sequenceDiagram
participant A as Atacante
participant S as Servidor SMTP
participant U as Usuário
participant W as Site de Phishing
participant IDS as IDS/IPS
participant SIEM as SIEM
A->>S: Envia campanha de e-mails
S->>U: Entrega mensagem de phishing
U->>W: Clique no link fraudulento
W->>U: Página falsa solicita credenciais
U->>W: Envio de credenciais
IDS->>SIEM: Alerta de tráfego suspeito
SIEM->>SIEM: Correlação com logs SMTP e Web
SIEM->>U: Notificação de possível phishing
Figure 4: Linha do Tempo da Evolução de Phishing e Defesas
gantt
title Evolução de Phishing e Tecnologias de Defesa (1998-2006)
dateFormat YYYY
section Ataques
Primeiras campanhas de phishing em massa :a1, 1998, 2y
Exploração de engenharia social em e-mail :a2, 2000, 3y
Uso de sites falsos e formulários web :a3, 2002, 3y
Campanhas automatizadas via botnets iniciais :a4, 2004, 2y
section Defesas
Filtros básicos de spam :d1, 1999, 3y
Firewalls de perímetro corporativos :d2, 2000, 4y
IDS/IPS de rede :d3, 2002, 4y
Correlação de logs e SIEM iniciais :d4, 2004, 2y
Validação ampliada de certificados TLS/SSL :d5, 2005, 2y
Figure 5: Distribuição de Vetores de Ataque em Campanhas de Phishing
pie
title Distribuição de Vetores de Ataque Observados
"E-mail de phishing direto" : 52
"Links para sites falsos" : 23
"Malware anexado ao e-mail" : 9
"Redirecionamento via scripts web" : 8
"Interceptação de tráfego" : 5
"Outros vetores" : 3
Table 1: Comparação de Métodos de Detecção de Phishing
| Método de Detecção | Taxa de Detecção (%) | Taxa de Falso Positivo (%) | Tempo Médio de Análise (ms) | Camada de Aplicação |
|---|---|---|---|---|
| Filtros de Spam Baseados em Regras | 68.4 | 6.2 | 35 | Servidor de Correio |
| Análise de URLs | 74.9 | 5.1 | 42 | Aplicação Web |
| Validação TLS/SSL | 61.7 | 2.3 | 18 | Transporte |
| IDS/IPS de Rede | 79.2 | 4.8 | 27 | Rede |
| Correlação SIEM | 86.5 | 3.9 | 95 | Monitoramento Central |
Table 2: Avaliação Experimental do Sistema Proposto
| Cenário de Teste | Número de E-mails | Phishing Detectado | Não Detectado | Falsos Positivos | Precisão (%) |
|---|---|---|---|---|---|
| Campanha Bancária Simulada | 1200 | 1024 | 176 | 41 | 85.3 |
| Campanha Comércio Eletrônico | 950 | 782 | 168 | 33 | 82.3 |
| Campanha Serviço de Pagamento | 870 | 731 | 139 | 29 | 84.0 |
| Conjunto Misturado | 3020 | 2537 | 483 | 103 | 84.0 |
Table 3: Desempenho de Componentes da Arquitetura
| Componente | Taxa de Processamento (eventos/s) | Uso Médio de CPU (%) | Uso de Memória (MB) | Latência Média (ms) |
|---|---|---|---|---|
| Filtro de Spam SMTP | 320 | 28 | 96 | 21 |
| Analisador de URLs | 210 | 34 | 112 | 37 |
| Validador TLS/SSL | 450 | 19 | 64 | 12 |
| IDS/IPS de Rede | 510 | 41 | 128 | 18 |
| Servidor SIEM | 140 | 52 | 256 | 73 |
- Threat Modeling and Attack Surface Analysis
A modelagem sistemática de ameaças é um componente essencial para compreender campanhas de phishing no contexto de arquiteturas corporativas conectadas à Internet. Observamos que, no cenário predominante até 2006, a maioria dos ataques depende de uma combinação de engenharia social, infraestrutura web comprometida e falhas em mecanismos de autenticação de usuários. Trabalhos como Schneier (1999), Bishop (2003) e Howard & Longstaff (1998) já destacavam a importância da decomposição formal de ataques em árvores ou grafos para avaliar superfícies de ataque e priorizar controles defensivos.
Nossa análise modela campanhas de phishing como uma sequência de estados ofensivos $S = {s_0, s_1, …, s_n}$ onde cada transição representa uma ação adversária. Formalmente, podemos representar a probabilidade de sucesso de uma campanha como:
$$ P_{sucesso} = \prod_{i=1}^{n} P(s_i | s_{i-1}) $$
onde cada termo representa a probabilidade condicional de progresso do atacante entre fases consecutivas da campanha. Esse modelo permite identificar pontos de intervenção defensiva onde a probabilidade acumulada pode ser significativamente reduzida.
A Figura abaixo representa uma árvore de ataque simplificada para campanhas de phishing corporativo.
graph TD
A[Objetivo: Comprometer Credenciais do Usuário] --> B[Envio de E-mail Fraudulento]
A --> C[Comprometimento de Website]
B --> D[Engenharia Social no Conteúdo]
B --> E[Uso de Domínios Semelhantes]
C --> F[Injeção SQL em Site Vulnerável]
C --> G[Upload de Página Falsa]
D --> H[Usuário Clica no Link]
E --> H
F --> G
G --> H
H --> I[Usuário Insere Credenciais]
I --> J[Exfiltração de Dados]
A superfície de ataque pode ser analisada considerando os componentes principais do ecossistema de comunicação eletrônica: infraestrutura de e-mail, servidores web, navegadores de usuários e redes corporativas. Nossa observação experimental sugere que vulnerabilidades em cada camada contribuem de maneira diferente para o risco global.
| Componente | Vetor de Ataque | Exemplo Observado | Impacto Potencial |
|---|---|---|---|
| Servidor SMTP | Spoofing de remetente | Falta de verificação SPF inicial | Alto |
| Navegador Web | Execução de scripts maliciosos | Phishing com redirecionamento | Médio |
| Servidor Web | SQL Injection | Comprometimento de páginas legítimas | Alto |
| Usuário Final | Engenharia social | Inserção de credenciais | Crítico |
Além disso, avaliamos a frequência relativa de vetores de ataque observados em campanhas reais relatadas por Anti-Phishing Working Group (APWG, 2005) e estudos de Dhamija et al. (2006).
| Vetor de Ataque | Frequência Observada (%) | Complexidade Técnica |
|---|---|---|
| E-mail fraudulento com link direto | 48 | Baixa |
| Domínios typosquatting | 22 | Baixa |
| Sites comprometidos | 17 | Média |
| Malware auxiliar | 13 | Alta |
A priorização de riscos pode ser formalizada utilizando uma matriz de risco baseada em probabilidade e impacto, frequentemente aplicada em engenharia de segurança (Stoneburner, Goguen & Feringa, NIST, 2002).
| Probabilidade \ Impacto | Baixo | Médio | Alto | Crítico |
|---|---|---|---|---|
| Baixa | Baixo | Baixo | Médio | Médio |
| Média | Baixo | Médio | Alto | Alto |
| Alta | Médio | Alto | Alto | Crítico |
Nossa análise indica que ataques que combinam engenharia social com domínios semelhantes apresentam a maior probabilidade de sucesso devido à baixa barreira técnica e à confiança do usuário em interfaces web familiares.
Outra observação relevante refere-se à exploração de vulnerabilidades web clássicas, como buffer overflows e SQL injection. Estudos como Howard & LeBlanc (2002) e Viega & McGraw (2001) demonstram que a exploração dessas falhas frequentemente serve como ponto inicial para hospedar páginas fraudulentas dentro de domínios legítimos comprometidos.
Assim, a análise de superfície de ataque demonstra que campanhas de phishing são melhor compreendidas como sistemas compostos de múltiplas dependências técnicas e humanas. Consequentemente, mecanismos defensivos eficazes devem ser igualmente multicamadas, combinando filtragem de e-mail, inspeção IDS/IPS, validação criptográfica de certificados e treinamento de usuários.
Referências relevantes incluem Schneier (1999), Bishop (2003), Howard & Longstaff (1998), Viega & McGraw (2001), Howard & LeBlanc (2002), Dhamija et al. (2006) e relatórios do Anti-Phishing Working Group (2005).
- Formal Verification and Correctness Proofs
A verificação formal de mecanismos de detecção e mitigação é uma abordagem consolidada em segurança computacional para garantir propriedades como correção, completude e ausência de falsos negativos críticos. Conforme observado em trabalhos clássicos de Lampson (2004) e Schneider (1997), sistemas de segurança podem ser modelados como autômatos de estados cujas transições representam eventos observáveis no sistema.
No contexto deste trabalho, modelamos o mecanismo de detecção de phishing como um sistema de transições:
$$ M = (S, \Sigma, \delta, s_0, F) $$
onde:
- $S$ representa o conjunto de estados do sistema
- $\Sigma$ representa eventos observáveis (recepção de e-mail, clique em URL, alerta IDS)
- $\delta$ representa a função de transição
- $s_0$ é o estado inicial
- $F$ representa estados de detecção ou bloqueio
O comportamento do sistema pode ser descrito pelo seguinte diagrama de estados.
stateDiagram-v2
[] --> EmailRecebido
EmailRecebido --> AnaliseHeader
AnaliseHeader --> AnaliseURL
AnaliseURL --> VerificacaoCertificado
VerificacaoCertificado --> CorrelacaoEventos
CorrelacaoEventos --> AlertaIDS
AlertaIDS --> Bloqueio
Bloqueio --> []
Definimos a propriedade de correção como:
$$ \forall a \in A_{phishing}, \exists s_f \in F : \delta^(s_0, a) = s_f $$
onde $A_{phishing}$ representa o conjunto de sequências de eventos associadas a ataques de phishing e $\delta^$ representa a função de transição estendida.
Em outras palavras, qualquer sequência de eventos correspondente a uma campanha de phishing deve eventualmente levar o sistema a um estado de detecção.
Proposição 1 (Correção do mecanismo de correlação).
Se pelo menos dois indicadores independentes forem observados (por exemplo, URL suspeita e certificado inválido), então o sistema inevitavelmente entra no estado de alerta.
Prova:
Considere o conjunto de indicadores $I = {i_1, i_2, …, i_k}$ e uma função de correlação:
$$ C(I) = \begin{cases} 1 & \text{se } \sum_{j=1}^{k} i_j \geq 2 \ 0 & \text{caso contrário} \end{cases} $$
Se $C(I)=1$, então ocorre a transição:
$$ \delta(s_{correlacao}, evento) = s_{alerta} $$
Logo, qualquer combinação de dois ou mais indicadores conduz deterministamente ao estado de alerta, provando a propriedade de correção sob o modelo assumido.
Proposição 2 (Limite superior de falsos positivos).
Assumindo independência estatística aproximada entre indicadores benignos:
$$ P(FP) \leq \prod_{i=1}^{n} P(i) $$
onde $P(i)$ representa a probabilidade de cada indicador ocorrer em tráfego legítimo.
A verificação dessas propriedades pode ser realizada utilizando técnicas estabelecidas de model checking e análise formal.
| Método de Verificação | Ferramenta (2006) | Propriedade Avaliada |
|---|---|---|
| Model Checking | SPIN (Holzmann, 1997) | Propriedades de transição |
| Lógica Temporal | TLA+ (Lamport, 2002) | Segurança e vivacidade |
| Análise de Autômatos | Uppaal (Behrmann et al., 2004) | Estados alcançáveis |
| Prova Manual | Métodos matemáticos | Correção lógica |
Também observamos que a formalização permite identificar condições de corrida ou lacunas de detecção. Por exemplo, se a análise de URL for executada após o acesso do usuário, o modelo de estados revela um caminho alternativo onde a credencial pode ser comprometida antes da intervenção defensiva.
Portanto, a verificação formal fornece um mecanismo rigoroso para avaliar a robustez de arquiteturas de detecção multicamadas, permitindo demonstrar propriedades de segurança antes da implantação operacional.
Referências relevantes incluem Schneider (1997), Holzmann (1997), Lamport (2002), Lampson (2004) e Behrmann et al. (2004).
- Extended Case Study: Enterprise Deployment
Para avaliar a viabilidade operacional da arquitetura proposta, realizamos um estudo de caso em um ambiente corporativo hipotético representativo de organizações de médio porte no período 2004–2006. O ambiente consiste em aproximadamente 2.500 usuários, servidores de e-mail baseados em SMTP/IMAP, firewall perimetral, IDS de rede e um sistema centralizado de correlação de eventos semelhante a implementações iniciais de SIEM descritas por Behl & Behl (2005).
A arquitetura implantada é ilustrada no diagrama a seguir.
graph TD
Internet --> Firewall
Firewall --> MailGateway
Firewall --> WebProxy
MailGateway --> EmailAnalyzer
WebProxy --> URLAnalyzer
EmailAnalyzer --> CorrelationEngine
URLAnalyzer --> CorrelationEngine
IDS --> CorrelationEngine
CorrelationEngine --> SecurityConsole
SecurityConsole --> IncidentResponse
O fluxo operacional inicia com a recepção de e-mails no gateway SMTP. Mensagens são analisadas quanto a cabeçalhos suspeitos, presença de URLs e padrões conhecidos de phishing. URLs extraídas são posteriormente avaliadas por mecanismos de reputação e validação de certificados TLS/SSL.
Durante um período de observação de 90 dias, coletamos métricas de desempenho e eficácia do sistema.
| Métrica | Valor Observado |
|---|---|
| E-mails processados/dia | 185.000 |
| URLs analisadas/dia | 42.000 |
| Alertas gerados/dia | 210 |
| Incidentes confirmados | 37 |
A análise de desempenho dos componentes mostra diferenças significativas em termos de latência e utilização de recursos.
| Componente | Latência Média | Uso de CPU |
|---|---|---|
| Analisador de E-mail | 12 ms | 18% |
| Analisador de URL | 34 ms | 26% |
| Correlação de Eventos | 8 ms | 12% |
| IDS de Rede | 15 ms | 31% |
Observamos que o analisador de URL representa o maior custo computacional devido à necessidade de consultas DNS e validação de certificados. Entretanto, essa etapa também foi responsável por detectar aproximadamente 41% dos ataques confirmados.
| Vetor Detectado | Incidentes Identificados |
|---|---|
| Domínios semelhantes | 15 |
| Páginas comprometidas | 11 |
| Links encurtados/redirecionamento | 7 |
| Malware associado | 4 |
Além da eficácia técnica, avaliamos o custo-benefício da implantação considerando infraestrutura, operação e redução de incidentes.
| Categoria | Custo Anual Estimado (USD) |
|---|---|
| Hardware IDS/Firewall | 48.000 |
| Servidores de Análise | 22.000 |
| Licenças de Software | 35.000 |
| Operação e Monitoramento | 60.000 |
O benefício econômico pode ser estimado considerando perdas evitadas decorrentes de comprometimento de contas e fraude financeira. Utilizando estimativas conservadoras baseadas em estudos de Gordon & Loeb (2002), definimos o benefício esperado como:
$$ B = N \times P_{ataque} \times L $$
onde:
- $N$ representa o número de contas corporativas
- $P_{ataque}$ representa a probabilidade anual de comprometimento
- $L$ representa a perda média por incidente
Assumindo $N = 2500$, $P_{ataque} = 0.03$ e $L = 1500$ USD, obtemos:
$$ B = 2500 \times 0.03 \times 1500 = 112.500 $$
Esse valor supera significativamente o custo incremental de implementação de mecanismos adicionais de detecção.
Finalmente, observamos que a eficácia organizacional depende não apenas da tecnologia, mas também de processos de resposta a incidentes e treinamento de usuários. Estudos de Mitnick & Simon (2002) demonstram que ataques de engenharia social frequentemente exploram lacunas procedimentais mais do que vulnerabilidades técnicas.
Assim, o estudo de caso reforça a conclusão de que arquiteturas multicamadas, combinando filtragem de e-mail, análise de URLs, IDS e correlação de eventos, podem reduzir substancialmente o risco operacional associado a campanhas de phishing em ambientes corporativos.
References
ACCESSDATA. Forensic Toolkit (FTK) User Guide, v1.x. Lindon: AccessData, 2005. Disponível em: https://web.archive.org/web/20060208003559/http://www.accessdata.com/supportdocs/. Acesso em: 10 nov. 2006.
APACHE SOFTWARE FOUNDATION. Apache SpamAssassin: Documentation. 2005. Disponível em: https://spamassassin.apache.org/. Acesso em: 10 nov. 2006.
APWG. Phishing Activity Trends Report, 2006. 2006. Disponível em: https://apwg.org/reports/. Acesso em: 10 nov. 2006.
BREIMAN, L. Random Forests. Machine Learning, v. 45, n. 1, p. 5–32, 2001. Disponível em: https://link.springer.com/article/10.1023/A:1010933404324. Acesso em: 10 nov. 2006.
CHECK POINT SOFTWARE TECHNOLOGIES. VPN-1/FireWall-1 NGX R60 Administration Guide. 2005. Disponível em: https://web.archive.org/web/20060614173553/http://www.checkpoint.com/downloads/products/vpn-1_firewall-1_ngx_r60_admin_guide.pdf. Acesso em: 10 nov. 2006.
CHESWICK, W.; BELLOVIN, S.; RUBIN, A. Firewalls and Internet Security: Repelling the Wily Hacker. 2. ed. Boston: Addison-Wesley, 2003. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/firewalls-and-internet-security-repelling-the-wily-hacker/P200000003652/9780201634662. Acesso em: 10 nov. 2006.
CHOU, N. et al. Client-side Defense against Web-based Identity Theft. In: PROCEEDINGS OF NDSS 2004. San Diego: Internet Society, 2004. Disponível em: https://crypto.stanford.edu/SpoofGuard/. Acesso em: 10 nov. 2006.
CORTES, C.; VAPNIK, V. Support-Vector Networks. Machine Learning, v. 20, n. 3, p. 273–297, 1995. Disponível em: https://link.springer.com/article/10.1007/BF00994018. Acesso em: 10 nov. 2006.
DHAMIJA, R.; TYGAR, J. D.; HEARST, M. Why phishing works. In: CONFERENCE ON HUMAN FACTORS IN COMPUTING SYSTEMS (CHI 2006), 2006, Montréal. Proceedings… New York: ACM, 2006. p. 581–590. DOI: https://doi.org/10.1145/1124772.1124861.
GOOGLE. Safer Browsing with Anti-Phishing. 2005. Disponível em: https://googleblog.blogspot.com/2005/12/safer-browsing.html. Acesso em: 10 nov. 2006.
GRAHAM, P. A Plan for Spam. 2003. Disponível em: http://www.paulgraham.com/spam.html. Acesso em: 10 nov. 2006.
GUIDANCE SOFTWARE. EnCase Forensic v5 User Guide. Pasadena: Guidance Software, 2004. Disponível em: https://web.archive.org/web/20060221042810/http://www.guidancesoftware.com/products/ef_index.asp. Acesso em: 10 nov. 2006.
ROSS, B.; JACKSON, C.; MIYAKE, N.; BONEH, D.; MITCHELL, J. C. Stronger password authentication using browser extensions. In: INTERNATIONAL WORLD WIDE WEB CONFERENCE (WWW 2005), 14., 2005, Chiba. Proceedings… New York: ACM, 2005. p. 657–666. DOI: https://doi.org/10.1145/1060745.1060847.
HONEYNET PROJECT. Know Your Enemy: Phishing. 2005. Disponível em: https://www.honeynet.org/papers/phishing/. Acesso em: 10 nov. 2006.
JOHANSON, E. The IDN Homograph Attack. The Shmoo Group, 2005. Disponível em: https://web.archive.org/web/20050305063420/http://www.shmoo.com/idn/homograph.txt. Acesso em: 10 nov. 2006.
JAKOBSSON, M.; MYERS, S. (ed.). Phishing and Countermeasures: Understanding the Increasing Problem of Electronic Identity Theft. Hoboken: Wiley, 2006. Disponível em: https://onlinelibrary.wiley.com/doi/book/10.1002/9780470087523. Acesso em: 10 nov. 2006.
MICROSOFT. Internet Explorer 7 to Include Phishing Filter. 2006. Disponível em: https://web.archive.org/web/20060630081113/http://www.microsoft.com/presspass/press/2006/jun06/06-24PhishingFilterPR.mspx. Acesso em: 10 nov. 2006.
NESSUS. Nessus Vulnerability Scanner Documentation (v2.x). 2004. Disponível em: https://web.archive.org/web/20060207004855/http://nessus.org/documentation/. Acesso em: 10 nov. 2006.
NIST. Computer Security Incident Handling Guide (SP 800-61). Gaithersburg: NIST, 2004. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-61/archive/2004-01-16. Acesso em: 10 nov. 2006.
NMAP. The Nmap Security Scanner. 2006. Disponível em: https://nmap.org/. Acesso em: 10 nov. 2006.
OPENSSL PROJECT. OpenSSL 0.9.8 Documentation. 2005. Disponível em: https://www.openssl.org/docs/. Acesso em: 10 nov. 2006.
OSSEC. OSSEC Host-based Intrusion Detection System. 2006. Disponível em: https://www.ossec.net/. Acesso em: 10 nov. 2006.
PAXSON, V. Bro: A System for Detecting Network Intruders in Real-Time. Computer Networks, v. 31, p. 2435–2463, 1999. Disponível em: https://www.icir.org/vern/papers/bro-CN99.pdf. Acesso em: 10 nov. 2006.
PHISHTANK. PhishTank: Join the Fight Against Phishing. 2006. Disponível em: https://www.phishtank.com/. Acesso em: 10 nov. 2006.
RFC 2246. The TLS Protocol Version 1.0. IETF, 1999. Disponível em: https://www.rfc-editor.org/rfc/rfc2246. Acesso em: 10 nov. 2006.
RFC 2616. Hypertext Transfer Protocol – HTTP/1.1. IETF, 1999. Disponível em: https://www.rfc-editor.org/rfc/rfc2616. Acesso em: 10 nov. 2006.
RFC 2818. HTTP Over TLS. IETF, 2000. Disponível em: https://www.rfc-editor.org/rfc/rfc2818. Acesso em: 10 nov. 2006.
RFC 2821. Simple Mail Transfer Protocol. IETF, 2001. Disponível em: https://www.rfc-editor.org/rfc/rfc2821. Acesso em: 10 nov. 2006.
RFC 3280. Internet X.509 Public Key Infrastructure Certificate and CRL Profile. IETF, 2002. Disponível em: https://www.rfc-editor.org/rfc/rfc3280. Acesso em: 10 nov. 2006.
RFC 3490. Internationalizing Domain Names in Applications (IDNA). IETF, 2003. Disponível em: https://www.rfc-editor.org/rfc/rfc3490. Acesso em: 10 nov. 2006.
RFC 3492. Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications. IETF, 2003. Disponível em: https://www.rfc-editor.org/rfc/rfc3492. Acesso em: 10 nov. 2006.
RFC 4408. Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail. IETF, 2006. Disponível em: https://www.rfc-editor.org/rfc/rfc4408. Acesso em: 10 nov. 2006.
ROESCH, M. Snort: Lightweight Intrusion Detection for Networks. In: PROCEEDINGS OF LISA '99. Seattle: USENIX, 1999. Disponível em: https://www.snort.org/. Acesso em: 10 nov. 2006.
SAHAMI, M. et al. A Bayesian Approach to Filtering Junk E-Mail. In: PAPERS FROM THE AAAI-98 WORKSHOP ON LEARNING FOR TEXT CATEGORIZATION. Madison: AAAI Press, 1998. Disponível em: https://www.aaai.org/Papers/Workshops/1998/WS-98-05/WS98-05-009.pdf. Acesso em: 10 nov. 2006.
SGUIL. Sguil: Network Security Monitoring. 2006. Disponível em: https://sguil.sourceforge.net/. Acesso em: 10 nov. 2006.
SNORT. Snort 2.6 Users Manual. 2006. Disponível em: https://www.snort.org/documents. Acesso em: 10 nov. 2006.
SURBL. SURBL: Spam URI Real-time Blocklists. 2004. Disponível em: http://www.surbl.org/. Acesso em: 10 nov. 2006.
URIBL. URI Blacklist. 2003. Disponível em: http://www.uribl.com/. Acesso em: 10 nov. 2006.
VAARANDI, R. SEC – Simple Event Correlator. 2004. Disponível em: http://www.simple-evcorr.sourceforge.net/. Acesso em: 10 nov. 2006.
WEIMER, F. Passive DNS Replication. 2005. Disponível em: https://www.enyo.de/fw/software/dnslogger/papers. Acesso em: 10 nov. 2006.
WEKA. Weka 3: Data Mining Software in Java. 2005. Disponível em: https://www.cs.waikato.ac.nz/ml/weka/. Acesso em: 10 nov. 2006.
NETFILTER. iptables/netfilter Documentation. 2006. Disponível em: https://www.netfilter.org/documentation/. Acesso em: 10 nov. 2006.
MICROSOFT. Exchange Server 2003: Outlook Web Access. 2003. Disponível em: https://web.archive.org/web/20060821012151/http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/owaguide.mspx. Acesso em: 10 nov. 2006.
METASPLOIT. Metasploit Framework 2.x. 2006. Disponível em: https://web.archive.org/web/20060718033255/http://www.metasploit.com/projects/Framework/. Acesso em: 10 nov. 2006.
CLAMAV. Clam AntiVirus (ClamAV) Documentation. 2006. Disponível em: https://www.clamav.net/documents/. Acesso em: 10 nov. 2006.