2026-07-15 · PRÁTICA · A equipe da Offensive Technology

Por que todo projeto começa com uma assinatura

Existe exatamente uma coisa que separa um teste de intrusão de um crime cibernético, e não é habilidade, ferramentas ou intenção. É a autorização. O mesmo comando executado contra o mesmo servidor é um serviço profissional na terça-feira e um crime grave na quarta-feira, e a única diferença é um pedaço de papel.

Portanto, antes de tocarmos em qualquer coisa, garantimos que esse papel esteja correto. Aqui está o que isso realmente significa na prática e por que não pularemos essa etapa, mesmo quando o cliente estiver com pressa.

Propriedade antes do acesso

A primeira pergunta não é "o que você quer testar", é "você pode provar que controla isso". Qualquer um pode digitar um domínio em um formulário. Isso não significa que ele seja o proprietário, e se não for, testá-lo nos coloca, a ambos, do lado errado da lei.

Então nós verificamos. Geralmente isso significa inserir um token em um registro DNS que possamos ler, ou confirmar a partir de um endereço de e-mail no próprio domínio. Leva alguns minutos e não é negociável. Se você não puder provar o controle do alvo, não há projeto a ser realizado.

Também não confiamos apenas em uma assinatura. Obtemos autorização por escrito de uma pessoa identificada e ainda assim exigimos a prova técnica por trás dela, porque uma assinatura no timbrado errado é exatamente como um pentester acaba mirando no alvo errado.

O escopo é uma cerca, não uma sugestão

Assim que a propriedade é estabelecida, documentamos exatamente o que está no escopo e o que não está: quais hosts, quais aplicações, quais técnicas e quais estão explicitamente fora de questão. Esse documento é a cerca. Permanecemos dentro dele mesmo quando algo interessante estiver claramente acessível logo do lado de fora.

• Os ativos que temos permissão para tocar, listados por nome.
• As técnicas que você aprovou e qualquer uma que tenha descartado.
• Janelas de execução, para que os testes nunca surpreendam sua equipe ou seus clientes.
• Um contato identificado que possa interromper tudo com uma única mensagem.

O mesmo documento define duas coisas que as pessoas esquecem até que se tornem críticas. Primeiro, o ambiente: estamos testando em produção, onde uma requisição pesada pode afetar clientes reais, ou em uma cópia de staging que o espelha? Ambas são escolhas válidas, mas a decisão precisa ser intencional, e não descoberta no meio do teste. Segundo, a condição de interrupção: quem pode parar o teste, como entrar em contato conosco e o que acontece com qualquer acesso já obtido caso o façam. Este é um acordo pré-projeto assinado, não um entendimento informal. Quando bem feito, ninguém precisa improvisar sob pressão.

Quando o alvo não é totalmente seu

Possuir um nome de domínio não é o mesmo que possuir tudo para onde ele aponta, e é aqui que escopos bem intencionados dão errado. Um exemplo comum: um cliente lista app.clientco.com como dentro do escopo. Nós consultamos e vemos que é um CNAME para uma plataforma SaaS de terceiros que o cliente assina, mas não opera. Ele controla o nome DNS; não controla os servidores por trás dele. Testar esse host significa testar o fornecedor, que não concordou com nada. Portanto, ele sai do escopo ou o cliente obtém autorização por escrito do fornecedor primeiro.

O mesmo cuidado se aplica a ativos em hospedagem compartilhada ou atrás de uma CDN compartilhada, onde um único endereço IP pode servir a milhares de clientes não relacionados, e a um domínio adquirido em uma transação cujos registros ainda resolvem para a infraestrutura do vendedor. Os principais provedores de nuvem também publicam suas próprias políticas de testes aceitáveis, e algumas atividades, em particular testes de negação de serviço e testes de estresse, ainda exigem notificação ou aprovação prévia, mesmo em recursos dos quais você seja dono. Desvendar o que é genuinamente seu faz parte do mapeamento da superfície de ataque externa, e isso acontece antes de qualquer teste, não durante.

A lei por trás da linha

O motivo de sermos inflexíveis em relação a isso não é uma política interna. A maioria dos países trata o acesso não autorizado a um sistema de computação como um crime em si. Nos Estados Unidos é o Computer Fraud and Abuse Act; no Reino Unido, o Computer Misuse Act 1990; em toda a União Europeia, os estados-membros criminalizam o acesso ilegal sob leis nacionais que implementam a diretiva do bloco sobre ataques contra sistemas de informação. As especificidades variam de acordo com a jurisdição, mas o ponto central é o mesmo: o acesso sem a permissão do proprietário é a infração, e a intenção de ajudar não é uma defesa. Isso não é uma assessoria jurídica, e seu próprio advogado é a pessoa certa para ler a legislação aplicável a você. É simplesmente por isso que nem uma única requisição é enviada até que a autorização e a propriedade estejam consolidadas.

Por que somos rigorosos com a parte burocrática

Os clientes às vezes interpretam isso como burocracia. É o oposto. Uma autorização rigorosa é o que nos permite ser agressivos dentro da cerca sem que nenhum de nós se preocupe. Quando os limites estão documentados e assinados, podemos encadear ataques com força e provar o impacto real, porque todos já concordaram sobre onde estão as fronteiras.

As equipes que se queimam são aquelas que trataram o escopo como uma mera formalidade. Nós o tratamos como a base, porque ele realmente é.

Autorização em primeiro lugar: respostas rápidas

Preciso de autorização por escrito para testar sistemas que já possuo?

Na prática, sim. A autorização por escrito prova que sua própria equipe aprovou o teste, o que protege você internamente e protege o operador que o executa. Se qualquer parte do ambiente estiver em uma infraestrutura que você não controla totalmente, como uma plataforma em nuvem ou um produto SaaS hospedado, você também pode precisar da permissão desse provedor. Obtenha tudo por escrito antes que qualquer teste seja executado.

O que é um documento de regras de engajamento?

É o acordo escrito que define o teste: os alvos exatos no escopo, as técnicas permitidas e proibidas, a janela de testes, os contatos identificados de ambos os lados e as condições em que o teste é interrompido. Ele transforma um vago "venha nos testar" em algo que ambas as partes podem cobrar.

É ilegal escanear um site que eu não possuo?

Pode ser. Muitas jurisdições criminalizam o acesso não autorizado a sistemas de computação, e a fronteira entre um escaneamento e um acesso nem sempre está onde as pessoas imaginam. Sem autorização e prova de que você controla o alvo, não direcione nada a ele. Isso não é aconselhamento jurídico; consulte um advogado qualificado para a sua jurisdição.

Como vocês confirmam que eu sou dono de um alvo antes de testá-lo?

Geralmente por meio de um registro que solicitamos que você publique no DNS do alvo, ou de uma resposta de uma caixa de e-mail do próprio domínio. Ambos provam o controle de uma forma que um formulário web não consegue. Até que essa verificação seja concluída, nenhum projeto é iniciado.

Leituras relacionadas

• Verificação, escaneamento ou pentest completo?
• Como se preparar para o seu primeiro teste de intrusão
• O que OSCP, OSEP e CRTO realmente provam