TryHackMe Penetration Testing Frameworks (versão em português)

Introdução

Imagine que você acabou de conseguir seu primeiro trabalho como pentester. O cliente é uma empresa de e-commerce de médio porte e quer que você avalie a segurança da aplicação web, da rede interna e da conscientização de segurança dos colaboradores. Você se senta, abre o notebook e então, por onde começa? Já sai executando o Nmap imediatamente? Testa primeiro a página de login em busca de SQL injection? Tenta aplicar phishing em um funcionário?

Sem uma abordagem estruturada, um teste de invasão rapidamente se transforma em um conjunto desorganizado de verificações aleatórias. Você pode deixar passar superfícies de ataque críticas, pular documentações importantes ou entregar achados que o cliente não consegue usar de forma prática. Pior ainda: pode acabar testando sistemas que nunca fizeram parte do escopo e se colocar em uma situação legal complicada. É exatamente esse problema que os frameworks de pentest resolvem.

Um framework de pentest é uma metodologia estruturada que orienta profissionais de segurança por todas as etapas de um trabalho, desde o planejamento inicial e a definição de escopo até a exploração, o relatório e a validação das correções.

Pense na analogia de um inspetor predial seguindo uma checklist de conformidade com normas de construção: o inspetor não sai andando pelo prédio esperando encontrar problemas por acaso. Em vez disso, ele segue um processo sistemático que garante que cada elemento estrutural, sistema elétrico e medida de segurança contra incêndio seja avaliado com base em um padrão conhecido. Frameworks de pentest cumprem o mesmo papel em avaliações de segurança.

A adoção de uma metodologia estruturada traz vários benefícios. Ela garante abrangência, evitando que áreas críticas sejam deixadas de lado. Promove consistência, permitindo que diferentes testers da mesma equipe produzam resultados comparáveis. Também apoia a conformidade, alinhando a avaliação a requisitos regulatórios. Além disso, melhora a comunicação, pois clientes, auditores e stakeholders conseguem entender e confiar em um processo baseado em um padrão reconhecido.

Existem muitos frameworks de pentest em uso atualmente, e cada um possui sua própria filosofia, seus pontos fortes e seus casos de uso ideais. Nesta sala, exploraremos os seguintes em profundidade:

Open Source Security Testing Methodology Manual — OSSTMM, uma abordagem científica e orientada por métricas para testes de segurança.

OWASP Web Security Testing Guide — WSTG, o framework de referência para avaliações de aplicações web.

NIST Special Publication 800–115, o guia técnico do governo dos Estados Unidos para testes e avaliações de segurança.

Penetration Testing Execution Standard — PTES, um padrão prático, orientado por fases, que reflete como trabalhos reais de pentest são conduzidos.

Information Systems Security Assessment Framework — ISSAF, uma metodologia historicamente influente com um modelo detalhado de avaliação em nove etapas.

Também apresentaremos o MITRE ATT&CK como uma base de conhecimento complementar que mapeia táticas e técnicas de adversários.

Além disso, faremos um panorama de vários outros frameworks relevantes, incluindo o WASC Threat Classification, o CSA Cloud Controls Matrix, o OWASP Mobile Application Security Testing Guide — MASTG, as PCI DSS Penetration Testing Guidelines e o CBEST Framework, para que você saiba quando e onde cada um se aplica.

Objetivos de aprendizagem

Descrever o propósito e a estrutura dos principais frameworks de pentest.

Comparar frameworks com base em seu escopo, metodologia e casos de uso pretendidos.

Selecionar um framework apropriado para um determinado cenário de trabalho.

Explicar como o MITRE ATT&CK complementa metodologias tradicionais de pentest.

Pré-requisitos

Familiaridade com conceitos básicos de redes.

Compreensão geral do que envolve um teste de invasão.

Responda às perguntas abaixo:

Um pentester executa várias ferramentas contra um alvo, mas ignora completamente o mapeamento de rede e não documenta o escopo com antecedência. Qual benefício do uso de um framework teria evitado essa situação de forma mais direta?

Resposta: Thoroughness

Seu cliente atua no setor de saúde e precisa demonstrar conformidade com a HIPAA. Além de identificar vulnerabilidades, qual benefício do uso de um framework reconhecido seria mais importante para esse cliente?

Resposta: Compliance

OSSTMM

Visão geral

Você provavelmente já ouviu a frase "não dá para gerenciar aquilo que não se consegue medir". Na maioria das disciplinas de engenharia, a quantificação é algo esperado: um engenheiro estrutural não declara que uma ponte é "segura" com base na intuição. No entanto, em testes de invasão, os achados muitas vezes são entregues como narrativas subjetivas. O Open Source Security Testing Methodology Manual, ou OSSTMM, busca mudar isso.

Desenvolvido pelo Institute for Security and Open Methodologies — ISECOM, o OSSTMM, atualmente na versão 3, aplica o método científico aos testes de segurança. Sua característica principal é colocar métricas acima de opiniões: em vez de entregar julgamentos subjetivos de risco, o OSSTMM produz resultados quantificáveis, verificáveis e repetíveis.

O OSSTMM organiza os testes em cinco canais de segurança, refletindo sua filosofia de que segurança não é apenas um problema de rede:

Human Security — HUMSEC: engenharia social e vulnerabilidades relacionadas ao fator humano.

Physical Security — PHYSSEC: controles de acesso físico, desde leitores de crachá até tailgating.

Wireless Communications — SPECSEC: Wi-Fi, Bluetooth, RFID e outros sinais eletromagnéticos.

Telecommunications — COMSEC: sistemas telefônicos, VoIP, fax e infraestrutura de modems.

Data Networks — DATASEC: serviços de rede, firewalls e protocolos da camada de aplicação.

Uma organização pode ter regras de firewall impecáveis, mas, se um atacante conseguir entrar na sala de servidores seguindo alguém pela porta, ou seja, por tailgating em PHYSSEC, ou induzir por engenharia social a redefinição de uma credencial em HUMSEC, esses controles de rede se tornam irrelevantes. Os cinco canais garantem que nada seja deixado de lado.

No centro da abordagem quantitativa do OSSTMM estão os Risk Assessment Values, ou RAVs. Um RAV mede o equilíbrio entre a superfície total de ataque, isto é, a exposição, e os controles que a protegem. Um RAV positivo indica risco residual; um RAV próximo de zero sugere que os controles estão bem ajustados à exposição. Esse resultado numérico significa que dois testers avaliando o mesmo alvo deveriam chegar a resultados comparáveis, assim como dois engenheiros medindo a mesma viga deveriam calcular tolerâncias de tensão semelhantes.

Fases: um passo a passo

O ciclo de testes do OSSTMM possui quatro fases. Vamos percorrê-las usando um cenário: sua equipe está avaliando a rede externa da FinVault Corp, uma empresa de serviços financeiros, com escopo definido para 10.0.113.0/24 e para o portal de clientes em portal.finvault-corp.thm.

Fase 1: Induction cobre enumeração e verificação. Você mapeia o que existe e confirma se é real. Na FinVault, você consulta DNS, revisa logs de transparência de certificados e descobre subdomínios como vpn.finvault-corp.thm e mail.finvault-corp.thm. Em seguida, verifica se cada ativo está online e responsivo. O resultado é um inventário confirmado do ambiente-alvo.

