O que é um vetor de ataque? Entenda a relação com a superfície de ataque

Entenda o que é um vetor de ataque, como ele se relaciona com a superfície de ataque e por que conectar exposições ajuda a identificar possíveis caminhos de ataque.

PorLeonnes Cybersecurity | 25 de agosto de 2026

Lion Focus — ativos expostos e serviços publicados na superfície de ataque

Durante o mapeamento da superfície de ataque aparece um subdomínio que não estava no inventário. Ele responde e leva a uma aplicação antiga, cuja tecnologia pode ser identificada externamente e possui uma vulnerabilidade conhecida para aquela versão.

Até aqui, é uma situação relativamente comum em análises de exposição. Temos um ativo que não estava sendo acompanhado, uma aplicação acessível pela Internet e uma vulnerabilidade que precisa ser analisada. A questão passa a ser: Como um atacante poderia utilizar essa exposição para tentar obter acesso ou avançar sobre o ambiente?

É nesse momento que o conceito de vetor de ataque começa a fazer sentido.

Superfície de ataque e vetor de ataque não são a mesma coisa

Os dois conceitos estão relacionados, mas representam coisas diferentes. Quando falamos de superfície de ataque, estamos olhando para os ativos e pontos que podem ser encontrados ou alcançados, como aplicações, IPs, serviços, APIs, ambientes cloud e outros recursos expostos. Um vetor de ataque representa uma possível forma de utilizar algum desses pontos para tentar comprometer um sistema ou obter acesso. O OWASP utiliza o termo attack vector para representar o caminho que um atacante pode percorrer para explorar uma vulnerabilidade.

No exemplo da aplicação antiga, o subdomínio e a aplicação fazem parte da superfície de ataque. Se a vulnerabilidade identificada puder ser explorada remotamente, começamos a enxergar um possível vetor:

Internet → Aplicação exposta → Vulnerabilidade → Acesso

A investigação, porém, dificilmente precisa parar na primeira descoberta. Ao analisar a aplicação, encontramos uma referência a uma API e, procurando informações relacionadas, aparece também um repositório público com documentação antiga dessa integração e um secret aparentemente utilizado para acessá-la.

O subdomínio, a aplicação, a vulnerabilidade, a API, o repositório e o secret poderiam ter sido identificados por ferramentas diferentes e registrados como findings independentes. Para quem está analisando o ambiente de uma perspectiva ofensiva, interessa entender se existe alguma relação entre eles. Talvez a vulnerabilidade da aplicação permita obter acesso; talvez o secret encontrado no repositório ainda funcione e permita autenticação diretamente na API; ou talvez nenhuma das duas possibilidades seja viável. Nesse momento, ainda estamos investigando.

Nem sempre existe uma vulnerabilidade no início do caminho

Quando pensamos em um ataque, é natural associar o ponto de entrada a uma vulnerabilidade, principalmente porque CVEs, exploits e software desatualizado fazem parte da rotina de segurança. Na prática, porém, existem outros caminhos. Uma credencial corporativa vazada pode permitir acesso a um serviço publicado na Internet sem que seja necessário explorar software algum. Um secret exposto pode permitir autenticação em uma API, enquanto uma configuração inadequada em cloud pode tornar determinados recursos acessíveis de uma forma que não deveria. Phishing e outras técnicas de Engenharia Social também podem ser o início de um ataque.

A CISA utiliza o conceito de initial attack vector durante a investigação de incidentes para entender como o adversário conseguiu o primeiro acesso ao ambiente. No nosso exemplo, se o secret encontrado no repositório ainda estiver válido e puder ser utilizado na API, talvez o atacante nem precise explorar a vulnerabilidade que chamou nossa atenção inicialmente.

Durante uma análise, é relativamente comum começarmos investigando uma exposição e encontrarmos informações que apontam para outra. Às vezes o caminho termina rapidamente; em outras situações, uma descoberta aparentemente secundária acaba sendo mais interessante do que aquela que iniciou a investigação.

Podemos imaginar que o nosso cenário evoluiu desta forma:

Subdomínio → Aplicação → API → Secret → Acesso

Se o acesso obtido permitir alcançar outro recurso, a análise pode continuar. Nesse ponto nos aproximamos do conceito de attack path, no qual diferentes condições e acessos formam um caminho entre o ponto inicial e outros recursos do ambiente. Não precisamos, entretanto, transformar cada conjunto de findings em um grande caminho de ataque. Muitas vezes ele simplesmente não existe. O importante é não assumir que as exposições encontradas precisam ser analisadas sempre de maneira isolada.

Encontrar uma relação entre exposições ainda não prova o ataque

Voltemos ao cenário anterior. Encontramos o subdomínio, identificamos a aplicação e sua API e descobrimos um secret em um repositório público. Existe uma relação interessante entre essas informações, mas ainda não sabemos se o caminho funciona. O secret pode ter sido revogado há meses, a API pode exigir outro mecanismo de autenticação, a vulnerabilidade identificada na aplicação pode não ser explorável naquela configuração específica ou podem existir controles que impeçam o avanço para outros recursos.

A validação ajuda a separar uma hipótese tecnicamente possível de uma exposição que apresenta evidências mais concretas. Dependendo da situação, isso pode envolver confirmar se um serviço realmente está acessível, verificar determinadas condições técnicas, analisar se uma credencial ainda possui relevância ou realizar uma avaliação ofensiva mais aprofundada.

O objetivo não é explorar tudo o que aparece; na maioria das vezes, isso nem faria sentido. Queremos reduzir a incerteza suficiente para entender melhor quais exposições merecem atenção. Se temos, por exemplo, duas vulnerabilidades classificadas como críticas e uma terceira de severidade alta, as críticas naturalmente aparecem primeiro quando olhamos apenas para a classificação. Mas, se a vulnerabilidade de severidade alta estiver em uma aplicação exposta à Internet e fizer parte de um caminho que conseguimos relacionar com outras exposições, essa informação pode alterar a prioridade da análise. A severidade não mudou; mudou aquilo que sabemos sobre a exposição.

Da superfície de ataque ao possível caminho

Superfície de ataque e vetor de ataque funcionam melhor quando analisados em conjunto. O primeiro conceito ajuda a entender onde estão os pontos expostos; o segundo nos aproxima da forma como esses pontos poderiam ser utilizados.

Em uma organização com muitos ativos, um discovery pode encontrar dezenas de subdomínios, aplicações e serviços, enquanto outras fontes trazem vulnerabilidades, credenciais vazadas, secrets, informações públicas e configurações inadequadas. Se cada descoberta permanecer isolada, teremos um inventário de exposições. Quando começamos a estabelecer relações entre algumas delas, passamos a enxergar possíveis caminhos.

Nem todos serão relevantes e muitos deixarão de fazer sentido assim que forem analisados com mais profundidade. Outros podem indicar que uma exposição aparentemente simples merece mais atenção do que parecia inicialmente. Pensar em vetores aproxima a gestão de exposição da perspectiva ofensiva porque, em vez de perguntar apenas o que está publicado ou quais vulnerabilidades existem, começamos a considerar outra pergunta: Se eu estivesse tentando entrar, por onde começaria?

A resposta pode estar em uma vulnerabilidade conhecida, mas também naquela credencial vazada, em um secret esquecido em um repositório ou em uma aplicação que ninguém lembrava que continuava publicada. Para um atacante, encontrar um ativo raramente é o objetivo; é apenas o lugar por onde ele começa.