Pre-Attack Indicators: Identifying Threats Before They're Used

Connected servers and infrastructure nodes across a dark world map.

A lot of threat intelligence is derived from attacks that have already happened. Malicious IP addresses, domains, file hashes and other indicators are collected during investigations, shared through threat intelligence feeds and used to detect or block subsequent activity.

There’s nothing wrong with that. Indicators of Compromise (IOCs) are useful for understanding what happened, identifying related activity and protecting against infrastructure that might be used again.

But what if we could identify the infrastructure an attacker was preparing to use before an attack had even taken place?

That’s what we’re interested in at Lab539, and why we’ve started using the term Pre-Attack Indicators (PAIs).

Rather than relying entirely on evidence collected during or after attacks, we’re looking for observable evidence of adversary preparation. In some cases, that gives us an opportunity to act before the infrastructure has been used against anyone.

What is a Pre-Attack Indicator?

At Lab539, we use the following definition:

A Pre-Attack Indicator is an observable artefact or activity confidently associated with adversary preparation, identified before there is evidence of its operational use in an attack.

We’re deliberately quite specific about that definition because loose use of the term can degrade its value.

A newly registered domain isn’t automatically a Pre-Attack Indicator. Neither is an IP address hosted by a provider frequently used by cybercriminals. Those things might warrant investigation, or be afforded a lower reputation, but they’re not sufficient evidence of adversarial activity.

We need something that links the infrastructure to the preparation of an attack. That could be characteristics associated with a particular attack framework, infrastructure relationships connected to an existing campaign, or configuration and behavioural characteristics that allow us to identify a malicious service.

And we need enough confidence in that assessment to do something useful with the intelligence.

A PAI also isn’t a prediction that an attack will definitely happen. Infrastructure gets abandoned, campaigns change and attackers make mistakes. We’ve identified evidence of preparation, but that doesn’t necessarily tell us whether, when or against whom the infrastructure will eventually be used.

How does this differ from an Indicator of Compromise?

IOCs have been a central part of security operations for years. They’re useful for investigations, identifying related activity and preventing the reuse of known malicious infrastructure.

The criticism often directed at them is that they’re too easy for attackers to change. An IP address can be replaced, a new domain registered or a server moved to another provider.

That’s true, but an IOC derived from yesterday’s attack isn’t somehow a bad IOC because the attacker moves somewhere else today. It still accurately describes infrastructure associated with the attack.

The problem comes when we expect intelligence collected after an attack to reliably prevent the next one.

Pre-Attack Indicators describe evidence collected at an earlier point in the attack lifecycle.

	Indicator of Compromise (IOC)	Pre-Attack Indicator (PAI)
Evidence	Associated with known malicious activity	Associated with adversary preparation
Discovery	Often during or after malicious activity	Before evidence of operational use
Typical use	Investigation, detection and blocking	Early warning, disruption and prevention
Example	An IP address recovered from an AiTM attack	An IP address identified during deployment of an AiTM proxy before it is actively used

The same IP address could be a PAI on Monday and an IOC on Tuesday.

Perhaps we identify an AiTM proxy while it’s being prepared, then observe an attacker using that same server in a phishing campaign the following day. The infrastructure hasn’t changed. We simply have additional evidence about its operational use.

We’re not suggesting that PAIs replace IOCs, or that the industry needs to abandon its existing terminology. We find it useful to distinguish intelligence about adversary preparation from intelligence obtained through observing attacks.

Looking for evidence of preparation

Attacks typically involve a considerable amount of work before anything reaches a victim.

Depending on the type of attack, an adversary might need to register domains, configure DNS, provision servers, obtain certificates, deploy software, establish command-and-control infrastructure or connect different components of an operation.

Some of that work leaves traces that can be observed externally.

At Lab539, we describe the attack lifecycle in three stages:

Preparation: Developing and assembling the infrastructure, tooling and capabilities required for an operation.
Positioning: Deploying those capabilities and putting them in a position where they can be used against a target.
Execution: Using those capabilities to carry out the attack.

Security monitoring tends to concentrate on execution and what happens afterwards. But there’s often an opportunity to investigate what an attacker is doing during preparation and positioning.

For infrastructure-based threats, that might involve examining:

Domain registrations, DNS configurations and hosting relationships.
TLS certificates and other service configuration characteristics.
Software fingerprints and behavioural characteristics of deployed services.
Connections between new infrastructure and previously investigated campaigns.
Patterns in the way an adversary provisions, configures and operates infrastructure.