Fase 2: Interaction cobre qualificação e quantificação. Você sonda ativamente os ativos verificados e avalia sua relevância. Na FinVault, você se conecta a cada serviço, identifica suas tecnologias e quantifica a exposição: 12 serviços acessíveis externamente em 8 hosts, sendo que 4 aceitam conexões não autenticadas. Esses achados alimentam diretamente o cálculo da superfície de ataque.

Fase 3: Inquiry cobre escalação de privilégios e verificação da escalação. Você testa se a exposição medida pode ser convertida em acesso não autorizado. Na FinVault, você descobre uma vulnerabilidade de IDOR no portal do cliente que permite que um usuário autenticado leia extratos de conta de outro cliente. A verificação da escalação confirma o escopo: acesso de leitura a 12.000 contas, sem acesso de escrita.

Fase 4: Intervention cobre quarentena, auditoria e enticement. Você trata os achados e examina o ambiente de controle mais amplo. Na FinVault, o endpoint vulnerável é restringido. Ao mesmo tempo, um patch é desenvolvido, caracterizando a quarentena; o modelo mais amplo de controle de acesso é examinado em busca de falhas semelhantes, caracterizando a auditoria; e um canary token é implantado para testar as capacidades internas de detecção, caracterizando o enticement.

Observações finais

O OSSTMM prescreve o formato Security Test Audit Report — STAR para os entregáveis, reforçando a consistência e permitindo comparabilidade entre equipes.

Seu rigor científico é, ao mesmo tempo, sua maior força e sua principal barreira. O framework OSSTMM torna os resultados auditáveis e comparáveis, algo raro em testes de invasão. No entanto, a curva de aprendizado é íngreme, implementações completas podem consumir bastante tempo e profissionais experientes em OSSTMM são mais difíceis de encontrar do que aqueles treinados em metodologias como OWASP ou NIST.

O OSSTMM é mais adequado para organizações que precisam de medições de segurança repetíveis e auditáveis, e que estão dispostas a investir no domínio da metodologia.

Responda às perguntas abaixo:

Qual métrica do OSSTMM quantifica o equilíbrio entre a superfície de ataque de uma organização e seus controles?

Resposta: Risk Assessment Values

Durante uma avaliação OSSTMM, você conclui as fases de Induction e Interaction, identificando 6 hosts executando serviços sem patch. Em qual fase você entra em seguida, e qual é o objetivo principal?

Resposta: Inquiry

OWASP WSTG

Visão geral

Você está testando uma aplicação web para uma loja online. A aplicação lida com cadastro de usuários, busca de produtos, carrinho de compras, processamento de pagamentos e rastreamento de pedidos. Por onde começar? Você testa primeiro o formulário de login? A barra de busca? A API de pagamento?

Com dezenas de possíveis superfícies de ataque em uma única aplicação web, é fácil acabar testando as mesmas coisas duas vezes ou, pior, deixar classes inteiras de vulnerabilidades passarem despercebidas.

O Open Web Application Security Project, ou OWASP, aborda esse problema com o Web Security Testing Guide — WSTG. Embora a OWASP seja mais conhecida pela lista OWASP Top Ten, que reúne vulnerabilidades críticas em aplicações web, o WSTG vai muito além: ele é um framework abrangente, mantido pela comunidade, que organiza testes de aplicações web em mais de 90 casos de teste distintos, agrupados em doze categorias.

Essas doze categorias cobrem toda a superfície de ataque de uma aplicação web moderna. Elas incluem coleta de informações, gerenciamento de configuração e implantação, gerenciamento de identidade, autenticação, autorização, gerenciamento de sessão, validação de entrada, tratamento de erros, criptografia, lógica de negócio, testes no lado do cliente e testes de API.

Cada categoria contém casos de teste numerados, como WSTG-INPV-01 para reflected cross-site scripting, com orientações passo a passo sobre o que testar e como testar.

O WSTG adota uma abordagem baseada em risco: as vulnerabilidades são priorizadas com base em sua explorabilidade e impacto, e não apenas catalogadas. Essa abordagem significa que o framework ajuda testers a concentrar seus esforços onde eles realmente importam.

Fases: segurança ao longo do SDLC

O que diferencia o WSTG de muitos frameworks de pentest é que ele não trata segurança como um evento isolado. Em vez disso, alinha os testes a cinco fases do Software Development Life Cycle, ou SDLC, incorporando segurança desde o planejamento inicial até a manutenção após o lançamento.

Vamos ver como isso funciona para a nossa loja online, a ShopSecure Inc., que está criando um novo portal de clientes.

Fase 1: antes do início do desenvolvimento. Os requisitos de segurança e as obrigações regulatórias são definidos antecipadamente. Para a ShopSecure, isso significa estabelecer que o portal deve estar em conformidade com o PCI DSS, já que processa pagamentos, e definir critérios mensuráveis, como o prazo máximo aceitável para corrigir vulnerabilidades.

Fase 2: durante a definição e o design. A arquitetura da aplicação é revisada em busca de falhas de segurança antes que qualquer código seja escrito. A equipe da ShopSecure cria modelos de ameaça para o fluxo de pagamento, identificando que a API de checkout será um alvo de alto valor e projetando controles de rate limiting e validação de entrada desde o início.

Fase 3: durante o desenvolvimento. O código é avaliado por meio de walkthroughs e revisões. Os desenvolvedores da ShopSecure revisam o módulo de autenticação com base nos casos de teste do WSTG para tratamento de credenciais, identificados como WSTG-ATHN, e encontram uma falha em que tokens de redefinição de senha não expiram.

Fase 4: durante a implantação. Os controles de segurança são verificados no ambiente de produção. A equipe da ShopSecure executa um pentest contra a aplicação em ambiente de staging, verificando se credenciais padrão foram alteradas, se o TLS está configurado corretamente e se não há endpoints de debug expostos.

Fase 5: durante a manutenção e as operações. A segurança é mantida após o lançamento por meio de verificações periódicas de saúde, especialmente depois de atualizações. Quando a ShopSecure lança uma nova funcionalidade de recomendação de produtos três meses depois, os casos de teste relevantes do WSTG são executados novamente para garantir que a atualização não tenha introduzido novas vulnerabilidades.

Observações finais

A maior força do WSTG é sua cobertura prática e exaustiva. Com mais de 90 casos de teste, cada um contendo procedimentos específicos e resultados esperados, ele oferece aos testers um roteiro concreto em vez de princípios abstratos.

Ele também se beneficia de atualizações contínuas feitas por uma comunidade global de profissionais de segurança, mantendo-se atualizado com classes emergentes de vulnerabilidades e arquiteturas modernas, como SPAs e microsserviços.

Por outro lado, uma implementação completa de todos os casos de teste pode ser impraticável para equipes com recursos limitados. Alguns testes exigem conhecimento especializado em áreas como análise criptográfica ou testes de lógica de negócio.

Também existe o risco de cair em uma mentalidade de checklist, em que testers executam mecanicamente os casos de teste sem parar para avaliar a postura geral de risco da aplicação. Os melhores profissionais usam o WSTG como base, mas aplicam pensamento crítico além da checklist.

