A exploração de aplicações web por meio de injeções SQL baseia‑se na capacidade de inserir cadeias de entrada que são concatenadas diretamente em comandos SQL no backend. Símbolos e tokens simples — como %, *, ;, --, _, operadores lógicos (OR, AND), e expressões tautológicas como 1=1 — tornam‑se ferramentas poderosas quando a aplicação não separa corretamente dados e comando. Um exemplo elucidativo: se a aplicação monta a consulta select * from users where name = 'value'; e o campo value é substituído literalmente pelo input do utilizador, a entrada Mark'; drop table users; -- transforma a consulta em select * from users where name = 'Mark'; drop table users; -- ; — qualquer texto após -- é ignorado pelo parser SQL, e a instrução de deleção é executada. Outro padrão recorrente é ' or 1=1;-- que converte a condição em sempre verdadeira, conduzindo à devolução de todas as linhas da tabela. Mesmo inputs que provocam erro de sintaxe, por exemplo inserindo um apóstrofo extra (Mark'), podem ser úteis ao revelar mensagens de erro detalhadas do servidor, expondo estrutura de tabelas, nomes de colunas ou o tipo de motor de base de dados.

Cross‑Site Scripting (XSS) explora outro corredor: o navegador do utilizador. Quando uma aplicação ecoa ou armazena conteúdo do utilizador sem sanitização adequada, o código malicioso pode ser executado no contexto do cliente, roubando cookies, tokens de sessão ou manipulando a interface do utilizador. Existem variantes distintas: reflected XSS, em que o payload é imediatamente devolvido na resposta; DOM‑based XSS, em que a modificação do ambiente do DOM pelo cliente altera o comportamento do script; e stored XSS, em que o payload persiste no servidor (por exemplo em comentários ou registos) e é servido a outros utilizadores. Ferramentas como XSSer e outras soluções de scanning automatizado ajudam a detectar vetores de XSS ao simular payloads e analisar respostas, e dispõem frequentemente de interfaces gráficas e modos linha de comando para testes de formulários e parâmetros.

A compreensão operacional das duas famílias de vulnerabilidades exige não apenas a memorização de payloads ou comandos de ferramenta, mas a percepção dos vetores de inserção de dados e do fluxo de tratamento: onde os dados do utilizador entram, como são concatenados às consultas ou ao DOM, que mecanismos de escaping e parametrização existem, e quais mensagens de erro o servidor devolve. A leitura atenta de respostas, logs e mensagens de erro permite inferir o motor de base de dados, a existência de colunas sensíveis e as permissões do utilizador da conexão.

Como operam os rootkits em modo usuário e modo kernel — e como detectá‑los?

O kernel, por sua vez, constitui um vetor de maior privilégio: controla comunicação entre processos, gestão de memória, interrupções, sistemas de arquivos e interfaces com hardware; a sua integridade é assegurada por proteções de hardware que implementam níveis de privilégio (rings), sendo o Ring 0 o domínio do kernel. Rootkits de modo kernel exploram esse privilégio para esconder processos e ficheiros, redirecionar solicitações de execução e interceptar chamadas ao sistema. As técnicas variam: módulos de kernel (loadable kernel modules) que se instalam como drivers, alterações diretas em estruturas de memória do kernel, manipulação da camada de virtualização ou mesmo corrompção de binários do próprio kernel em disco. Ferramentas históricas como o Adore exemplificam a potência dessas técnicas: um módulo carregável associado a um utilitário de controlo permite ocultar portas de rede, processos, entradas de wtmp/utmp/lastlog e suprimir registos do syslog, além de oferecer backdoor de shell com privilégios, sendo adaptado a várias versões do kernel e compatível com sistemas FreeBSD nas versões apropriadas.

Como manter acesso pós-exploração e validar um shell reverso?

Para estabelecer e verificar um shell reverso, é necessário primeiro declarar os parâmetros de ligação no manipulador local: o endereço do atacante (LHOST) e a porta de escuta (LPORT). Por exemplo, definir set LHOST 192.168.20.130 e set LPORT 4444 prepara o listener para receber a conexão de retorno. Uma vez definidos os valores, a execução do exploit inicia o handler e, em ambiente controlado, produz saídas que comprovam a aceitação das conexões e a negociação dos sockets: inicialização do handler, aceitação de clientes, escrita e leitura entre os sockets A e B e o pareamento dos tokens de verificação. A abertura de uma sessão de shell de comando normalmente aparece com a indicação do par de endpoints e o carimbo temporal, por exemplo: Command shell session 1 opened (192.168.20.130:4444 -> 192.168.20.131:38897) at 2023-06-18 .... Após a abertura, comandos como id servem para identificar o contexto de execução do processo remoto (por exemplo uid=1(daemon) gid=1(daemon) groups=1(daemon)), informação essencial para planejar passos subsequentes de pós-exploração ou de contenção.

A síntese final de pós‑exploração assinala que entender o raciocínio de um atacante e dominar as vulnerabilidades exploráveis é condição sine qua non para proteger ativos e arquiteturas. O praticante ético deve manter atualização contínua sobre vetores emergentes, participar de comunidades técnicas e aproveitar cursos e certificações que consolidem conhecimento prático e normativo. Também é imperativo compreender o modelo de responsabilidade partilhada em nuvem, as diferenças entre IaaS/PaaS/SaaS, e como misconfigurações ou credenciais expostas ampliam superfícies de ataque.

Importante acrescentar ao texto: sempre operar apenas com autorização explícita e documentada; registrar e preservar evidências durante qualquer exercício de segurança; minimizar técnicas que alterem estado de produção permanente; priorizar médições que permitam reversão completa após testes. Acrescentar orientações sobre coleta e análise de logs (sistemas de arquivos, syslog, EDR/NDR), monitoramento de integridade (FIM), e procedimentos de resposta a incidentes melhora a utilidade prática do capítulo. Explicar os sinais de comprometimento mais sutis — anomalias em conexões de saída, criação de contas incomuns, módulos de kernel inesperados — e descrever critérios para diferenciar atividade legítima de atividade maliciosa é crucial. Finalmente, destacar a necessidade de documentação técnica clara dos passos realizados durante testes (com timestamps e hash de artefatos) e políticas de disclosure responsáveis completa o panorama que o leitor deve incorporar além do conteúdo exposto.

Como capturar e analisar tráfego de rede de forma prática e segura?

O uso de imagens vulneráveis como Metasploitable 2 permanece valioso porque permite praticar técnicas sem riscos ao ambiente produtivo; a imagem é baixada, extraída e aberta no hipervisor — atenção redobrada se for exposta à Internet, pois a máquina contém inúmeras vulnerabilidades conhecidas. Antes de iniciar qualquer captura, verifique o endereço IP da máquina alvo (por exemplo, com $ ifconfig) e anote-o; no laboratório do exemplo, esse endereço era 192.168.111.170.

Para cenários que exigem máxima precisão, utilizam‑se dispositivos de hardware — network taps — que replicam fisicamente a transmissão entre cabo e hosts. Exemplos como o Throwing Star LAN tap provêm uma cópia não intrusiva do sinal para análise. Em redes com switches, o tap ou uma configuração de espelhamento (port mirroring) é quase sempre necessária, já que as topologias modernas não encaminham todo o tráfego para uma única porta por padrão.

O procedimento prático para capturar tráfego não encriptado foi exemplificado com DVWA (Damn Vulnerable Web Application). Inicie a captura no Wireshark (ícone em forma de barbatana) antes de executar a ação que deseja observar — por exemplo, o login admin:password via HTTP. Após parar a captura, é possível filtrar e reduzir o volume de pacotes para análise. Filtros de exibição do Wireshark seguem a sintaxe [Protocolo].[campo] [operador] [valor]; como exemplo, ip.dst == 192.168.111.170 mostra somente pacotes cujo destino é o IP alvo. Diferencie filtros de captura (aplicados no momento da gravação para limitar o que é escrito no pcap) de filtros de exibição (aplicados sobre o arquivo já capturado para facilitar a investigação).

HTTP trafega em texto claro — por isso, credenciais e sessões podem ser visíveis nas capturas quando não há criptografia. Esse é o motivo pelo qual inspecionar pacotes é útil para validar conectividade, diagnosticar latências e gargalos, construir linhas do tempo em investigações forenses e detectar indicadores de comprometimento via inspeção profunda de pacotes. Em contrapartida, tráfego TLS/HTTPS exige outra abordagem: metadados, análise de padrões de fluxo e, quando disponível e autorizada, uso de chaves privadas ou proxies de inspeção para dessifrar sessões (sempre dentro de limites legais e éticos).

Práticas técnicas importantes a considerar: sincronize relógios das máquinas do laboratório (NTP) para que timestamps de pacotes sejam confiáveis ao correlacionar eventos; prefira salvar capturas em formato pcap(ng) para preservar metadados; armazene arquivos grandes externamente e use índices ou filtros para recuperar trechos relevantes; automatize análises com scripts que parseiem pcap quando for necessário processar grandes volumes. Para wifi, uma placa compatível com modo monitor é necessária e o procedimento difere levemente devido às camadas físicas e à presença de frames de gestão.

Como revelar credenciais e analisar tráfego HTTP/TLS com Wireshark?

Aplicar filtros é o primeiro passo para transformar um volume massivo de pacotes em informação útil. Ao restringir a captura ao tráfego destinado a um host específico obtemos um conjunto manejável, mas geralmente ainda amplo — por isso empregamos filtros semânticos sobre o conteúdo dos protocolos. Um filtro simples e eficaz para descobrir autenticações em texto claro é: tcp contains login. Com ele, os pacotes retornados concentram comunicações TCP onde a string “login” aparece, tornando possível localizar requisições HTTP que transportem credenciais em texto puro.

Ao inspecionar um desses pacotes no painel de descrição do Wireshark, expanda as seções Ethernet II, Internet Protocol Version 4 e Transmission Control Protocol para obter, respectivamente, endereços MAC de origem/destino, endereços IP e portas TCP. A seção Hypertext Transfer Protocol revelará a requisição web em si; ao abrir os campos do HTTP frequentemente se identificam campos de formulário (POST/GET) contendo username e password em texto simples. A capacidade nativa do Wireshark de reassemblar streams TCP (Follow → TCP Stream ou o atalho Ctrl+Alt+Shift+T) permite visualizar a sequência completa de negociação cliente‑servidor — inclusive os pares POST/GET que carregam credenciais — facilitando a leitura contínua da sessão sem ter de saltar entre pacotes isolados.

Para fins de análise forense de tráfego TLS, a decriptação ao vivo só é possível quando se dispõe das chaves de sessão. Existem duas abordagens práticas: capturar a chave privada do servidor (nem sempre suficiente, especialmente se o servidor usa Perfect Forward Secrecy) ou obter os segredos de sessão (pre‑master/master secrets) exportados pelo cliente. Navegadores e ferramentas modernas podem ser configurados para gravar o arquivo de log de chaves (SSLKEYLOGFILE), que contém os segredos necessários para o Wireshark reconstituir e decifrar streams TLS. Com esse arquivo em mãos, abra Wireshark, vá a Edit → Preferences → Protocols → TLS (ou “SSL” em versões 2.x) e aponte para o arquivo de log de chaves; após isso as mensagens TLS serão desembrulhadas e o conteúdo HTTP reaparecerá nos pacotes apropriados. Nem sempre isto funcionará: se o cifrador usar Perfect Forward Secrecy (e o log de chaves não contiver os segredos corretos), a decriptação será impossível mesmo dispondo da chave privada do servidor.