How to authorize Strike's IPs

Many environments block traffic that does not come from known addresses. For testing to run without interruptions, you need to authorize the IPs Strike works from in advance. This practice is known as IP allowlisting (or whitelisting).

What Strike's IPs are

• 3.217.45.182/32

• 52.4.41.179/32

• 18.210.150.0/32

• 3.91.124.199/32

Where to authorize them

Add Strike's IPs to the allowlist of your firewalls, WAF, load balancers and any other access control for the assets you include in your Threat Emulations.

What happens if you don't authorize the IPs

If your access controls don't recognize Strike's IPs, testing traffic may be blocked or flagged as suspicious, and the run may not cover the full planned scope.

You can see this in the Pre-flight Check, the configuration validation Strike performs at the start of each run:

• Blocking: if Strike's traffic is blocked, the check cannot reach the asset and the run does not start. Authorize the IPs and click Retry.

• Limited: if there are partial limitations, for example filtering or rate limiting, the run still goes ahead, but coverage may be affected.

For more details, see How the Pre-flight Check works.

Frequently asked questions

Where do I need to add the IPs?

In every access control relevant to the assets you include in your Threat Emulations: firewalls, WAF, load balancers and any access list.

Are "whitelist" and "allowlist" the same thing?

Yes. Both terms refer to the same thing. Depending on the tool you use, the feature may appear as "allowlist" or "whitelist".

The Pre-flight Check flagged an access issue. What do I do?

Check that all four Strike IPs are authorized in all your access controls. Once you've fixed it, click Retry from the Threat Emulation or from the asset panel.

What if my asset is only accessible through VPN?

In addition to authorizing the IPs, you need to configure VPN access. For more details, see Requirements for an effective Threat Emulation.