Responda às perguntas abaixo:

O WSTG organiza seus casos de teste usando um formato específico de identificador. Qual identificador você procuraria para encontrar casos de teste relacionados à validação de entrada?

Resposta: WSTG-INPV

Uma equipe de desenvolvimento acabou de finalizar o código de uma nova funcionalidade e quer verificá-la com base no WSTG antes da implantação. Em qual número de fase alinhada ao SDLC ela está?

Resposta: 3

NIST SP 800–115

Visão geral

Considere este cenário: você trabalha como analista de segurança para uma agência governamental ou uma grande empresa que possui contratos com o governo federal. Sua organização precisa de uma avaliação de segurança, mas os resultados devem satisfazer auditores, estar em conformidade com diretrizes federais e ser defensáveis em caso de questionamentos de fiscalização. Um relatório de pentest cheio de comentários informais e classificações subjetivas de risco não será suficiente. Você precisa de uma metodologia reconhecida e confiável para reguladores federais.

Esse é o espaço ocupado pela NIST Special Publication 800–115, intitulada Technical Guide to Information Security Testing and Assessment. Publicado pelo National Institute of Standards and Technology — NIST, esse documento fornece um framework fundamental para avaliar sistematicamente a postura de segurança de sistemas de informação. Embora tenha origem no contexto federal dos Estados Unidos, seus princípios são amplamente aplicáveis e bastante adotados no setor privado, especialmente por organizações que valorizam processos estruturados e repetíveis.

A NIST SP 800–115 não é um framework de pentest em sentido estrito. Ela é mais ampla: cobre todo o espectro de técnicas de teste e avaliação de segurança, desde revisão de documentos e análise de logs até varredura de vulnerabilidades e testes de invasão completos. Ela trata o pentest como uma técnica entre várias, todas com o objetivo de validar se os controles de segurança funcionam conforme esperado.

Três objetivos centrais orientam o framework. Primeiro, identificar vulnerabilidades em sistemas, redes e aplicações. Segundo, validar controles de segurança, testando se eles funcionam como esperado sob condições adversariais. Terceiro, avaliar a explorabilidade, simulando cenários de ataque do mundo real para determinar se um agente de ameaça consegue, de fato, explorar as fraquezas identificadas.

Fases: um passo a passo

A NIST SP 800–115 estrutura os testes em três fases. Vamos percorrê-las com um cenário: sua equipe foi contratada para avaliar a segurança da GovNet, a rede interna de uma agência federal de médio porte, composta por 500 hosts, 3 data centers e um portal público de serviços ao cidadão.

Fase 1: Planejamento. Antes de qualquer teste começar, os objetivos, o escopo e as regras de engajamento são formalmente definidos e documentados. Para a GovNet, isso significa especificar quais segmentos de rede estão dentro do escopo, como o portal do cidadão e seu backend de suporte, e quais estão excluídos, como o enclave classificado.

Também significa estabelecer protocolos de comunicação: quem deve ser notificado se uma vulnerabilidade crítica for encontrada durante o teste, em quais horários os testes são permitidos e o que constitui uma condição de parada emergencial. A fase de planejamento produz um plano formal de testes aprovado por todos os stakeholders.

Fase 2: Execução. É aqui que os testes ativos acontecem. A NIST SP 800–115 agrupa as atividades de execução em quatro categorias de técnicas:

Técnicas de revisão: examinar documentação, políticas, configurações de sistemas e conjuntos de regras. Na GovNet, isso inclui revisar regras de firewall e listas de controle de acesso em busca de configurações incorretas.

Identificação e análise de alvos: descobrir e identificar hosts ativos, portas abertas e serviços em execução. Na GovNet, você faz uma varredura da infraestrutura do portal do cidadão e identifica 12 serviços expostos à internet.

Validação de vulnerabilidades em alvos: confirmar que as fraquezas identificadas são reais e exploráveis, e não falsos positivos. Na GovNet, uma varredura sinaliza uma possível SQL injection na função de busca do portal; você a valida manualmente criando uma consulta de teste que retorna informações sobre a versão do banco de dados.

Teste de invasão: simular ataques adversariais para testar a profundidade da exploração possível. Na GovNet, você encadeia a SQL injection confirmada com uma escalação de privilégios no servidor de banco de dados para demonstrar que um atacante externo poderia acessar registros internos de cidadãos.

Perceba como a NIST SP 800–115 trata essas atividades como uma progressão do passivo para o ativo, e do baixo impacto para o alto impacto. Nem todo trabalho precisa chegar à etapa de pentest; às vezes, uma revisão e uma validação de vulnerabilidades são suficientes para os objetivos da avaliação.

Fase 3: Pós-teste. O foco passa a ser analisar resultados, priorizar riscos e entregar estratégias de correção acionáveis. Para a GovNet, isso significa categorizar os achados por severidade, por exemplo: a cadeia de SQL injection é crítica, enquanto a ausência de um cabeçalho de segurança HTTP é baixa.

Também envolve mapear cada achado ao controle específico que ele contorna e fornecer etapas concretas de remediação. A NIST SP 800–115 enfatiza que os achados devem ser acionáveis: dizer ao cliente "você tem uma SQL injection" não é suficiente. O padrão é explicar qual parâmetro está vulnerável, quais dados estão em risco e como corrigir o problema.

Observações finais

Os pontos fortes da NIST SP 800–115 estão em sua flexibilidade e credibilidade institucional. Ela se adapta a diversos ambientes, desde data centers tradicionais até infraestrutura em nuvem e implantações de IoT, porque define categorias de técnicas em vez de prescrever ferramentas específicas.

Sua associação com o NIST dá reconhecimento imediato em ambientes governamentais, de defesa e setores regulados. Ela também promove padronização, facilitando que organizações com várias equipes de teste mantenham uma qualidade consistente.

Por outro lado, ela não impõe frequências de auditoria nem penalidades. Diferente do PCI DSS, que exige testes de invasão anuais, a NIST SP 800–115 é uma orientação, não uma regulamentação. Isso pode limitar sua adoção como motivador independente em setores altamente regulados.

Ela também exige profissionais qualificados; o framework presume que os testers consigam executar uma ampla variedade de técnicas, desde revisão documental até exploração, o que demanda um conjunto de habilidades bastante abrangente.

Responda à pergunta abaixo:

Durante a fase de Execução, seu scanner de vulnerabilidades sinaliza 15 possíveis problemas em uma aplicação web. Antes de tentar a exploração, qual categoria de técnica da NIST SP 800–115 você deve aplicar a esses achados?

Resposta: Target vulnerability validation

PTES

Visão geral

Você já conheceu frameworks que enfatizam métricas científicas, como o OSSTMM; cobertura de aplicações web, como o OWASP WSTG; e técnicas de avaliação alinhadas ao contexto governamental, como a NIST SP 800–115. Mas há uma pergunta importante a considerar: se você fosse contratado amanhã para um trabalho padrão de pentest contra uma rede corporativa, qual framework refletiria mais de perto o fluxo real que você seguiria desde a primeira conversa com o cliente até a entrega do relatório final?

