Inside a Threat Emulation: The attack vectors Strike actually tests

At Strike, a Threat Emulation isn't one technique run against different targets, it's a combination of vectors, chosen based on what's realistic for that organization's attack surface. Some weeks that looks like probing an API for broken access control. Others, it's a phishing pretext aimed at a finance team, or a malicious file dropped to see whether an EDR actually catches it before it executes. The point was never to pick the flashiest technique. It was to look like whatever an actual attacker would try first.

The application layer is still where most of the work happens

Web apps and APIs remain the most common entry point, so that's where the bulk of every Threat Emulation Strike runs actually lives: authentication flaws, broken access control, IDOR, injection, the usual OWASP Top 10 territory, but tested against the real architecture of each app, SPAs, GraphQL, whatever auth scheme is actually in place, not a generic payload list. A login flow behind 2FA doesn't stop the test; it's part of what gets validated.

People are part of the attack surface too

A perfectly hardened API doesn't help if someone on the finance team clicks the wrong link. Strike's Red Teaming engagements exist for exactly that gap: social engineering exercises, phishing pretexts, and identity abuse scenarios that live outside the codebase entirely. It's less about proving someone can be fooled, that's rarely in question, and more about measuring how the organization notices and responds when it happens.

And yes, malware

It doesn't come up in every conversation about offensive security, but it's part of what we run: simulating what happens when a malicious file makes it past the front door. Not to prove that a file can slip through, that's almost never the interesting part, but to see whether detection and response actually catch it, and how long that takes.

Why the vector is the easy part

None of this matters much if it stops at "we found something." A finding without validated exploitability is a guess with good formatting. That's why at Strike nothing reaches a client until it's been checked for real impact, scored, and mapped to what actually matters for their business.

In practice that means every finding, regardless of which vector produced it, carries a severity score, gets ranked against the others by real business impact rather than a raw number, and lands in a report built to hold up against the framework a client actually answers to, whether that's PCI DSS, SOC 2, or ISO 27001. Remediation steps come with it, so a team can act the same day instead of scheduling a meeting to figure out what it means.

That's the part that's harder to shortcut than the attack itself.

‍

Curious what this looks like against your own environment? Book a demo.

‍