A particular nameserver, hosting provider or certificate characteristic might be entirely unremarkable in isolation. However, combinations of characteristics can be far more revealing, particularly when they’re supported by previous investigations and an understanding of how a particular attack framework or adversary operates.

Some infrastructure can be identified with a high degree of confidence before we have evidence of it being used against a victim and that’s exactly what we’re interested in.

The detection logic is the detector

One of the criticisms of IP and domain-based intelligence is that attackers can simply move their infrastructure.

They can, and they do. But that criticism tends to focus entirely on the indicator itself, overlooking how the indicator was discovered.

Imagine we’ve identified a combination of DNS behaviour, certificate characteristics, hosting configurations and software fingerprints associated with a particular type of adversarial infrastructure.

That combination might allow us to identify new instances of the infrastructure as they’re provisioned.

The investigation and detection logic could be quite sophisticated. It might involve collecting and correlating information from multiple sources, following infrastructure relationships and validating suspected systems.

But the organisation consuming the intelligence doesn’t necessarily need to understand or reproduce all of that work.

It needs something it can act on.

That might simply be an IP address identified, with high confidence, as an AiTM proxy being prepared for operational use.

The detection logic is the detector; the Pre-Attack Indicator is its actionable output.

And if the attacker changes infrastructure, the same investigative methods may reveal its replacement.

We’re not claiming that every replacement will be found, or that attackers can’t adapt their techniques to make discovery harder.

The value comes from continually identifying infrastructure early enough that defenders have an opportunity to act.

An example: Adversary-in-the-Middle phishing

Our AiTM Feed provides a practical example of how this works. Our guide to preventing AiTM phishing explains how infrastructure intelligence fits alongside phishing-resistant MFA and other controls.

Adversary-in-the-Middle (AiTM) phishing allows attackers to compromise accounts protected by conventional multi-factor authentication.

The attacker uses a reverse proxy to relay authentication between the victim and a legitimate identity provider, such as Microsoft Entra ID. The victim completes a genuine authentication process, but the attacker can capture the resulting authenticated session.

Much of the industry’s defence against this type of attack concentrates on preventing users from visiting phishing websites.

That’s useful, but those websites are only the delivery mechanism.

The attacker also needs infrastructure to communicate with the legitimate identity provider and carry out the authentication.

At Lab539, we hunt that backend infrastructure.

We’ve found that attackers often reuse backend systems across multiple phishing domains and campaigns. While phishing frontends can be disposable, the backend infrastructure provides another opportunity to identify and disrupt the operation.

In some cases, we can identify those systems while they’re being prepared, before we’ve observed them being used in an attack.

An IP address identified through that process becomes a Pre-Attack Indicator when the evidence supports a high-confidence assessment that it’s being prepared for adversarial use.

And because the attacker needs to communicate with the identity provider, that IP address gives us something we can block.

Turning the intelligence into prevention

Microsoft Entra ID allows organisations to configure Conditional Access policies that reject sign-ins originating from specified network locations.

Our AiTM Feed supplies intelligence about identified AiTM infrastructure, which customers can synchronise with those controls.

If an attacker attempts to authenticate through an identified proxy, Conditional Access can reject the sign-in before the attacker obtains a usable authenticated session.

The phishing email might still reach the user. The phishing website might not be detected as malicious. The user might even enter their credentials.

But the authentication doesn’t have to succeed.

We’ve documented an example of this in our AiTM Non-Incident Report, where an authentication attempt was blocked using intelligence supplied by Lab539.

The intelligence doesn’t have to be derived from a previous attack against that customer. In cases where we’ve discovered the infrastructure early enough, the block can already be in place before the customer encounters it.

This is also why we put so much effort into identifying backend infrastructure rather than relying exclusively on the phishing websites that users encounter.

Why not just block everything suspicious?

Because there’s a considerable difference between infrastructure that looks suspicious and infrastructure we can confidently associate with malicious activity.

A newly registered domain might belong to a legitimate business. A server running a particular application might be entirely benign. An IP address might host services belonging to multiple unrelated organisations.

There are plenty of characteristics that can help prioritise investigations without being sufficient justification for a block.

In our AiTM research, we spend a lot of time establishing whether infrastructure is genuinely associated with adversarial activity.

