Um mergulho na evolução da segurança ofensiva, desde os primórdios até os dias atuais. O artigo explora a mudança de paradigmas, a complexidade crescente das ameaças e a necessidade de especialização.
MundiX News·11 de maio de 2026·15 min de leitura·👁 9 views
Análise de Segurança 15 Anos Depois: Ato I
Olá a todos! Meu nome é Sergey e sou diretor do Centro de Pesquisa de Ciberameaças na Angara Security. Tenho trabalhado e liderado pentests e red teams durante toda a minha carreira consciente em segurança da informação (SI).
Quero compartilhar com vocês, nossos queridos e respeitados leitores, minhas reflexões sobre a substituição de conceitos nos serviços de análise de segurança. Muitas vezes vi (e ainda vejo com frequência) como um pentest é chamado de "varredura de vulnerabilidades", ou como o conceito de Red Team engloba um pentest comum, mesmo com elementos de "contra-medidas".
Sem entrar em detalhes sobre minha motivação, decidi fazer um ciclo de artigos onde, com base em minha experiência e na experiência de meus colegas, tentarei detalhar toda a parte ofensiva, com exemplos e explicações dos pontos realmente importantes que afetam a qualidade, a duração e o custo de tais trabalhos, com análise de casos reais da minha prática e outras coisas. Devo dizer de antemão que tentarei fazer isso em um formato leve e descontraído, para que a leitura desses artigos não se transforme em uma atividade entediante e os leitores não queiram, em vez de ler, ir "assistir a vídeos curtos" ou se envolver em coisas mais úteis. Não espere nenhuma ciência de foguetes e análises de técnicas hardcore dos artigos. Pelo contrário, será mais um material simples e mastigado para um público mais amplo e menos imerso.
Spoiler para quem ainda quer entrar em detalhes sobre a motivação
E ainda assim, o que me motivou. Darei um exemplo curto, mas revelador, da minha prática real:
[Imagem de duas capturas de tela de conversas]
A rotina diária de um líder de pentest...
À esquerda, meu velho amigo e um especialista muito experiente da Defensive Security, de quem foi, para dizer o mínimo, inesperado receber essa pergunta. À direita, um chat de trabalho com um cliente durante o projeto. Apesar da falta de contexto, a essência do problema é refletida por essas correspondências. Eu entenderia e não prestaria atenção, se fosse 1 caso em 20-30 projetos. Mas isso acontece com regularidade invejável até hoje.
Por um lado, isso pode não ser crítico. Especialmente quando o cliente e o executor esperam a mesma coisa do trabalho. Por outro lado, essa "sincronização" não acontece com tanta frequência quanto gostaríamos. E isso leva não apenas a mal-entendidos no nível da comunicação operacional, mas sim, e com mais frequência, ao fato de que uma parte (o cliente) espera um resultado, e a outra parte (o executor) entrega um resultado completamente diferente. E às vezes esse "mal-entendido" ocorre no nível da análise do Termo de Referência (TR) e da pré-venda. Alguns não entendem por que isso custa mais e leva mais tempo do que o esperado, e outros não entendem por que as condições no TR contradizem a prática estabelecida ou o que o cliente quer deles em princípio. No final, ninguém recebe o que deseja.
Nesse sentido, eu (e não só) tenho um desejo irresistível de contar ao mundo como entender esse mundo difícil de serviços de segurança ofensiva, destacar as diferenças nesses serviços e tirar conclusões sobre os benefícios de uma ou outra abordagem, resolvendo seus problemas. Claro, eu não sou o primeiro (e nem o último) a tentar fazer o mesmo. Há um certo número de artigos, podcasts, materiais de vídeo legais na rede, onde de uma forma ou de outra tudo é contado, e meus colegas do "lado vermelho" realmente fizeram um trabalho legal, que eu não quero e não tenho o direito de subestimar (olá e respeito aos caras da PT, Kaspersky, BI.Zone, Cicada8, UCSSB, Singleton e muitas outras empresas). Ao mesmo tempo, em cada um desses materiais, de uma forma ou de outra (pelo menos para mim), faltam algumas nuances para cobrir toda a imagem: em algum lugar técnicas, em algum lugar organização, em algum lugar uma base banal, porque o cálculo foi feito em um público bastante maduro. E para juntar toda a imagem na minha cabeça, você precisa não apenas rever/relê/ouvir tudo, mas também, em alguns lugares, até mesmo se envolver no estudo da questão. Este é um tempo precioso que sempre temos em falta.
Gostaria de começar o ciclo de artigos com uma citação do pensador francês Voltaire:
Voltaire, François-Marie Arouet
escritor e filósofo francês, um dos principais representantes do pensamento iluminista do século XVIII
"Quem não conhece o passado, não conhece o presente nem o futuro, nem a si mesmo"
Algo muito pomposo... Em geral, vamos começar com a história da segurança ofensiva em nosso mercado. Espero que o conhecimento de como tudo começou ajude no futuro a entender as nuances de pentests e red teams modernos. Além disso, essa breve excursão será interessante para jovens e promissores profissionais de segurança, e os mais experientes sentirão nostalgia e, possivelmente, até derramarão uma lágrima.
Então, vamos lá!
A História dos Serviços Ofensivos
Voltemos ao (já) distante final dos anos 2000, início dos anos 2010 do século XXI. A segurança da informação estava apenas ganhando força, o pentest como tal ainda não era tão popular quanto agora. Poucas empresas ofereciam esse serviço (de cabeça, só me lembrei da Informzashchita, DialogNauka e Digital Security), e as equipes internas de pentest em grandes empresas eram conhecidas um pouco menos do que nada. A qualidade do trabalho era determinada pelo nível de entusiasmo dos pentesteurs e pelo número de projetos concluídos. O processo médio de pentest (por exemplo, interno) naquele momento era aproximadamente o seguinte:
Chegamos ao objeto;
Conduzimos ataques de rede como ARP Spoofing ou VLAN-hopping. Talvez, se alguém estivesse familiarizado com o Responder (sim, o primeiro commit no Github data de 12 de fevereiro de 2013) - NBT-NS/LLMNR spoofing;
Executamos o lendário scanner de vulnerabilidades "azul-verde" ou o infame Xspider em todas as sub-redes disponíveis;
Vemos os resultados:
Encontrou alguma coisa? Super, tentamos explorá-lo, calculamos o CVSS manualmente, pensamos nas recomendações;
Não encontrou - bem, vamos escrever sobre "O nível de proteção é alto";
Fluxo aproximado de qualquer trabalho interno da época
Spoiler para quem pode se ofender...
Eu não quero dizer que todo mundo fazia isso. Este é um exemplo médio, que variou de executor para executor. Portanto, guarde suas pantufas com as quais você quer me atacar :)
Com o pentest externo, era mais ou menos a mesma coisa, apenas o scanner acima mencionado foi complementado por outro scanner "branco-vermelho" versão 10.5 para aplicações web (lembre-se de como ele se tornou cliente-servidor?). Ataques ao Kerberos? AD CS? Kubernetes? Não, não havia nada disso então. Embora em 2017 a história com ShadowBrokers e a vulnerabilidade EternalBlue tenha causado muito barulho e, desde então, no arsenal de pentesteurs ágeis, além do metasploit, apareceu sua própria máquina virtual com FuzzBunch.
Por que era assim? Para mim, identifiquei as seguintes razões:
Falta de experiência suficiente no mercado.
O pentest, como uma atividade metódica e formalizada, estava apenas amadurecendo. É normal, nunca dá para "fazer bonito" de imediato.
O nível de desenvolvimento tecnológico e a universalidade.
Naquela época, não havia divisão de especialistas em áreas, como agora. Os pentesteurs eram uma espécie de artesãos universais que sabiam como conduzir "aprspufing" e inserir uma aspa em um formulário de aplicação web. Bem, e, para ser justo, na época, a web não era tão pesada e, na maioria das vezes, do lado do servidor, não havia tantos frameworks JavaScript, os meios de proteção ainda não eram tão "malvados" como hoje, e nossa comunidade ainda não estudou tão profundamente o Windows e o Active Directory. Ser um universalista naquele momento era, em certa medida, a norma.
Falta de uma base metódica e prática adaptada.
Especialistas em segurança experientes podem, é claro, discordar de mim: "Sergey, você está errado! Havia OWASP, NIST 800-115 e PTES". Não discuto, havia, mas há uma pequena nuance, e vamos nos deter neste ponto com mais detalhes.
Na verdade, todos esses padrões e metodologias estavam lá na época, mas não para nós. Não é segredo que as tendências globais chegam às nossas terras com algum atraso. Agora, esse atraso, é claro, foi reduzido para semanas. Mas estamos falando dos anos 2010. Vamos tentar encontrar argumentos a favor disso e analisar os padrões que são mais frequentemente ouvidos, podem ser aplicados na prática e você os viu (ou até mesmo escreveu) em relatórios de pentest: OWASP, PTES, OSSTMM.
OWASP Testing Guide
A história deste guia começa em 2004. No entanto, ele se tornou mais ou menos usado a partir da segunda versão, que foi lançada em 2007. Chegou até nós mais perto do início dos anos 2010. Houve até uma campanha global para traduzir este guia para diferentes idiomas do mundo, incluindo o russo. Eles escreveram sobre isso no Habr. Vamos prestar atenção à data - 2014.
O próprio guia contém mais de 270 páginas e aplicá-lo na prática, como uma espécie de cheat sheet, era (e é) bastante difícil. Portanto, alguns pentesteurs fizeram seus próprios cheat sheets locais com base neste guia e em sua experiência. Posteriormente, um projeto separado apareceu OWASP Cheat Sheet, que já se tornou mais ou menos utilitário. É verdade, ele apareceu apenas em 2018 :) E, o que é importante, este guia foi útil para testar aplicações, mas não cobriu a "infraestrutura" em extensão suficiente.
PTES
Este padrão foi publicado pela primeira vez em 2009, e, ao contrário do mesmo OWASP Testing Guide, descreveu mais as etapas do processo e as ferramentas recomendadas (a lista das quais era frequentemente copiada para a "Lista de ferramentas usadas" nos mesmos relatórios de pentest). Novamente, usá-lo como um cheat sheet ou manual era bastante difícil, porque o texto PTES não implica especificidades sobre uma ou outra ação, e em alguns lugares até mesmo informações gerais estão ausentes.
Era 2026...
OSSTMM
Outro padrão estrangeiro, cuja primeira versão apareceu no final de 2000 (para quem quiser ver uma das primeiras versões - aqui), e a terceira versão (atualmente relevante) - no final de 2010. Novamente, se você se referir ao texto do padrão, dificilmente encontrará informações detalhadas, por exemplo, como e com o que realizar efetivamente o fuzzing de uma aplicação web ou como fazer corretamente o ARP spoofing para não direcionar todo o tráfego da sub-rede através de sua interface e não derrubar a rede de todo o andar do escritório do Cliente por algum tempo. (os pentesteurs experientes devem estar familiarizados com esta situação)
Em vez disso, você verá mais a concepção da abordagem de teste, começando pelas definições (segurança, conformidade, limites, controles, etc.) e terminando com os requisitos para o resultado, ou seja, o que você deve escrever no relatório e em que forma.
Não se parece com os relatórios que você escreveu ou recebeu, certo?
Havia uma série de outros padrões, metodologias e manuais (por exemplo, IDART, PCI DSS Penetration Testing Guidance ou RTFM), mas todos eles eram, na maioria das vezes, documentos formais e tinham pouca relação com a implementação prática do pentest. Sim, eu sei que já havia nossos padrões e metodologias domésticas (olá 15408, 27001, STO BR IBBS e outros), mas eles eram muito mais formais do que os documentos acima mencionados.
Mas tudo isso é "teoria em papel". Para ter certeza de minhas conclusões, há 3 anos realizei uma pequena pesquisa entre meus amigos e conhecidos, que naquela época eram pentesteurs comuns.
[Imagem de duas capturas de tela de conversas]
Paciente número um
Paciente número dois (digitou errado, acontece...)
O segundo, a propósito, observa corretamente outra coisa importante. Além de metodologias e listas de verificação, naquela época não havia tanta variedade de plataformas de treinamento ou imagens para autoestudo dos fundamentos do hacking. Só me lembrei de RootMe, bWAPP e Metasploitable. E, claro, muitos concursos CTF em CTFtime.org. (mas sabemos o quão "próximas" as condições do CTF são da vida real...)
Hoje, existe um número incontável de blogs, cheat sheets, cursos e plataformas dedicadas a pentests e red teams. Não vou listá-los aqui, pois pode não haver tempo suficiente para isso. Sim, antes havia cursos da EC-Council (o mesmo CEH) e da eLearn Security. Mas eles custavam dinheiro, ao contrário de blogs e repositórios Github de acesso público e gratuitos.
O resultado de tais trabalhos é um tipo separado de arte. Vamos dar uma olhada na captura de tela de parte de um relatório real de 2015 de uma respeitada empresa de SI:
[Imagem de um relatório]
Uuuh, RCE no Windows...
Mas se você olhar para a descrição da mesma vulnerabilidade nos resultados do "scanner de vulnerabilidades azul-verde" acima mencionado...
[Imagem de um relatório]
Hmm...
...então ficará claro que a seção do relatório é uma tradução-cópia da descrição da vulnerabilidade do scanner. E havia muitas dessas seções nos relatórios da época.
(você se lembra, sim, quem comprou um pentest naquela época?)
É daí que veio esse estereótipo de que os pentesteurs não trabalham sem um scanner de vulnerabilidades. Alguém estava satisfeito (e talvez ainda esteja satisfeito até hoje) com esse resultado. Não há nada de errado com isso, você ainda pode encontrar isso agora. Só que este não será um relatório de pentest, mas sim um relatório de varredura de vulnerabilidades.
No total, o que temos no final:
Não havia tanta experiência de combate.
A base metódica estava lá, mas não era aplicável na prática.
Cada um tinha sua própria base prática e seu nível de experiência dependia do entusiasmo do pentesteur.
Os pentesteurs eram "universais".
As tecnologias na época não eram tão complexas.
A diferença dos serviços agora e então
Voltemos aos nossos dias. Se você visitou conferências conhecidas, onde há uma caravana de estandes com ofertas de serviços e produtos em uma grande área, então você definitivamente viu folhetos com a descrição de todos os serviços oferecidos. E hoje, as informações sobre serviços ofensivos geralmente não cabem em um lado de uma folha no formato A5. Haverá ofertas como:
Varredura de vulnerabilidades;
Pentest externo;
Pentest interno;
Análise de aplicações (web e mobile);
Engenharia social;
Análise de redes Wi-Fi;
Pentest físico;
CPT (também conhecido como Continuous Penetration Testing);
Red Team;
Purple Team;
Exercícios cibernéticos.
Para comparação, as ofertas da época continham cerca de 3 serviços:
Pentest;
Pentest abrangente;
Análise de segurança.
E cada serviço moderno, na verdade, tornou-se independente, com seus próprios requisitos, restrições e características. É lógico. As tecnologias se tornaram muito mais complexas (só os contêineres e as infraestruturas em nuvem valem alguma coisa), leva mais tempo para estudar/analisar um pedaço específico da infraestrutura, o número de ameaças e vulnerabilidades conhecidas só aumenta a cada dia. Tudo isso ainda é temperado com o nível de maturidade e a diversidade de ferramentas de proteção, o que, sem dúvida, complica e encarece o ataque, mas nunca reduz sua probabilidade a zero. Daí resulta que para cada tipo de trabalho são necessárias suas próprias competências, seus próprios prazos e outras nuances. Darei alguns exemplos para argumentar meus pensamentos, e se meus colegas do setor nos comentários confirmarem (ou refutarem) os exemplos fornecidos, será ótimo.
Pentest Interno
Eu já dei um exemplo de pentests internos anteriores acima. Naquela época, não se sabia e/ou não se encontrava tantas vulnerabilidades que permitissem comprometer completamente toda a infraestrutura. De cabeça, das mais penetrantes, posso lembrar MS08-067 e MS17-010. E, francamente, no arsenal do pentesteur de infraestrutura, era suficiente ter um scanner de vulnerabilidades, metasploit e algumas utilidades como Responder, THC-Hydra ou bettercap para quebrar a infraestrutura de um Cliente médio.
No entanto, após o famoso EternalBlue e a entrada em cena do pentest russo do infame Kerberoasting (embora tenha sido publicado oficialmente em 2014 no Derbycon 2014, mas o primeiro commit no Impacket do script GetUserSPNs.py foi feito em maio de 2016, e chegou até nós um pouco mais tarde), o número de vulnerabilidades e ataques à infraestrutura do Windows começou a crescer rapidamente. Naquela época, os ataques agora conhecidos como UD/CD/RBCD, ataques ao WSUS, ADCS, SCCM, ataques Pre-2K, etc. já estavam sendo usados.
No processo de escrita deste texto, decidi aproveitar os benefícios do progresso técnico e pedi à rede neural que reunisse estatísticas para mim nos últimos 15+ anos. O que aconteceu:
[Imagem de um gráfico]
Obrigado ao ChatGPT pelas estatísticas tortas, mas visuais
Spoiler para os curiosos e céticos
Para não sobrecarregá-lo com o texto completo das pesquisas de IA, compartilharei apenas meu prompt inicial para aqueles que desejam comparar o resultado com o gráfico acima:
Prepare estatísticas de vulnerabilidades detectadas no Windows OS e Active Directory para o período de 2010-2025. As estatísticas devem incluir apenas as vulnerabilidades que pertencem à classe RCE e Relay, foram exploradas ativamente em ataques reais e têm ferramentas e descrições públicas em blogs de pesquisadores de segurança.
Adicione às estatísticas uma lista de ataques ao Windows e Active Directory que podem não ter recebido um identificador CVE, mas ainda foram usados em ataques reais e têm uma descrição pública e ferramentas de exploração. Por exemplo, ataques ao Kerberos, LDAP, WSUS, SCCM e outros. Ou seja, é necessário determinar em que ano apareceu um determinado ataque e adicionar essa informação às estatísticas. Como fonte de tais ataques, você pode usar o mindmap da Orange Cyberdefence (https://orange-cyberdefence.github.io/ocd-mindmaps/), mas não se limite a ele.
Para cada vulnerabilidade/ataque, deve haver um link para um recurso com uma descrição, bem como links para ferramentas e PoCs disponíveis publicamente.
As estatísticas devem ser apresentadas nos seguintes formatos:
Uma tabela com as colunas "Ano", "Nomes de vulnerabilidades", "Números CVE", "Números MS" (por exemplo, MS08-067), "Links", onde cada linha é o ano de publicação da vulnerabilidade/ataque
Um gráfico cumulativo de detecção de vulnerabilidades por ano, onde o eixo X são os anos, o eixo Y é o número de vulnerabilidades
Daquele momento (ou seja, por volta de 2017-2018), o arsenal do pentesteur já havia ido muito além do metasploit. Impacket, BloodHound e todos os tipos de ntlmrelayx com certyfy/certipy e muito, muito mais começaram a aparecer lá. A partir do mesmo momento, um especialista ofensivo médio não conseguia mais manter informações na cabeça sobre aplicações e infraestrutura. Bem, e o tempo para realizar um pentest interno de qualidade tornou-se proporcionalmente maior, o que, em combinação com o resto, o tornou de um "estágio" em um serviço especializado independente.
Análise de Aplicações
A imagem geral é semelhante ao pentest de infraestrutura. No início da ofensiva, as aplicações web eram predominantemente do lado do servidor. Toda a lógica e segurança eram fornecidas pelo servidor, e o JavaScript, na grande maioria dos casos, era responsável apenas pela interpretação dos dados no lado do cliente. Posteriormente, quando, grosseiramente falando, os XSSs começaram a ser explorados com mais frequência no ITW, os desenvolvedores começaram a prestar mais atenção ao lado do cliente e a aplicar com mais responsabilidade todos os tipos de SOP/CORS/CSP e outros mecanismos, que também se tornaram dramaticamente mais complexos hoje.
Também adicionaram complexidade ao trabalho dos web pentesteurs, é claro, frameworks e linguagens de programação. Novamente, se você se referir às estatísticas públicas da aparência de linguagens e frameworks para desenvolvimento de aplicações (mesmo que não sejam totalmente precisas e coletadas por uma rede neural), poderá ver a dinâmica do crescimento do zoológico de uma variedade de tecnologias que os webbers têm que enfrentar. E quanto mais recente for essa tecnologia, mais provável é que ela tenha sido desenvolvida Secure by Design, e isso torna ainda mais difícil encontrar vulnerabilidades em tal produto. Vamos temperar isso com o conceito de "multicamadas".
A aplicação moderna não é apenas um monte de arquivos PHP no sistema de arquivos do servidor, mas uma combinação inteira de tecnologias como Kubernetes, S3, gRPC, GraphQL, etc., que também funciona por meio de um proxy reverso. Sim, pode-se notar com justiça que muitas das tecnologias usadas são, de alguma forma, padronizadas e padronizadas. Mas é daí que a complexidade cresce, pois, excluindo vulnerabilidades simples como injeções de SQL, XXE ou desserializações inseguras, aparecem bugs mais complexos, cuja busca requer não apenas o conhecimento das coisas básicas "de cor", mas também a compreensão do funcionamento de uma ou outra tecnologia no nível de um desenvolvedor profissional.
E não se deve perder de vista o fato de que, no geral, a cultura de desenvolvimento seguro cresceu nos últimos 15 anos e não se compara ao que era no início dos anos 2010.
[Imagem de um gráfico]
Obrigado (novamente) ao ChatGPT pelas estatísticas tortas, mas visuais
Spoiler para os curiosos e céticos
Também estou compartilhando meu prompt inicial, que ajustei ligeiramente com perguntas subsequentes:
Reúna estatísticas sobre a aparência de linguagens de programação e frameworks para desenvolvimento de aplicações, a partir de 2010 e terminando em 2025. As estatísticas devem levar em consideração produtos modernos populares, com base nos quais as aplicações web e móveis estão sendo desenvolvidas agora. As estatísticas devem estar em dois formatos:
Tabela com divisão por ano
Gráfico cumulativo da aparência de produtos, onde o eixo X são os anos, o eixo Y é o número de produtos
Os mesmos exemplos podem ser dados para pentests externos, e para "wi-fi", e outros serviços, mas então a leitura deste artigo se transformará em uma atividade entediante. Em geral, você entendeu a essência.
Spoiler para quem pegou a pantufa
Eu intencionalmente não levo em consideração aqui o progresso tanto dos próprios meios de proteção quanto da maturidade dos processos de SI nas empresas, porque um pentest adequado, em geral, não deve ser combatido. Mas vou revelar esse pensamento em detalhes nos próximos artigos, não se preocupe.
Como viver com isso
Muito provavelmente, alguns leitores deste artigo terão a pergunta: "E o que acontece a seguir? Bem, tudo ficou mais complicado, e o que eu faço com isso?" Justo, eu também teria. Responderei a esta e muitas outras perguntas nos próximos artigos, onde tentarei analisar detalhadamente cada um dos tipos de serviços ofensivos em comparação com outros.
Talvez você tenha outras perguntas que seria interessante analisar nos próximos materiais. Não hesite, escreva-as nos comentários, e tentarei analisar o máximo de questões possível.
Enquanto isso, com este texto, eu queria mergulhar o leitor em uma excursão muito breve, em alguns lugares subjetiva, de serviços ofensivos, que no futuro o ajudará a olhar um pouco de um ângulo diferente para os serviços que existem agora no mercado e, espero, corrigir um pouco sua visão e compreensão.
Fique ligado, até os próximos artigos!
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Análise de Segurança 15 Anos Depois: Ato I
Olá a todos! Meu nome é Sergey e sou diretor do Centro de Pesquisa de Ciberameaças na Angara Security. Tenho trabalhado e liderado pentests e red teams durante toda a minha carreira consciente em segurança da informação (SI).
Quero compartilhar com vocês, nossos queridos e respeitados leitores, minhas reflexões sobre a substituição de conceitos nos serviços de análise de segurança. Muitas vezes vi (e ainda vejo com frequência) como um pentest é chamado de "varredura de vulnerabilidades", ou como o conceito de Red Team engloba um pentest comum, mesmo com elementos de "contra-medidas".
Sem entrar em detalhes sobre minha motivação, decidi fazer um ciclo de artigos onde, com base em minha experiência e na experiência de meus colegas, tentarei detalhar toda a parte ofensiva, com exemplos e explicações dos pontos realmente importantes que afetam a qualidade, a duração e o custo de tais trabalhos, com análise de casos reais da minha prática e outras coisas. Devo dizer de antemão que tentarei fazer isso em um formato leve e descontraído, para que a leitura desses artigos não se transforme em uma atividade entediante e os leitores não queiram, em vez de ler, ir "assistir a vídeos curtos" ou se envolver em coisas mais úteis. Não espere nenhuma ciência de foguetes e análises de técnicas hardcore dos artigos. Pelo contrário, será mais um material simples e mastigado para um público mais amplo e menos imerso.
Spoiler para quem ainda quer entrar em detalhes sobre a motivação
E ainda assim, o que me motivou. Darei um exemplo curto, mas revelador, da minha prática real:
[Imagem de duas capturas de tela de conversas]
A rotina diária de um líder de pentest...
À esquerda, meu velho amigo e um especialista muito experiente da Defensive Security, de quem foi, para dizer o mínimo, inesperado receber essa pergunta. À direita, um chat de trabalho com um cliente durante o projeto. Apesar da falta de contexto, a essência do problema é refletida por essas correspondências. Eu entenderia e não prestaria atenção, se fosse 1 caso em 20-30 projetos. Mas isso acontece com regularidade invejável até hoje.
Por um lado, isso pode não ser crítico. Especialmente quando o cliente e o executor esperam a mesma coisa do trabalho. Por outro lado, essa "sincronização" não acontece com tanta frequência quanto gostaríamos. E isso leva não apenas a mal-entendidos no nível da comunicação operacional, mas sim, e com mais frequência, ao fato de que uma parte (o cliente) espera um resultado, e a outra parte (o executor) entrega um resultado completamente diferente. E às vezes esse "mal-entendido" ocorre no nível da análise do Termo de Referência (TR) e da pré-venda. Alguns não entendem por que isso custa mais e leva mais tempo do que o esperado, e outros não entendem por que as condições no TR contradizem a prática estabelecida ou o que o cliente quer deles em princípio. No final, ninguém recebe o que deseja.
Nesse sentido, eu (e não só) tenho um desejo irresistível de contar ao mundo como entender esse mundo difícil de serviços de segurança ofensiva, destacar as diferenças nesses serviços e tirar conclusões sobre os benefícios de uma ou outra abordagem, resolvendo seus problemas. Claro, eu não sou o primeiro (e nem o último) a tentar fazer o mesmo. Há um certo número de artigos, podcasts, materiais de vídeo legais na rede, onde de uma forma ou de outra tudo é contado, e meus colegas do "lado vermelho" realmente fizeram um trabalho legal, que eu não quero e não tenho o direito de subestimar (olá e respeito aos caras da PT, Kaspersky, BI.Zone, Cicada8, UCSSB, Singleton e muitas outras empresas). Ao mesmo tempo, em cada um desses materiais, de uma forma ou de outra (pelo menos para mim), faltam algumas nuances para cobrir toda a imagem: em algum lugar técnicas, em algum lugar organização, em algum lugar uma base banal, porque o cálculo foi feito em um público bastante maduro. E para juntar toda a imagem na minha cabeça, você precisa não apenas rever/relê/ouvir tudo, mas também, em alguns lugares, até mesmo se envolver no estudo da questão. Este é um tempo precioso que sempre temos em falta.
Gostaria de começar o ciclo de artigos com uma citação do pensador francês Voltaire:
Voltaire, François-Marie Arouet
escritor e filósofo francês, um dos principais representantes do pensamento iluminista do século XVIII
"Quem não conhece o passado, não conhece o presente nem o futuro, nem a si mesmo"
Algo muito pomposo... Em geral, vamos começar com a história da segurança ofensiva em nosso mercado. Espero que o conhecimento de como tudo começou ajude no futuro a entender as nuances de pentests e red teams modernos. Além disso, essa breve excursão será interessante para jovens e promissores profissionais de segurança, e os mais experientes sentirão nostalgia e, possivelmente, até derramarão uma lágrima.
Então, vamos lá!
A História dos Serviços Ofensivos
Voltemos ao (já) distante final dos anos 2000, início dos anos 2010 do século XXI. A segurança da informação estava apenas ganhando força, o pentest como tal ainda não era tão popular quanto agora. Poucas empresas ofereciam esse serviço (de cabeça, só me lembrei da Informzashchita, DialogNauka e Digital Security), e as equipes internas de pentest em grandes empresas eram conhecidas um pouco menos do que nada. A qualidade do trabalho era determinada pelo nível de entusiasmo dos pentesteurs e pelo número de projetos concluídos. O processo médio de pentest (por exemplo, interno) naquele momento era aproximadamente o seguinte:
Chegamos ao objeto;
Conduzimos ataques de rede como ARP Spoofing ou VLAN-hopping. Talvez, se alguém estivesse familiarizado com o Responder (sim, o primeiro commit no Github data de 12 de fevereiro de 2013) - NBT-NS/LLMNR spoofing;
Executamos o lendário scanner de vulnerabilidades "azul-verde" ou o infame Xspider em todas as sub-redes disponíveis;
Vemos os resultados:
Encontrou alguma coisa? Super, tentamos explorá-lo, calculamos o CVSS manualmente, pensamos nas recomendações;
Não encontrou - bem, vamos escrever sobre "O nível de proteção é alto";
Fluxo aproximado de qualquer trabalho interno da época
Spoiler para quem pode se ofender...
Eu não quero dizer que todo mundo fazia isso. Este é um exemplo médio, que variou de executor para executor. Portanto, guarde suas pantufas com as quais você quer me atacar :)
Com o pentest externo, era mais ou menos a mesma coisa, apenas o scanner acima mencionado foi complementado por outro scanner "branco-vermelho" versão 10.5 para aplicações web (lembre-se de como ele se tornou cliente-servidor?). Ataques ao Kerberos? AD CS? Kubernetes? Não, não havia nada disso então. Embora em 2017 a história com ShadowBrokers e a vulnerabilidade EternalBlue tenha causado muito barulho e, desde então, no arsenal de pentesteurs ágeis, além do metasploit, apareceu sua própria máquina virtual com FuzzBunch.
Por que era assim? Para mim, identifiquei as seguintes razões:
Falta de experiência suficiente no mercado.
O pentest, como uma atividade metódica e formalizada, estava apenas amadurecendo. É normal, nunca dá para "fazer bonito" de imediato.
O nível de desenvolvimento tecnológico e a universalidade.
Naquela época, não havia divisão de especialistas em áreas, como agora. Os pentesteurs eram uma espécie de artesãos universais que sabiam como conduzir "aprspufing" e inserir uma aspa em um formulário de aplicação web. Bem, e, para ser justo, na época, a web não era tão pesada e, na maioria das vezes, do lado do servidor, não havia tantos frameworks JavaScript, os meios de proteção ainda não eram tão "malvados" como hoje, e nossa comunidade ainda não estudou tão profundamente o Windows e o Active Directory. Ser um universalista naquele momento era, em certa medida, a norma.
Falta de uma base metódica e prática adaptada.
Especialistas em segurança experientes podem, é claro, discordar de mim: "Sergey, você está errado! Havia OWASP, NIST 800-115 e PTES". Não discuto, havia, mas há uma pequena nuance, e vamos nos deter neste ponto com mais detalhes.
Na verdade, todos esses padrões e metodologias estavam lá na época, mas não para nós. Não é segredo que as tendências globais chegam às nossas terras com algum atraso. Agora, esse atraso, é claro, foi reduzido para semanas. Mas estamos falando dos anos 2010. Vamos tentar encontrar argumentos a favor disso e analisar os padrões que são mais frequentemente ouvidos, podem ser aplicados na prática e você os viu (ou até mesmo escreveu) em relatórios de pentest: OWASP, PTES, OSSTMM.
OWASP Testing Guide
A história deste guia começa em 2004. No entanto, ele se tornou mais ou menos usado a partir da segunda versão, que foi lançada em 2007. Chegou até nós mais perto do início dos anos 2010. Houve até uma campanha global para traduzir este guia para diferentes idiomas do mundo, incluindo o russo. Eles escreveram sobre isso no Habr. Vamos prestar atenção à data - 2014.
O próprio guia contém mais de 270 páginas e aplicá-lo na prática, como uma espécie de cheat sheet, era (e é) bastante difícil. Portanto, alguns pentesteurs fizeram seus próprios cheat sheets locais com base neste guia e em sua experiência. Posteriormente, um projeto separado apareceu OWASP Cheat Sheet, que já se tornou mais ou menos utilitário. É verdade, ele apareceu apenas em 2018 :) E, o que é importante, este guia foi útil para testar aplicações, mas não cobriu a "infraestrutura" em extensão suficiente.
PTES
Este padrão foi publicado pela primeira vez em 2009, e, ao contrário do mesmo OWASP Testing Guide, descreveu mais as etapas do processo e as ferramentas recomendadas (a lista das quais era frequentemente copiada para a "Lista de ferramentas usadas" nos mesmos relatórios de pentest). Novamente, usá-lo como um cheat sheet ou manual era bastante difícil, porque o texto PTES não implica especificidades sobre uma ou outra ação, e em alguns lugares até mesmo informações gerais estão ausentes.
Era 2026...
OSSTMM
Outro padrão estrangeiro, cuja primeira versão apareceu no final de 2000 (para quem quiser ver uma das primeiras versões - aqui), e a terceira versão (atualmente relevante) - no final de 2010. Novamente, se você se referir ao texto do padrão, dificilmente encontrará informações detalhadas, por exemplo, como e com o que realizar efetivamente o fuzzing de uma aplicação web ou como fazer corretamente o ARP spoofing para não direcionar todo o tráfego da sub-rede através de sua interface e não derrubar a rede de todo o andar do escritório do Cliente por algum tempo. (os pentesteurs experientes devem estar familiarizados com esta situação)
Em vez disso, você verá mais a concepção da abordagem de teste, começando pelas definições (segurança, conformidade, limites, controles, etc.) e terminando com os requisitos para o resultado, ou seja, o que você deve escrever no relatório e em que forma.
Não se parece com os relatórios que você escreveu ou recebeu, certo?
Havia uma série de outros padrões, metodologias e manuais (por exemplo, IDART, PCI DSS Penetration Testing Guidance ou RTFM), mas todos eles eram, na maioria das vezes, documentos formais e tinham pouca relação com a implementação prática do pentest. Sim, eu sei que já havia nossos padrões e metodologias domésticas (olá 15408, 27001, STO BR IBBS e outros), mas eles eram muito mais formais do que os documentos acima mencionados.
Mas tudo isso é "teoria em papel". Para ter certeza de minhas conclusões, há 3 anos realizei uma pequena pesquisa entre meus amigos e conhecidos, que naquela época eram pentesteurs comuns.
[Imagem de duas capturas de tela de conversas]
Paciente número um
Paciente número dois (digitou errado, acontece...)
O segundo, a propósito, observa corretamente outra coisa importante. Além de metodologias e listas de verificação, naquela época não havia tanta variedade de plataformas de treinamento ou imagens para autoestudo dos fundamentos do hacking. Só me lembrei de RootMe, bWAPP e Metasploitable. E, claro, muitos concursos CTF em CTFtime.org. (mas sabemos o quão "próximas" as condições do CTF são da vida real...)
Hoje, existe um número incontável de blogs, cheat sheets, cursos e plataformas dedicadas a pentests e red teams. Não vou listá-los aqui, pois pode não haver tempo suficiente para isso. Sim, antes havia cursos da EC-Council (o mesmo CEH) e da eLearn Security. Mas eles custavam dinheiro, ao contrário de blogs e repositórios Github de acesso público e gratuitos.
O resultado de tais trabalhos é um tipo separado de arte. Vamos dar uma olhada na captura de tela de parte de um relatório real de 2015 de uma respeitada empresa de SI:
[Imagem de um relatório]
Uuuh, RCE no Windows...
Mas se você olhar para a descrição da mesma vulnerabilidade nos resultados do "scanner de vulnerabilidades azul-verde" acima mencionado...
[Imagem de um relatório]
Hmm...
...então ficará claro que a seção do relatório é uma tradução-cópia da descrição da vulnerabilidade do scanner. E havia muitas dessas seções nos relatórios da época.
(você se lembra, sim, quem comprou um pentest naquela época?)
É daí que veio esse estereótipo de que os pentesteurs não trabalham sem um scanner de vulnerabilidades. Alguém estava satisfeito (e talvez ainda esteja satisfeito até hoje) com esse resultado. Não há nada de errado com isso, você ainda pode encontrar isso agora. Só que este não será um relatório de pentest, mas sim um relatório de varredura de vulnerabilidades.
No total, o que temos no final:
Não havia tanta experiência de combate.
A base metódica estava lá, mas não era aplicável na prática.
Cada um tinha sua própria base prática e seu nível de experiência dependia do entusiasmo do pentesteur.
Os pentesteurs eram "universais".
As tecnologias na época não eram tão complexas.
A diferença dos serviços agora e então
Voltemos aos nossos dias. Se você visitou conferências conhecidas, onde há uma caravana de estandes com ofertas de serviços e produtos em uma grande área, então você definitivamente viu folhetos com a descrição de todos os serviços oferecidos. E hoje, as informações sobre serviços ofensivos geralmente não cabem em um lado de uma folha no formato A5. Haverá ofertas como:
Varredura de vulnerabilidades;
Pentest externo;
Pentest interno;
Análise de aplicações (web e mobile);
Engenharia social;
Análise de redes Wi-Fi;
Pentest físico;
CPT (também conhecido como Continuous Penetration Testing);
Red Team;
Purple Team;
Exercícios cibernéticos.
Para comparação, as ofertas da época continham cerca de 3 serviços:
Pentest;
Pentest abrangente;
Análise de segurança.
E cada serviço moderno, na verdade, tornou-se independente, com seus próprios requisitos, restrições e características. É lógico. As tecnologias se tornaram muito mais complexas (só os contêineres e as infraestruturas em nuvem valem alguma coisa), leva mais tempo para estudar/analisar um pedaço específico da infraestrutura, o número de ameaças e vulnerabilidades conhecidas só aumenta a cada dia. Tudo isso ainda é temperado com o nível de maturidade e a diversidade de ferramentas de proteção, o que, sem dúvida, complica e encarece o ataque, mas nunca reduz sua probabilidade a zero. Daí resulta que para cada tipo de trabalho são necessárias suas próprias competências, seus próprios prazos e outras nuances. Darei alguns exemplos para argumentar meus pensamentos, e se meus colegas do setor nos comentários confirmarem (ou refutarem) os exemplos fornecidos, será ótimo.
Pentest Interno
Eu já dei um exemplo de pentests internos anteriores acima. Naquela época, não se sabia e/ou não se encontrava tantas vulnerabilidades que permitissem comprometer completamente toda a infraestrutura. De cabeça, das mais penetrantes, posso lembrar MS08-067 e MS17-010. E, francamente, no arsenal do pentesteur de infraestrutura, era suficiente ter um scanner de vulnerabilidades, metasploit e algumas utilidades como Responder, THC-Hydra ou bettercap para quebrar a infraestrutura de um Cliente médio.
No entanto, após o famoso EternalBlue e a entrada em cena do pentest russo do infame Kerberoasting (embora tenha sido publicado oficialmente em 2014 no Derbycon 2014, mas o primeiro commit no Impacket do script GetUserSPNs.py foi feito em maio de 2016, e chegou até nós um pouco mais tarde), o número de vulnerabilidades e ataques à infraestrutura do Windows começou a crescer rapidamente. Naquela época, os ataques agora conhecidos como UD/CD/RBCD, ataques ao WSUS, ADCS, SCCM, ataques Pre-2K, etc. já estavam sendo usados.
No processo de escrita deste texto, decidi aproveitar os benefícios do progresso técnico e pedi à rede neural que reunisse estatísticas para mim nos últimos 15+ anos. O que aconteceu:
[Imagem de um gráfico]
Obrigado ao ChatGPT pelas estatísticas tortas, mas visuais
Spoiler para os curiosos e céticos
Para não sobrecarregá-lo com o texto completo das pesquisas de IA, compartilharei apenas meu prompt inicial para aqueles que desejam comparar o resultado com o gráfico acima:
Prepare estatísticas de vulnerabilidades detectadas no Windows OS e Active Directory para o período de 2010-2025. As estatísticas devem incluir apenas as vulnerabilidades que pertencem à classe RCE e Relay, foram exploradas ativamente em ataques reais e têm ferramentas e descrições públicas em blogs de pesquisadores de segurança.
Adicione às estatísticas uma lista de ataques ao Windows e Active Directory que podem não ter recebido um identificador CVE, mas ainda foram usados em ataques reais e têm uma descrição pública e ferramentas de exploração. Por exemplo, ataques ao Kerberos, LDAP, WSUS, SCCM e outros. Ou seja, é necessário determinar em que ano apareceu um determinado ataque e adicionar essa informação às estatísticas. Como fonte de tais ataques, você pode usar o mindmap da Orange Cyberdefence (https://orange-cyberdefence.github.io/ocd-mindmaps/), mas não se limite a ele.
Para cada vulnerabilidade/ataque, deve haver um link para um recurso com uma descrição, bem como links para ferramentas e PoCs disponíveis publicamente.
As estatísticas devem ser apresentadas nos seguintes formatos:
Uma tabela com as colunas "Ano", "Nomes de vulnerabilidades", "Números CVE", "Números MS" (por exemplo, MS08-067), "Links", onde cada linha é o ano de publicação da vulnerabilidade/ataque
Um gráfico cumulativo de detecção de vulnerabilidades por ano, onde o eixo X são os anos, o eixo Y é o número de vulnerabilidades
Daquele momento (ou seja, por volta de 2017-2018), o arsenal do pentesteur já havia ido muito além do metasploit. Impacket, BloodHound e todos os tipos de ntlmrelayx com certyfy/certipy e muito, muito mais começaram a aparecer lá. A partir do mesmo momento, um especialista ofensivo médio não conseguia mais manter informações na cabeça sobre aplicações e infraestrutura. Bem, e o tempo para realizar um pentest interno de qualidade tornou-se proporcionalmente maior, o que, em combinação com o resto, o tornou de um "estágio" em um serviço especializado independente.
Análise de Aplicações
A imagem geral é semelhante ao pentest de infraestrutura. No início da ofensiva, as aplicações web eram predominantemente do lado do servidor. Toda a lógica e segurança eram fornecidas pelo servidor, e o JavaScript, na grande maioria dos casos, era responsável apenas pela interpretação dos dados no lado do cliente. Posteriormente, quando, grosseiramente falando, os XSSs começaram a ser explorados com mais frequência no ITW, os desenvolvedores começaram a prestar mais atenção ao lado do cliente e a aplicar com mais responsabilidade todos os tipos de SOP/CORS/CSP e outros mecanismos, que também se tornaram dramaticamente mais complexos hoje.
Também adicionaram complexidade ao trabalho dos web pentesteurs, é claro, frameworks e linguagens de programação. Novamente, se você se referir às estatísticas públicas da aparência de linguagens e frameworks para desenvolvimento de aplicações (mesmo que não sejam totalmente precisas e coletadas por uma rede neural), poderá ver a dinâmica do crescimento do zoológico de uma variedade de tecnologias que os webbers têm que enfrentar. E quanto mais recente for essa tecnologia, mais provável é que ela tenha sido desenvolvida Secure by Design, e isso torna ainda mais difícil encontrar vulnerabilidades em tal produto. Vamos temperar isso com o conceito de "multicamadas".
A aplicação moderna não é apenas um monte de arquivos PHP no sistema de arquivos do servidor, mas uma combinação inteira de tecnologias como Kubernetes, S3, gRPC, GraphQL, etc., que também funciona por meio de um proxy reverso. Sim, pode-se notar com justiça que muitas das tecnologias usadas são, de alguma forma, padronizadas e padronizadas. Mas é daí que a complexidade cresce, pois, excluindo vulnerabilidades simples como injeções de SQL, XXE ou desserializações inseguras, aparecem bugs mais complexos, cuja busca requer não apenas o conhecimento das coisas básicas "de cor", mas também a compreensão do funcionamento de uma ou outra tecnologia no nível de um desenvolvedor profissional.
E não se deve perder de vista o fato de que, no geral, a cultura de desenvolvimento seguro cresceu nos últimos 15 anos e não se compara ao que era no início dos anos 2010.
[Imagem de um gráfico]
Obrigado (novamente) ao ChatGPT pelas estatísticas tortas, mas visuais
Spoiler para os curiosos e céticos
Também estou compartilhando meu prompt inicial, que ajustei ligeiramente com perguntas subsequentes:
Reúna estatísticas sobre a aparência de linguagens de programação e frameworks para desenvolvimento de aplicações, a partir de 2010 e terminando em 2025. As estatísticas devem levar em consideração produtos modernos populares, com base nos quais as aplicações web e móveis estão sendo desenvolvidas agora. As estatísticas devem estar em dois formatos:
Tabela com divisão por ano
Gráfico cumulativo da aparência de produtos, onde o eixo X são os anos, o eixo Y é o número de produtos
Os mesmos exemplos podem ser dados para pentests externos, e para "wi-fi", e outros serviços, mas então a leitura deste artigo se transformará em uma atividade entediante. Em geral, você entendeu a essência.
Spoiler para quem pegou a pantufa
Eu intencionalmente não levo em consideração aqui o progresso tanto dos próprios meios de proteção quanto da maturidade dos processos de SI nas empresas, porque um pentest adequado, em geral, não deve ser combatido. Mas vou revelar esse pensamento em detalhes nos próximos artigos, não se preocupe.
Como viver com isso
Muito provavelmente, alguns leitores deste artigo terão a pergunta: "E o que acontece a seguir? Bem, tudo ficou mais complicado, e o que eu faço com isso?" Justo, eu também teria. Responderei a esta e muitas outras perguntas nos próximos artigos, onde tentarei analisar detalhadamente cada um dos tipos de serviços ofensivos em comparação com outros.
Talvez você tenha outras perguntas que seria interessante analisar nos próximos materiais. Não hesite, escreva-as nos comentários, e tentarei analisar o máximo de questões possível.
Enquanto isso, com este texto, eu queria mergulhar o leitor em uma excursão muito breve, em alguns lugares subjetiva, de serviços ofensivos, que no futuro o ajudará a olhar um pouco de um ângulo diferente para os serviços que existem agora no mercado e, espero, corrigir um pouco sua visão e compreensão.
Fique ligado, até os próximos artigos!
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