Para muitos pentesters em atuação, a resposta é o Penetration Testing Execution Standard, ou PTES. Disponível em pentest-standard.org, o PTES foi desenvolvido por um grupo de profissionais experientes de segurança com um objetivo específico: definir como é um teste de invasão real, de ponta a ponta. Enquanto outros frameworks focam no que testar ou em como medir, o PTES foca em como o trabalho flui do início ao fim.

O PTES é organizado em sete fases que se conectam diretamente ao ciclo de vida de um trabalho de pentest. Essa abordagem o torna especialmente prático para testers iniciantes, porque responde a uma pergunta que muitos frameworks deixam implícita: "Tenho um contrato assinado; agora o que faço no primeiro dia, no segundo dia e nos dias seguintes?"

Fases: um passo a passo

Vamos percorrer as sete fases usando um cenário: uma empresa de saúde, a MedGuard Health, contratou sua equipe para realizar um pentest completo da rede corporativa e do portal de registros de pacientes.

Fase 1: Interações pré-engajamento. Essa fase inclui tudo o que acontece antes do início dos testes. Você define o escopo com o diretor de TI da MedGuard: a LAN corporativa, 10.10.0.0/16, o portal de pacientes em records.medguard-health.thm e as redes wireless do prédio da sede.

Você documenta as regras de engajamento, incluindo janelas de teste, apenas em noites de dias úteis para evitar interrupções nas operações clínicas, contatos de emergência e uma carta de autorização, conhecida como "get out of jail free letter", autorizando o teste. O PTES é especialmente detalhado aqui porque escopos mal definidos são uma das principais fontes de disputas legais e profissionais em testes de invasão.

Fase 2: Coleta de inteligência. Você coleta informações sobre a MedGuard usando técnicas passivas e ativas. O reconhecimento passivo inclui coletar endereços de e-mail de funcionários no LinkedIn, descobrir subdomínios por meio de logs de transparência de certificados e revisar vagas de emprego que revelam stacks tecnológicas, como "procuramos DBA com experiência em Oracle 19c".

O reconhecimento ativo envolve enumeração de DNS e varredura de rede dentro do escopo acordado. O PTES diferencia esses níveis porque a profundidade da coleta de inteligência influencia diretamente a qualidade das fases seguintes.

Fase 3: Modelagem de ameaças. Com base nas informações coletadas, você identifica os alvos mais valiosos e os caminhos de ataque mais prováveis. Na MedGuard, o banco de dados de registros de pacientes é o ativo de maior valor. Seu modelo de ameaças identifica dois caminhos principais de ataque: comprometer diretamente o portal de pacientes por meio de uma vulnerabilidade web ou pivotar pela LAN corporativa após comprometer uma estação de trabalho de funcionário.

Essa fase garante que o esforço de teste seja orientado por uma lógica adversarial, e não por varreduras aleatórias.

Fase 4: Análise de vulnerabilidades. Você identifica sistematicamente fraquezas que poderiam permitir os caminhos de ataque definidos no modelo de ameaças. Na MedGuard, a varredura de vulnerabilidades revela que o portal de pacientes está executando uma versão desatualizada do Apache Tomcat, que contém uma vulnerabilidade conhecida de desserialização. Na rede interna, várias estações de trabalho estão sem patches críticos.

O PTES enfatiza que a análise de vulnerabilidades inclui tanto varreduras automatizadas quanto verificação manual para eliminar falsos positivos.

Fase 5: Exploração. Você tenta explorar as vulnerabilidades confirmadas. Na MedGuard, você explora a falha de desserialização do Tomcat para obter uma shell no servidor do portal. No ambiente interno, usa um pretexto de phishing, autorizado no escopo, para entregar um payload a uma estação de trabalho de funcionário.

O PTES reforça que a exploração deve ter propósito: o objetivo é demonstrar impacto de negócio, não simplesmente "comprometer máquinas" por diversão.

Fase 6: Pós-exploração. Depois de obter acesso, você determina o impacto no mundo real. A partir do servidor do portal comprometido, você pivota para o banco de dados backend e confirma acesso de leitura aos registros de pacientes. A partir da estação de trabalho do funcionário, você extrai credenciais de domínio em cache e demonstra movimento lateral até um servidor de arquivos contendo dados financeiros.

O PTES trata a pós-exploração como a fase em que achados técnicos são traduzidos em risco de negócio: "acessamos 50.000 registros de pacientes" tem muito mais peso do que "obtivemos uma shell".

Fase 7: Relatório. Você entrega os achados em um relatório estruturado, considerando dois públicos. O resumo executivo comunica o risco de negócio em linguagem clara para a liderança da MedGuard: dados de pacientes estavam acessíveis, a exposição regulatória sob a HIPAA é significativa e a remediação é urgente.

O relatório técnico fornece os detalhes necessários para que a equipe de TI da MedGuard consiga reproduzir e corrigir cada achado: etapas exatas de exploração, hosts afetados, evidências em screenshots e orientações de remediação priorizadas.

Observações finais

A maior força do PTES está em sua estrutura prática e de ponta a ponta. Ele funciona como um playbook de como os trabalhos realmente acontecem, o que o torna um excelente framework de aprendizado para testers iniciantes que estão desenvolvendo seus instintos de fluxo de trabalho.

Seu tratamento detalhado das interações pré-engajamento é especialmente valioso. Muitos frameworks tratam superficialmente escopo e autorização legal, justamente áreas em que testers inexperientes cometem erros caros.

Por outro lado, o PTES não é atualizado formalmente há vários anos, e suas seções de orientação técnica fazem referência a ferramentas e técnicas desatualizadas. A metodologia e a estrutura de fases continuam sólidas, mas testers devem complementar as orientações específicas de ferramentas com documentações atuais.

Além disso, o PTES não possui as métricas quantitativas do OSSTMM, então os resultados dependem mais do julgamento individual do tester.

Responda à pergunta abaixo:

Qual número de fase do PTES aborda especificamente a definição do escopo, das regras de engajamento e da autorização legal para um teste de invasão?

Resposta: 1

ISSAF

Visão geral

Você já estudou um livro antigo e percebeu que, apesar da idade, a lógica central ainda continua válida? Em segurança cibernética, ferramentas e exploits têm uma vida útil curta, mas metodologias bem projetadas podem sobreviver por muito mais tempo do que as tecnologias para as quais foram originalmente criadas. O Information Systems Security Assessment Framework, ou ISSAF, é um bom exemplo disso.

Desenvolvido pelo Open Information Systems Security Group — OISSG, o ISSAF é um framework open-source de pentest criado para avaliar a segurança de redes, sistemas e aplicações. A versão mais recente, ISSAF v0.2.1, foi publicada por volta de 2006, e o framework não é mais mantido ativamente. Não existe mais uma URL oficial para baixá-lo; no entanto, o rascunho ainda pode ser encontrado em fontes arquivadas online. Esse é um contexto importante: a metodologia e a estrutura de fases do ISSAF continuam instrutivas, mas suas orientações específicas sobre ferramentas estão desatualizadas e não devem ser usadas como referência para trabalhos atuais.

