One of the things we talk a lot about at Silent Push is the detection gap. The time between when an adversary gains access to an environment, and when our security tools would traditionally alert us to that. It is a problem I spend a lot of time discussing with customers, and the question is always the same: how do we actually start to build a more preemptive cyber program?
Traditionally, we tried to do this with threat intelligence and indicators of compromise. But the challenge was always that those are objects of the past. Things that already happened, that I can use to go hunting and see if I observed similar activity. That model has a ceiling. This post covers what we have built at Silent Push to push through it.
Why IOCs only get you so far
I want to be straightforward about this: threat intelligence and IOCs are not useless. They have real value for hunting historical activity and understanding adversary behavior. The problem is the timing. By the time an IOC reaches your tools, someone somewhere has already been compromised. That is baked into what an indicator of compromise actually is.
For phishing in particular, this matters a lot. Adversaries spin up new infrastructure fast, run a campaign, and move on before the IOCs from that campaign are widely shared. By the time those indicators reach your email gateway or firewall, the sites have often already done their damage and been abandoned.
The Core Limitation
IOCs are objects of the past. Things that already happened. They confirm what happened. They cannot tell you what is being built right now, and they cannot get ahead of a campaign that has not launched yet.
What we built instead: Indicators of Future Attack®
What we have built at Silent Push is what we call Indicators of Future Attack®. Almost a reverse engineering of an IOC. Instead of starting from a known-bad domain and working backwards, we want to understand the patterns that come along with the creation and management of adversary infrastructure, so we can identify it while it is still being stood up.
We do that by collecting data across DNS and our web scan content continuously. As we collect that, we can start to identify active infrastructure as it is being spun up and as it moves across different providers on the internet. The output is an IOFA feed: a continuously updated list of sites and infrastructure we have found that match adversary staging patterns, before any campaign has launched from them.
Indicator of Compromise (IOC)
Indicator of Future Attack (IOFA®)
A real example: Fake financial institution
Here is a concrete example. We have an IOFA feed built around a fake financial institution, a phishing site impersonating a real brand. One of the things I want to highlight here is that we are also seeing more of these new AI-generated sites, the kind that are convincing enough to end up in your users’ inboxes and look legitimate at a glance.
The site in this example is brand new as of today. Registered this morning. But it is already in our IOFA feed, which has been continuously discovering new sites like this over the last month, tracking them as they are created and adding them automatically.
We don’t want to have to respond to every phishing email. This is really what the indicators of future attack are going to allow us to do.
That is the shift. Instead of triaging phishing alerts one by one after they land in someone’s inbox, we are tracking the sites as they are created. The infrastructure is known before the campaign runs. That means we can act before the first email is sent.
Where you can put these feeds to work
IOFAs are things we can ingest directly into the security tools you are already using. Depending on what you want to get ahead of, that could mean proxies and firewalls to block staged infrastructure before a user ever requests it, email gateways to cut down on the phishing alerts your team has to triage, SOAR platforms to automate the block when a domain shows up in an IOFA feed, or your SIEM to enrich alerts with context on whether the infrastructure is already part of a known campaign.
Traffic Origin: That IP Address is not the full story!
The second thing I want to cover is Traffic Origin, because it solves a different problem from IOFAs but fits into the same goal of building a more preemptive program.
When I look up an IP address in a traditional workflow, I get a location and a reputation score. That is useful, but it only tells me where the IP is registered. It does not tell me where the person using it is actually located. Adversaries know this. They route traffic through residential proxy networks specifically so their sessions look like they are coming from a domestic IP address.
The Proxy Problem
An IP address located in the United States tells you where the traffic appears to be coming from. Traffic Origin tells you where it is actually coming from. Those two things are often not the same.
With Traffic Origin, we now have more detail on where someone is physically located when they use a given IP address. In this example, I have an IP that shows up as United States. But Traffic Origin also tells me it is part of a residential proxy network, and that the upstream origin of that traffic is somewhere else entirely.
How that changes what you do with the data
That context matters a lot depending on what workflow you are looking at. A few ways we see teams use it:
- For authentication workflows: if I see a login from a US IP but Traffic Origin tells me the upstream origin is a high-risk country, maybe I want to handle that differently. Require a second factor, hold the session, or block it depending on my policy.
- For applications and onboarding: an application comes in from what looks like a domestic address. Traffic Origin flags the upstream origin as somewhere unexpected. Maybe I want a second set of eyes on that before it moves forward.
- For KYC and compliance: for financial teams, a transaction from a US IP that is actually originating from a sanctioned country is a compliance issue, not just a security concern. Traffic Origin gives you something firm to make that call on.
- For insider risk: remote employees routing through proxies, or fraudulent hires running laptop farms, produce traffic that looks local. Traffic Origin identifies the upstream origin regardless of what the observed IP shows.
Bringing it into your SOAR
The last piece I want to walk through is how you actually operationalize this data inside your security stack. Let me take the phishing domain from earlier. If that domain triggered an alert or showed up in a phishing email I had to investigate, I can look it up directly in Silent Push from inside my SOAR platform.
I can see it is part of our IOFA feed. I can get additional details on the campaign. And then I can say: if it is part of a phishing campaign, I want to automatically push out a block for this. I do not want my users clicking that link. That playbook fires without anyone having to manually review and approve the block each time.
The same thing works on the identity side with Traffic Origin. I can correlate my Zoom logs with this data and easily identify users that are connecting through a specific proxy service, like AstralVPN. Instead of reviewing individual logins one at a time, I get a scoped list of sessions where the observed location does not match the upstream origin. That is something I can actually act on.
The whole platform is API-first and built on top of APIs that are all available to customers. There is nothing we can do in the platform that you cannot automate in your own environment. Native integrations, Splunk apps, and pre-built playbooks are available for common stacks. If you are building something custom, the full API gives you direct access to IOFA feeds, Traffic Origin, DNS enrichment, and infrastructure context without going through an intermediary layer.
What a preemptive program actually looks like
Everything I have covered here comes back to the same idea. We want to use the data and tools we have to start building up a risk-based program that gets us ahead of adversary infrastructure, rather than just responding to it after it lands.
IOFAs let you track phishing sites as they are being created and ingest them into the tools that can block them before a campaign launches. Traffic Origin gives you context on where users are actually connecting from, not just where their IP is registered. SOAR integration lets you automate the response to both, so your analysts are spending time on the things that actually need human judgment.
You do not need to replace what you already have. This is data you pull into the stack you are already running and use it to get upstream of the problem.
Want to put this into practice?
We put together a blueprint specifically for SOC teams. It covers how IOFAs surface attacker infrastructure before staging completes, a 30-60-90 day checklist to get there without replacing your stack, and real attack case studies where IOFAs caught live campaigns before they hit blocklists.
What is the detection gap?
The detection gap is the time between when an adversary gains access to an environment and when your security tools would traditionally alert you to it. Most tools only surface a threat after it has made contact with your environment. That means by the time you know about it, you are already behind. Building a preemptive program is about closing that gap before the alert fires, not after.
How are IOFAs different from IOCs?
IOCs are objects of the past. They are things that already happened that you can use to go hunting and see if you observed similar activity. IOFAs are almost the reverse of that. Instead of starting from a known-bad indicator, we identify the patterns that come with the creation and management of adversary infrastructure, so we can surface it while it is still being staged. IOFAs give you something to act on before the campaign launches, not after the first user clicks.
What does Traffic Origin actually tell me?
Traffic Origin tells you where someone is physically located when they use a given IP address. Standard GeoIP only shows you where the IP is registered, which is the last visible hop. If someone is routing through a residential proxy, their traffic looks like it is coming from wherever that proxy is located. Traffic Origin looks past that and gives you details on the actual upstream origin of the connection. That is the context you need to make a real risk decision on a login, an application, or a transaction.
Can I integrate this with my SOAR?
Yes. The whole platform is API-first and built on top of APIs that are all available to customers. There is nothing we can do in the platform that you cannot automate in your own environment. We have native integrations, Splunk apps, and pre-built playbooks for common stacks. If you are building something custom, the full API gives you direct access to IOFA feeds, Traffic Origin data, and DNS enrichment without going through an intermediary layer.
How does Silent Push find phishing sites before they send any emails?
We are continuously collecting data across DNS and our web scan content. As we collect that, we can identify active infrastructure as it is being spun up and as it moves across different providers. We are looking for the patterns that come with adversary staging activity, not just known-bad domains. That means we can add a site to an IOFA feed on the day it is registered, before it has ever been used to send a phishing email or harvest credentials.
What about AI-generated phishing pages?
We are seeing more of those. The pages themselves are more convincing now, but they still need real infrastructure behind them. They still get registered, hosted, and managed, and that process leaves the same kind of patterns we are tracking. We are not evaluating the visual quality of the page. We are looking at how the infrastructure was created and how it is being managed. That holds regardless of how the page itself was generated.
