Dentro de uma Threat Emulation: os vetores de ataque que a Strike testa

Na Strike, uma Threat Emulation não é uma única técnica executada contra alvos diferentes, é uma combinação de vetores, escolhidos de acordo com o que é realista para a superfície de ataque de cada organização. Em algumas semanas isso significa testar uma API em busca de falhas de controle de acesso. Em outras, é uma tentativa de phishing direcionada ao time financeiro, ou um arquivo malicioso enviado para ver se um EDR realmente o detecta antes que seja executado. O objetivo nunca foi escolher a técnica mais chamativa. Foi se parecer com o que um atacante de verdade tentaria primeiro.

A camada de aplicação ainda é onde acontece a maior parte do trabalho

Aplicações web e APIs continuam sendo o ponto de entrada mais comum, então é aí que vive a maior parte de cada Threat Emulation que a Strike executa: falhas de autenticação, controle de acesso quebrado, IDOR, injeções, o território habitual do OWASP Top 10, mas testado contra a arquitetura real de cada aplicação - SPAs, GraphQL, o esquema de autenticação que estiver realmente implementado, não uma lista genérica de payloads. Um fluxo de login protegido por 2FA não interrompe o teste, é parte do que é validado.

As pessoas também fazem parte da superfície de ataque

Uma API perfeitamente protegida não ajuda muito se alguém do time financeiro clicar no link errado. Os projetos de Red Teaming da Strike existem exatamente para esse ponto cego: exercícios de engenharia social, tentativas de phishing e cenários de abuso de identidade que vivem completamente fora do código. Não se trata tanto de provar que alguém pode ser enganado, isso raramente está em dúvida, mas de medir como a organização percebe e responde quando isso acontece.

E sim, malware também

Não aparece em toda conversa sobre segurança ofensiva, mas faz parte do que rodamos: simular o que acontece quando um arquivo malicioso passa pela primeira linha de defesa. Não para provar que um arquivo pode passar, isso quase nunca é a parte interessante, mas para ver se a detecção e resposta realmente o capturam, e quanto tempo isso leva.

Por que o vetor é a parte fácil

Nada disso importa muito se parar em "encontramos algo." Um achado sem exploração validada é um palpite bem formatado. Por isso, na Strike, nenhum achado chega a um cliente até que seu impacto real tenha sido verificado, pontuado e mapeado contra o que realmente importa para aquele negócio.

Na prática, isso significa que cada achado, não importa qual vetor o produziu, recebe uma pontuação de severidade, é priorizado em relação aos demais com base no impacto real para o negócio e não em um número bruto, e chega em um relatório construído para se sustentar diante do framework que aquele cliente realmente responde, seja PCI DSS, SOC 2 ou ISO 27001. Os passos de remediação vêm junto, para que o time possa agir no mesmo dia em vez de marcar uma reunião para entender o que aquilo significa.

Essa é a parte mais difícil de simplificar do que o próprio ataque.

Curioso para ver como isso se aplica ao seu ambiente? Agende uma demo.

‍