Então, por que estudar um framework que não é mais mantido? Porque o modelo de avaliação em nove etapas do ISSAF é uma das representações mais claras de como um atacante progride dentro de um ambiente-alvo. Ele reflete a lógica de uma ameaça persistente avançada, avançando sistematicamente desde o reconhecimento inicial até o acesso persistente e a remoção de evidências. Se essa progressão parece familiar, deveria mesmo parecer: é o pensamento baseado em kill chain que você encontrou em detalhes anteriormente neste módulo, na sala sobre Cyber Kill Chain.

O ISSAF cobre uma ampla variedade de domínios de segurança, incluindo infraestrutura de rede, sistemas host, aplicações web, bancos de dados e engenharia social. Sua abordagem baseada em risco prioriza vulnerabilidades exploráveis e de alto impacto em vez de achados de baixa severidade.

Fases: um passo a passo

O ISSAF divide uma avaliação em três fases. Vamos percorrê-las com um cenário: sua equipe está avaliando a segurança da TechBridge Solutions, uma empresa de desenvolvimento de software com 200 funcionários, um servidor Git interno e um portal de gerenciamento de projetos voltado para clientes.

Fase 1: Planejamento e preparação

Essa fase define os limites do trabalho. Você se reúne com o CTO da TechBridge para definir o escopo, incluindo a rede corporativa, o servidor Git e o portal de gerenciamento de projetos. Também estabelece protocolos de escalação e contatos de emergência, identifica restrições, como o fato de o servidor Git de produção não poder ser interrompido durante o horário comercial, e concorda sobre o conjunto de ferramentas apropriado para a avaliação.

Fase 2: Avaliação

Esta é a parte central do ISSAF, onde está seu modelo de nove etapas. Cada etapa se baseia na anterior, simulando como um adversário real avançaria pelo ambiente.

Coleta de informações: coletar dados publicamente disponíveis sobre a TechBridge. Registros DNS, dados WHOIS, perfis de funcionários no LinkedIn e referências a tecnologias em vagas de emprego, como "experiência com Jenkins e GitLab CI obrigatória", ajudam a formar seu entendimento sobre o alvo.

Mapeamento de rede: mapear a topologia da rede ativa. Você descobre que o intervalo de IPs externo da TechBridge hospeda o portal de projetos, um gateway VPN e um servidor de e-mail. A varredura interna, uma vez dentro do escopo, revela o servidor Git, um servidor Jenkins de build e várias estações de trabalho de desenvolvedores.

Identificação de vulnerabilidades: examinar os ativos mapeados em busca de fraquezas. O portal de projetos executa um CMS desatualizado com uma vulnerabilidade conhecida de bypass de autenticação. O servidor Jenkins tem seu console administrativo exposto sem autenticação.

Penetração: tentar a exploração inicial. Você explora o console Jenkins sem autenticação para executar comandos do sistema no servidor de build.

Obtenção de acesso e escalação de privilégios: escalar do acesso inicial para privilégios mais elevados. A partir do servidor Jenkins, você recupera credenciais armazenadas da conta de serviço que faz deploy de código em produção, a qual possui direitos administrativos no servidor Git.

Enumeração adicional: com acesso elevado, enumerar o que agora está acessível. A partir do servidor Git, você descobre repositórios contendo chaves de API, strings de conexão com banco de dados e código-fonte de projetos de clientes.

Comprometimento de usuários ou sites remotos — movimento lateral: mover-se lateralmente para outros sistemas. Usando as credenciais coletadas, você acessa várias estações de trabalho de desenvolvedores e o servidor de e-mail interno.

Manutenção de acesso: estabelecer acesso persistente para demonstrar que um atacante real poderia manter sua presença. Você documenta, sem realmente implantar, como uma backdoor poderia ser inserida no pipeline de CI/CD, persistindo após reinicializações de sistemas e novos deployments.

Cobertura de rastros: demonstrar como um atacante apagaria evidências. Você documenta quais logs registraram sua atividade e identifica lacunas no logging da TechBridge que permitiriam a um adversário real operar sem ser detectado.

Observe a progressão: cada etapa aprofunda a posição do atacante no ambiente. As etapas 1 a 3 são reconhecimento e análise; as etapas 4 a 7 envolvem comprometimento ativo; e as etapas 8 e 9 tratam de persistência e furtividade.

Fase 3: Relatório e limpeza

Você compila os achados em um relatório estruturado, priorizado por impacto de negócio. O console Jenkins sem autenticação é classificado como crítico, pois forneceu o ponto inicial de entrada que levou ao acesso ao código-fonte.

A limpeza envolve remover quaisquer artefatos de teste, revogar contas temporárias criadas durante a avaliação e confirmar com a equipe da TechBridge que nenhum resíduo dos testes permaneceu no ambiente.

Observações finais

O modelo de nove etapas do ISSAF é sua contribuição duradoura. A progressão desde a coleta de informações até o movimento lateral e a cobertura de rastros oferece um modelo mental claro de como ataques reais acontecem, tornando-o uma excelente ferramenta educacional, mesmo que o framework em si não seja mais mantido.

No entanto, esse status de não manutenção é uma limitação real. As orientações específicas de ferramentas fazem referência a versões de software com mais de uma década de defasagem, e não há uma comunidade atualizando a documentação. O ISSAF deve ser estudado por sua metodologia e lógica adversarial, não por seus procedimentos técnicos. Para orientações atuais sobre ferramentas, complemente o estudo com recursos como PTES, OWASP WSTG ou a documentação relevante das próprias ferramentas.

Responda à pergunta abaixo:

O modelo de avaliação em nove etapas do ISSAF começa com coleta de informações. Qual é a nona e última etapa?

Resposta: Covering tracks

MITRE ATT&CK

Visão geral

Nas tarefas anteriores, exploramos frameworks que explicam como conduzir um teste de invasão: como definir o escopo, avançar pelas fases e relatar os achados. Mas considere a seguinte situação: você acabou de concluir um trabalho usando o PTES, e o relatório documenta que você obteve acesso inicial por meio de um e-mail de phishing, escalou privilégios explorando um serviço mal configurado, moveu-se lateralmente usando credenciais roubadas e exfiltrou dados por um canal criptografado. O cliente lê o relatório e faz uma pergunta aparentemente simples: "Como nossa exposição se compara ao que agentes de ameaça reais estão fazendo na prática?"

Essa pergunta é difícil de responder usando apenas um framework de pentest. Frameworks como PTES e OSSTMM estruturam o processo de teste, mas não catalogam sistematicamente as táticas e técnicas específicas usadas por adversários reais. É essa lacuna que o MITRE ATT&CK preenche.

ATT&CK significa Adversarial Tactics, Techniques, and Common Knowledge. Desenvolvido e mantido pela MITRE Corporation, ele não é um framework tradicional de pentest. Trata-se de uma base de conhecimento sobre o comportamento de adversários, construída a partir de observações reais de como agentes de ameaça operam. Ele cataloga o que os atacantes fazem, organizado em uma estrutura que profissionais de segurança podem usar para inteligência de ameaças, engenharia de detecção, red team e, no contexto desta sala, para enriquecer achados de pentest.

A matriz: táticas, técnicas e subtécnicas

