Cybersecurity has relied on Indicators of Compromise (IOCs) for years, but there has also been a growing amount of criticism of them.
The usual argument is that IOCs are too easy for attackers to change. An IP address can be replaced, a new domain can be registered and infrastructure can be moved somewhere else, so blocking what an attacker used yesterday may have limited value tomorrow.
That criticism is understandable, but we think it slightly misses the point of what an IOC actually is. An Indicator of Compromise is exactly that: an indicator that something has been associated with a compromise or attack. A malicious IP address recovered from an incident does not somehow become a bad IOC because the attacker moves somewhere else the following day; it still accurately describes what happened.
The problem comes when we take that IOC and try to use it for a different purpose - predicting or preventing the attacker's next move - and then criticise it because it doesn't do that reliably.
In many ways, people making that criticism have reached the same conclusion we have. If we want indicators that are useful before an attack, rather than indicators derived from one afterwards, we need to treat those as a different thing.
At Lab539 we're going to refer to those as Pre-Attack Indicators, or PAIs.
A lot of our research already happens at that earlier stage. We look for infrastructure while it is being assembled: domains being registered, DNS configured, certificates issued, servers provisioned and infrastructure linked together. In some cases we can identify adversarial infrastructure before it has ever been used against a victim.
Calling those things IOCs has never felt quite right, because there may not yet have been a compromise at all.
What is a Pre-Attack Indicator?
Our working definition is:
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.
A PAI isn't a prediction that an attack will definitely happen. Infrastructure gets abandoned, campaigns change and attackers make mistakes. It is evidence that an adversary is preparing the capability to attack.
The terminology itself isn't new, which is another reason we like it.
Physical security and counter-terrorism have used "pre-attack indicators" for years. The UK's National Protective Security Authority, for example, uses the term for observable signs that might provide warning of preparation for a terrorist attack.
There is already some use in cybersecurity too. Searchlight Cyber talks about monitoring "pre-attack indicators" including attacker activity and infrastructure, while Intel 471 has used the term when discussing intelligence that can provide warning before an organisation is attacked.
So we're using an existing term because it describes something we increasingly need to differentiate from post-event indicators.
What this looks like in practice
Our AiTM Feed is probably the clearest example.
Lab539 identifies backend infrastructure associated with Adversary-in-the-Middle attacks, and we aim to identify and block that infrastructure before it has been weaponised against users.
It is difficult to describe the address as an Indicator of Compromise because there may not have been a compromise; the infrastructure probably hasn't even been involved in an attack yet. What we have instead is infrastructure that we have identified, with a high degree of confidence, as being associated with adversarial AiTM activity before operational use.
That is a Pre-Attack Indicator.
An IP address can therefore be a PAI on Monday and an IOC on Tuesday. The infrastructure itself may not have changed; what has changed is where it sits in the attack lifecycle and what we know about how it is being used.
The indicator can change and still be valuable
Pre-Attack Indicators don't somehow solve the problem of ephemeral infrastructure. An attacker can still move to another IP address, register another domain or change hosting providers. The difference is when the indicator becomes useful.
If an attacker is preparing an AiTM proxy today and we identify the IP address before their campaign starts tomorrow, the fact that they could move it elsewhere next week doesn't reduce the value of knowing about it today.
The key part is often the method used to find that infrastructure. A hunter might identify a combination of domain-registration behaviour, DNS configuration, certificates, hosting characteristics, particular technology signatures and other attributes. Those patterns can continue to reveal new infrastructure even as the individual domains and IP addresses change.
The detection logic is the detector; the PAI is its actionable output.
It isn't particularly helpful to tell every defender to look for domains registered through a particular registrar, using particular nameservers, with a certain certificate pattern and a collection of other correlated characteristics. How do they actually apply that logic within their environments? That's the challenge for hunters to solve if the output is going to be useful and actionable.
Useful output for a defender might be that a specific set of IP addresses has been identified, with high confidence, as AiTM proxy infrastructure being prepared for operational use. Blocking authentication from these IP addresses then becomes a worthwhile (and hopefully trivial) activity.
The indicators may still be short-lived, but short-lived intelligence can be extremely valuable when it arrives before the thing it describes becomes operational.
Suspicious isn't enough
There is an important quality point to make on this topic. Something like a newly registered domain is not automatically a Pre-Attack Indicator. It might deserve a lower reputation score than a ten-year-old domain, warrant additional scrutiny or share characteristics with malicious infrastructure, but low reputation and suspiciousness are not the same thing as intelligence showing adversary preparation.
In our case everything that enters our AiTM Feed has been identified, with a high degree of confidence, as infrastructure involved in AiTM-related adversarial activity. We are not simply collecting things that look suspicious and calling them Pre-Attack Indicators.
Without that distinction, PAI just becomes another way of saying "things that might be bad", which doesn't give a defender enough information to make a useful decision.
Context matters
If something is being described as a Pre-Attack Indicator, there should also be enough context to explain why.
What activity links it to adversarial behaviour? What kind of attack is it associated with? How confident is that assessment? Has it already become operational and, most importantly, what is the intended defensive use?
That context changes what somebody can sensibly do with the indicator. A high-confidence AiTM proxy might reasonably be blocked at authentication, while a domain loosely associated with infrastructure used by an adversary might instead be something to monitor. Both may be useful intelligence, but they are not interchangeable.
For our own use of the term, quality and context are an important part of what makes something a PAI, rather than it simply being a large collection of low-confidence suspicious infrastructure.
If you're also working in the pre-attack space, that distinction may be useful. The difficult part isn't producing more indicators; it's producing indicators with enough confidence and context that somebody can actually do something with them.
Don't we already have IOFA?
There is already another term used for broadly the same idea: Indicators of Future Attack, or IOFA.
It is a useful description and one we hear regularly from people in the industry. Silent Push uses IOFA to describe domains and IP addresses identified before they have been fully deployed in an attack.
Whilst we're basically describing the same thing, the complication is that Silent Push has registered "Indicators of Future Attack" as a US trademark and has separately applied to register "IOFA" for its cybersecurity services.
We're not particularly interested in debating whether terminology like that should be trademarked. We just want terminology that we, our customers and other researchers can use without having to worry about whether somebody else considers it their intellectual property.
People already using IOFA will undoubtedly continue to do so. For our purposes, though, Pre-Attack Indicator describes what we're doing without that complication.
Why we're using PAI
Lab539 isn't claiming ownership of Pre-Attack Indicator, and we certainly aren't going to trademark it. Nor are we claiming to have invented the phrase; as the examples above show, it is already being used elsewhere in security.
PAI also means Publicly Available Information in parts of the intelligence community, so the acronym won't always be unambiguous. Where that matters, writing Pre-Attack Indicator in full is probably the sensible answer.
For us, the term works because it describes the thing we are actually trying to differentiate: intelligence about adversarial infrastructure before it is used in an attack, rather than intelligence derived from activity that has already happened.
That doesn't make IOCs any less useful. It just means they describe a different point in the lifecycle.
For the work we're doing before an attack takes place, Pre-Attack Indicator feels like a much better fit. If you're working in the same space, perhaps it will be useful terminology for you too.