We’re not simply collecting newly registered domains, identifying unpopular hosting providers or assigning reputation scores to things that look unusual.

That sort of information can be useful for hunting, but it doesn’t automatically become a Pre-Attack Indicator.

For us, the classification requires evidence of adversary preparation and sufficient confidence in the assessment.

That standard becomes especially important when the intelligence is going to be used for automated enforcement.

Making Pre-Attack Indicators useful to defenders

Finding infrastructure is only part of the work. The intelligence also needs to be delivered in a form that organisations can use.

An IP address associated with an AiTM backend proxy might be suitable for blocking at the identity provider.

A domain associated with malicious delivery infrastructure might be more useful in protective DNS or web filtering.

Other indicators might be suitable for monitoring or further investigation, but not for blocking.

The action depends on what the infrastructure does, how confident we are in the assessment and what controls the organisation has available.

Useful intelligence should provide enough context to answer some basic questions:

What have we identified? An IP address, domain, service or other observable artefact.
Why do we believe it’s malicious? The evidence connecting it to adversary preparation.
What role does it play? Is it a phishing frontend, authentication proxy, command-and-control server or something else?
How confident are we? Is the evidence sufficient to justify blocking, or should the indicator be investigated further?
When was it observed? Has it become operational, is it still active, and when was it last seen?
What should defenders do with it? Block, monitor, investigate or take some other action.

There’s also ongoing maintenance to consider.

Infrastructure gets repurposed, IP addresses are reassigned and an assessment that justified blocking something last week might no longer be valid today.

Indicators need to be reassessed and removed when appropriate.

Poorly maintained intelligence can cause problems of its own, particularly when it’s used to make automated blocking decisions.

What about short-lived indicators?

A lot of the debate around indicator-based security seems to assume that an indicator needs to remain useful for weeks or months to have any value.

We don’t think that’s a particularly helpful way of looking at it.

Consider an IP address used by an attacker for just 24 hours.

If we identify it three days after the attack, it might be useful for investigating what happened, but it probably won’t prevent that particular attack.

If we identify it six hours before the campaign begins, and get it into the relevant preventative controls, it could stop the attack from succeeding.

Exactly the same IP address, with exactly the same operational lifetime.

The difference is when the intelligence becomes available.

Obviously, an attacker could move to another IP address. But that doesn’t undo an attack we’ve already prevented, and it doesn’t mean we can’t identify the new infrastructure too.

We’re interested in the capability to discover adversary infrastructure continuously, rather than relying on an ever-growing collection of historical indicators.

Some of the most valuable intelligence we produce may only remain relevant for a relatively short period.

If it arrives before the attack, that can be enough.

The limitations of Pre-Attack Indicators

There are plenty of attacks where identifying infrastructure in advance is difficult or impossible.

Some attackers use compromised legitimate systems, residential proxies, shared infrastructure or services provisioned shortly before use.

Others deliberately minimise the traces they leave while preparing an operation.

And even where infrastructure is observable, we won’t necessarily discover every instance.

Finding a Pre-Attack Indicator also doesn’t necessarily tell us that an attack is inevitable, when it might happen or who will be targeted.

Nor does identifying something as malicious automatically mean blocking it is appropriate. Shared infrastructure, limited confidence or the potential impact on legitimate services might make monitoring a better option.

Pre-Attack Indicators won’t replace phishing-resistant authentication, endpoint security, vulnerability management or incident response.

But where adversaries are building and operating infrastructure that we can identify, there’s an opportunity to interfere with their operations before an attack succeeds.

It’s an opportunity we think deserves considerably more attention.

Finding the infrastructure before the attack

The security industry has invested heavily in identifying malicious activity and responding quickly when something goes wrong.

That work is necessary, and it will remain necessary.

But attackers frequently have to prepare and position their infrastructure before they can use it.

We can investigate some of that preparation. We can recognise infrastructure being assembled for malicious purposes. And, when we have sufficient confidence, we can provide defenders with indicators they can act on before the infrastructure is used.

That’s what we mean by Pre-Attack Indicators.

We’re not trying to predict every attack. We’re trying to identify the infrastructure attackers are preparing, understand what it does and make that knowledge useful to defenders.

The earlier we discover it, the more options we have to interfere with the attack.

And if we can prevent an attack from succeeding, that’s a better outcome than having to investigate it afterwards.