O ATT&CK é organizado como uma matriz. Pense nela como uma grande tabela. As colunas representam táticas, que são os objetivos de alto nível do adversário, ou seja, o "porquê" por trás de uma ação. A matriz Enterprise atual inclui 14 táticas, progredindo desde acesso inicial até execução, persistência, escalação de privilégios, evasão de defesa, acesso a credenciais, descoberta, movimento lateral, coleta, comando e controle, exfiltração e impacto.

Dentro de cada coluna de tática, as linhas listam técnicas, que representam o "como", ou seja, os métodos específicos que um adversário usa para alcançar aquele objetivo tático. Por exemplo, na tática de Initial Access, você encontrará técnicas como Phishing — T1566, Exploit Public-Facing Application — T1190 e Valid Accounts — T1078.

Muitas técnicas são divididas ainda em subtécnicas. Phishing, por exemplo, possui subtécnicas para anexos de spearphishing, T1566.001; links de spearphishing, T1566.002; e spearphishing via serviço, T1566.003.

Cada entrada de técnica na base de conhecimento ATT&CK inclui uma descrição, exemplos reais de grupos de ameaça que a utilizaram, recomendações de detecção e mitigações. É isso que torna o ATT&CK mais do que uma taxonomia: ele é uma referência viva, conectada ao comportamento observado de adversários reais.

ATT&CK como complemento, não substituto

Aqui está a distinção principal para esta sala: o ATT&CK não ensina como executar um pentest. Ele não define fases, procedimentos de escopo ou formatos de relatório. Em vez disso, fornece uma linguagem comum para descrever o que foi encontrado durante um teste conduzido com qualquer framework.

Considere a analogia entre um dicionário médico e um procedimento diagnóstico. O PTES é como o procedimento diagnóstico: ele diz ao médico quais etapas seguir durante um exame. O ATT&CK é como o dicionário médico: ele fornece uma terminologia padronizada para nomear e categorizar o que o médico observa. Você precisa dos dois, mas eles têm finalidades diferentes.

Passo a passo: mapeando achados para o ATT&CK

Vamos ver como isso funciona na prática. Lembre-se do trabalho na MedGuard Health da Tarefa 5, sobre PTES. Veja como os principais achados daquele trabalho se mapeiam para IDs de técnicas do ATT&CK:

Ao anotar um relatório PTES com IDs de técnicas do ATT&CK, o tester fornece à equipe de segurança da MedGuard insights acionáveis além da simples correção de vulnerabilidades individuais. O cliente agora pode consultar cada técnica na base de conhecimento ATT&CK, revisar as orientações de detecção e criar ou validar regras de detecção para esses comportamentos específicos. A conversa deixa de ser apenas "corrija este bug" e passa a ser "conseguimos detectar esta classe de comportamento adversário?"

Observações finais

A força do ATT&CK está em seu papel como tradutor universal do comportamento adversário. Ele permite que pentesters, analistas de inteligência de ameaças, engenheiros de detecção e equipes de resposta a incidentes falem a mesma língua.

Para pentesters especificamente, mapear achados para o ATT&CK eleva um relatório de uma lista de vulnerabilidades para uma narrativa fundamentada em comportamentos de ameaça do mundo real.

A base de conhecimento é extensa, e dominá-la leva tempo. Apenas a matriz Enterprise contém mais de 200 técnicas. Para uma exploração mais profunda e prática do ATT&CK, incluindo como navegar pela matriz, pesquisar grupos de ameaça específicos e aplicá-lo à engenharia de detecção, salas dedicadas mais adiante na plataforma TryHackMe cobrem o ATT&CK com muito mais detalhes.

Por enquanto, a principal conclusão é esta: o ATT&CK complementa o framework de pentest escolhido ao fornecer um vocabulário padronizado para descrever aquilo que você encontra.

Responda às perguntas abaixo:

Na matriz ATT&CK, o que as colunas representam?

Resposta: tactics

Na matriz ATT&CK, o que as linhas dentro de cada coluna representam?

Resposta: Techniques

Você comprometeu um servidor web explorando uma vulnerabilidade sem patch em uma aplicação exposta publicamente. Qual ID de técnica do ATT&CK você usaria para classificar esse achado?

Resposta: T1190

Outros frameworks relevantes

Visão geral

Os frameworks que abordamos até agora — OSSTMM, OWASP WSTG, NIST SP 800–115, PTES, ISSAF e MITRE ATT&CK — representam as principais metodologias e bases de conhecimento que um pentester júnior provavelmente encontrará. Mas o cenário não termina aí. Dependendo do setor, da plataforma ou do ambiente regulatório em que o cliente atua, talvez seja necessário conhecer frameworks mais especializados, voltados a domínios específicos.

Esta tarefa apresenta cinco frameworks adicionais. O objetivo não é dominar profundamente cada um deles, mas desenvolver uma visão geral do cenário: saber que eles existem, entender seus nichos e reconhecer quando um trabalho com cliente pode exigir um deles.

Os frameworks

O WASC Threat Classification foi desenvolvido pelo Web Application Security Consortium — WASC como uma taxonomia para categorizar vulnerabilidades e tipos de ataques em aplicações web. Ele organiza ameaças em categorias como autenticação insuficiente, vazamento de informações e abuso de funcionalidade. Embora tenha sido influente em meados dos anos 2000 e tenha ajudado a padronizar a forma como a indústria discutia ameaças web, desde então foi amplamente substituído pelo OWASP Top Ten e pelo WSTG como principais referências em segurança web. Ainda assim, você pode encontrá-lo mencionado em documentações antigas ou frameworks de conformidade.

A CSA Cloud Controls Matrix — CCM é publicada pela Cloud Security Alliance — CSA e fornece um framework de controles de segurança cibernética projetado especificamente para ambientes de computação em nuvem. Ela mapeia controles em 17 domínios, incluindo segurança de dados, gerenciamento de identidade e acesso, e segurança de infraestrutura, alinhando-os a grandes padrões como ISO 27001, NIST e PCI DSS. A CCM não é uma metodologia de pentest; é uma ferramenta de governança e conformidade que ajuda organizações a avaliar se seus provedores e configurações em nuvem atendem aos requisitos de segurança. Você a encontraria quando um cliente precisa de uma avaliação de postura de segurança em nuvem, e não de um pentest tradicional.

O OWASP Mobile Application Security Testing Guide — MASTG é o equivalente mobile do WSTG, abordado na Tarefa 3. Mantido pela OWASP, o MASTG fornece casos de teste detalhados para segurança de aplicações Android e iOS, cobrindo áreas como armazenamento de dados, implementação criptográfica, comunicação de rede, interação com a plataforma e qualidade de código. Se o trabalho envolver o teste de um aplicativo de mobile banking, um aplicativo de portal de pacientes na área da saúde ou qualquer aplicação móvel voltada ao cliente, o MASTG é a referência principal. Ele é usado em conjunto com o OWASP Mobile Application Security Verification Standard — MASVS, que define os requisitos de segurança contra os quais o MASTG realiza os testes.

As PCI DSS Penetration Testing Guidelines são definidas dentro do Payment Card Industry Data Security Standard, especificamente no Requisito 11.4 da PCI DSS v4.0. Diferentemente dos frameworks de uso geral abordados anteriormente, essas diretrizes são exigências regulatórias: qualquer organização que processe, armazene ou transmita dados de titulares de cartão deve realizar testes de invasão que atendam aos critérios do PCI DSS. As diretrizes especificam que os testes devem cobrir tanto o perímetro externo quanto a rede interna, devem ser realizados pelo menos anualmente e após mudanças significativas na infraestrutura, além de validar os controles de segmentação de rede. Quando seu cliente é um varejista, processador de pagamentos ou qualquer entidade do ecossistema de cartões de pagamento, os requisitos do PCI DSS moldam tanto o escopo quanto o formato do relatório do trabalho.

O CBEST Framework foi desenvolvido pelo Bank of England em colaboração com o setor financeiro do Reino Unido. Trata-se de um framework de pentest orientado por inteligência de ameaças, projetado especificamente para instituições financeiras do Reino Unido, incluindo bancos, seguradoras e provedores de infraestrutura do mercado financeiro. Trabalhos baseados em CBEST começam com uma fase personalizada de inteligência de ameaças, que identifica os agentes de ameaça e cenários de ataque mais relevantes para aquela instituição específica. Em seguida, o teste de invasão simula esses cenários realistas de ameaça. O CBEST se destaca pela forte integração entre inteligência de ameaças e testes práticos, além de seu respaldo regulatório no setor financeiro do Reino Unido.

Tabela comparativa

Observações finais

A principal conclusão desta visão geral é que a escolha do framework depende do contexto. O setor do cliente, suas obrigações regulatórias, a plataforma tecnológica utilizada e a jurisdição geográfica influenciam qual framework se aplica.

Um pentester que trabalha com um banco do Reino Unido precisa entender o CBEST. Um tester avaliando um aplicativo mobile de saúde recorrerá ao OWASP MASTG. Um tester trabalhando com um processador de pagamentos não pode ignorar os requisitos do PCI DSS.

Conhecer esse cenário significa ser capaz de reconhecer qual framework determinado trabalho exige, mesmo que você precise estudá-lo em detalhes naquele momento.

Responda às perguntas abaixo:

Seu cliente é um varejista online europeu que processa pagamentos com cartão de crédito por meio do site. Qual framework desta tarefa governaria mais diretamente os requisitos de teste de invasão para este trabalho?

Resposta: PCI DSS Penetration Testing Guidelines

Um cliente pede que você avalie a segurança de sua aplicação bancária para iOS, incluindo como ela armazena credenciais localmente e se comunica com APIs backend. Qual framework desta tarefa é a referência de teste mais apropriada?

Resposta: OWASP Mobile Application Security Testing Guide

Sua equipe está avaliando a infraestrutura AWS de um cliente para determinar se suas configurações em nuvem atendem aos padrões de segurança da indústria. Eles não estão solicitando um teste de invasão, mas sim uma avaliação de controles. Qual framework é mais relevante?

Resposta: CSA Cloud Control Matrix

Escolhendo o framework certo

Visão geral

Agora você tem um conhecimento prático sobre vários frameworks de pentest, cada um com sua própria filosofia, estrutura e pontos fortes. Mas saber o que cada framework é não significa automaticamente saber qual deles usar. Na prática, a escolha do framework é uma das primeiras decisões que um pentester toma depois de receber o briefing de um trabalho, e essa decisão é influenciada por múltiplos fatores que, muitas vezes, apontam para direções diferentes.

Pense na analogia de uma caixa de ferramentas de um mecânico. Um mecânico não usa todas as ferramentas em todos os trabalhos; ele escolhe as ferramentas com base no veículo, no problema e nas expectativas do cliente. Um pentester atua da mesma forma. O framework "certo" depende do setor do cliente, do tipo de sistema que será testado, do contexto regulatório e dos objetivos do trabalho.

Esta tarefa apresenta os principais critérios de seleção e, em seguida, traz cenários realistas para você praticar essa decisão.

Critérios de seleção

Quatro fatores costumam orientar a escolha de frameworks em trabalhos reais.

Escopo do trabalho e tipo de alvo é o filtro mais imediato. Uma avaliação de aplicação web se alinha ao OWASP WSTG. Um trabalho envolvendo aplicação mobile pede o OWASP MASTG. Um pentest completo de rede se alinha naturalmente ao PTES ou ao OSSTMM. Se o escopo abranger vários canais, incluindo fatores físicos e humanos, o modelo de cinco canais do OSSTMM se torna especialmente relevante.

Requisitos regulatórios e de conformidade podem sobrepor completamente a preferência pessoal. Se o cliente processa dados de cartão de pagamento, as diretrizes de pentest do PCI DSS não são opcionais. Se o cliente é uma instituição financeira do Reino Unido sujeita à supervisão do Bank of England, o CBEST pode ser obrigatório. A NIST SP 800–115 tem peso em ambientes do governo dos Estados Unidos e de fornecedores federais. Quando a regulamentação determina o caminho, o tester se adapta.

Necessidade de resultados quantificáveis e repetíveis importa quando vários avaliadores estão envolvidos ou quando os resultados precisam ser comparados ao longo do tempo. As métricas RAV do OSSTMM foram criadas especificamente para isso. Se um cliente diz: "Queremos medir se nossa postura de segurança melhorou desde o teste do ano passado", o OSSTMM fornece a estrutura de medição para responder a essa pergunta de forma objetiva.

Especialização da equipe e recursos disponíveis são restrições práticas fáceis de ignorar. Uma implementação completa do OSSTMM exige familiaridade profunda com seu sistema de métricas. O CBEST exige capacidades de inteligência de ameaças. Para uma equipe menor conduzindo uma avaliação padrão de rede corporativa, o PTES oferece um fluxo de trabalho prático e bem estruturado, sem a sobrecarga de frameworks mais especializados.

Prática com cenários

Vamos aplicar esses critérios a situações realistas. Para cada cenário, considere qual framework, ou combinação de frameworks, você recomendaria e por quê.

Cenário 1

Um hospital regional contrata sua equipe para testar o portal web voltado a pacientes e a rede interna à qual ele se conecta. O hospital precisa estar em conformidade com a HIPAA, mas não está sujeito ao PCI DSS, pois terceiriza o processamento de pagamentos. Eles querem uma avaliação estruturada, de ponta a ponta, com um resumo executivo claro para o conselho diretor.

O PTES é a opção mais adequada aqui. Ele fornece a estrutura de trabalho de ponta a ponta que o hospital precisa, sua fase de relatório produz explicitamente entregáveis executivos e técnicos, e ele cobre tanto testes de aplicação web quanto de rede dentro de uma única metodologia. O OWASP WSTG pode complementar especificamente os testes do portal web, e o mapeamento dos achados para IDs de técnicas do MITRE ATT&CK fortaleceria o relatório ao conectá-lo a comportamentos reais de ameaça.

Cenário 2

Um banco multinacional com sede em Londres precisa de um teste de invasão que satisfaça suas obrigações regulatórias no Reino Unido. O trabalho deve começar com uma avaliação de inteligência de ameaças específica para a instituição.

O CBEST é a escolha clara. Ele foi projetado para instituições financeiras do Reino Unido, exige uma fase personalizada de inteligência de ameaças e é reconhecido pelo Bank of England. Nenhum framework de uso geral, sozinho, atenderia a esses requisitos.

Cenário 3

Uma startup SaaS quer que duas empresas de segurança diferentes testem independentemente sua plataforma ao longo dos próximos dois anos e comparem diretamente os resultados para acompanhar melhorias. A plataforma é totalmente baseada na web.

As métricas RAV do OSSTMM permitem as comparações diretas entre equipes e ao longo do tempo que o cliente está solicitando. O OWASP WSTG orientaria os casos de teste específicos para web, enquanto o OSSTMM forneceria a camada de medição quantitativa que torna a comparação ano a ano significativa.

Cenário 4

Uma fintech pede que você teste seus aplicativos de mobile banking para Android e iOS, ambos lidando com transações de cartão de crédito.

Esse trabalho exige dois frameworks atuando em conjunto. O OWASP MASTG fornece os casos de teste para segurança de aplicações mobile em ambas as plataformas. As diretrizes de pentest do PCI DSS também devem ser seguidas, pois os aplicativos lidam com dados de titulares de cartão. O tester precisa atender simultaneamente à metodologia de teste específica para mobile e à exigência regulatória.

Observações finais

Como esses cenários ilustram, a escolha de framework raramente é uma decisão única. Trabalhos reais geralmente envolvem um framework principal, que estrutura a metodologia geral, e frameworks complementares, que tratam de requisitos específicos regulatórios, de plataforma ou de relatório.

A capacidade de reconhecer quais frameworks se aplicam e como eles se complementam é uma habilidade que diferencia um pentester metódico de alguém que simplesmente executa ferramentas.

Responda às perguntas abaixo:

Uma agência federal dos Estados Unidos precisa de uma avaliação de segurança de sua rede interna. Os resultados devem estar alinhados às diretrizes federais, e a avaliação deve incluir tanto revisões documentais quanto testes de invasão ativos. Qual framework é a escolha primária mais natural?

Resposta: NIST SP 800–115

Seu cliente é uma empresa de e-commerce com uma loja web, um aplicativo mobile de compras e um sistema de processamento de pagamentos. Qual combinação de frameworks você recomendaria para cobrir os três componentes? — separados por vírgula

Resposta: WSTG,MASTG,PCI DSS

Conclusão

Nesta sala, exploramos o cenário dos frameworks de pentest, começando pela pergunta "por que frameworks são importantes?" e avançando até a habilidade prática de escolher o framework certo para um determinado trabalho.

Para continuar com o desafio prático, pressione o botão View Site abaixo.

Começamos com o OSSTMM e sua filosofia científica, orientada por métricas, na qual a segurança não é uma opinião subjetiva, mas uma propriedade mensurável expressa por meio dos Risk Assessment Values. Em seguida, examinamos o OWASP WSTG, o roteiro do tester de aplicações web, com mais de 90 casos de teste organizados ao longo do Software Development Life Cycle.

A NIST SP 800–115 nos mostrou como os testes de segurança se encaixam no mundo governamental e corporativo, estruturando técnicas de avaliação desde revisões documentais passivas até exploração ativa. O PTES nos aproximou mais da realidade cotidiana do pentest, mapeando sete fases desde a primeira conversa com o cliente até o relatório final.

O ISSAF, embora não seja mais mantido, nos apresentou um dos modelos mais claros de progressão adversarial por meio de sua avaliação em nove etapas. E o MITRE ATT&CK forneceu o vocabulário comum para descrever o que adversários realmente fazem, enriquecendo os achados de qualquer framework com IDs de técnicas baseados em inteligência de ameaças do mundo real.

Também vimos cinco frameworks adicionais, cada um atendendo a um nicho especializado, desde testes de aplicações mobile, como o OWASP MSTG, até exigências regulatórias na indústria de cartões de pagamento, como o PCI DSS, e no setor financeiro do Reino Unido, como o CBEST.

Por fim, praticamos a habilidade aplicada de seleção de frameworks, reconhecendo que trabalhos reais frequentemente exigem uma metodologia principal complementada por frameworks específicos de domínio ou por requisitos regulatórios.

Tabela comparativa geral

O que vem a seguir

Esta sala teve como foco os frameworks que estruturam como os testes de invasão são planejados, executados e reportados.

No módulo Pentesting Methodologies and Reporting, abordaremos Threat Modeling for Pentesters e Planning and Scoping. Essas salas irão formalizar ainda mais esse conhecimento, fornecendo a mentalidade adversarial que complementa a disciplina metodológica que você construiu aqui.

Responda às perguntas abaixo:

Percorra o site estático anexado. Qual é a flag?

Resposta: THM{pen-test-fr4m3work5}

Seu mentor deixou este dossiê sobre sua mesa antes de ir para o local de um cliente. Os quatro exercícios dentro dele foram inspirados em trabalhos reais. Resolva-os em ordem. Cada um testa uma decisão de julgamento que você precisará tomar em campo.

Canais do OSSTMM

Reconheça os cinco canais de segurança que, em conjunto, descrevem toda a superfície de ataque de uma organização.

Progressão do ISSAF

Organize a progressão do atacante em nove etapas, desde o reconhecimento até a persistência e a furtividade.

Mapeamento ATT&CK

Mapeie os achados do trabalho para as táticas do MITRE ATT&CK usando o vocabulário padronizado.

Seleção de framework

Selecione o conjunto certo de frameworks para um cenário de cliente com base no escopo, na regulamentação e nos entregáveis.

Nota do mentor

Métricas quantificáveis

O RAV do OSSTMM, Risk Assessment Values, fornece uma pontuação numérica para a postura de segurança. Ele não é uma nota de aprovado ou reprovado. É uma baseline contra a qual você mede mudanças.

Quando um cliente pergunta "estamos seguros?", o RAV permite responder: "Estamos em 73%, e aqui está o que influenciou esse resultado."

Passo a passo pela superfície de ataque

Cada marcador pertence a um dos cinco canais de segurança do OSSTMM. Identifique todos os cinco canais para concluir este exercício.

Segurança humana

Engenharia social, pretexting contra help desk, coerção de insiders. Uma ligação telefônica confiante para essa pessoa muitas vezes é mais barata do que um zero-day.

Arco adversarial

Coloque as nove etapas na ordem em que um atacante as executaria. Verifique sua sequência quando todos os espaços estiverem preenchidos.

Sequência verificada

As etapas 1 a 3 são de reconhecimento e análise. As etapas 4 a 7 representam o comprometimento ativo. As etapas 8 e 9 tratam de persistência e furtividade.

Você acabou de percorrer o arco que um adversário real seguiria.

Quadro de marcação de táticas

Mapeie cada achado do trabalho para a tática do ATT&CK que ele representa. Nem todas as colunas serão usadas.

Envie quando estiver pronto.

Roteador de trabalhos

Três briefings de clientes. Trabalhe cada um deles. O conjunto de frameworks precisa atender ao escopo, à regulamentação e às expectativas de entrega ao mesmo tempo.

Parabéns! 🎉

Você concluiu a sala Penetration Testing Frameworks.

Resposta: Não é ncessário resposta