API-first offering now gives product and threat intelligence teams access to preemptive data that identifies adversary infrastructure before attacks begin
RESTON, Va., August 4, 2026 — Silent Push, the leader in preemptive cybersecurity intelligence, is expanding access to its proprietary first-party infrastructure intelligence platform, enabling cybersecurity companies to integrate the same data that powers Silent Push’s own threat detection and research capabilities directly into their products and workflows.
Unlike traditional threat intelligence that relies on indicators of compromise (IOCs) after an attack has occurred, Silent Push provides first-party infrastructure intelligence and Indicators of Future Attack® (IOFA) that identify adversary infrastructure while it is still being built, an average of 104 days before it is weaponized. This enables cybersecurity vendors to deliver earlier detection, richer context, and more proactive protection for their customers.
“Cybersecurity products are only as effective as the intelligence behind them,” said Ken Bagnall, CEO and Co-Founder at Silent Push. “Silent Push is giving security vendors access to the first-party infrastructure intelligence they need through flexible APIs and integrations, enabling them to move beyond reactive detection and instead build products that identify emerging threats before attacks begin.”
The offering is designed for both cybersecurity product and research teams and cyber threat intelligence (CTI) organizations seeking to enhance detection capabilities, accelerate research, and differentiate their offerings through exclusive infrastructure intelligence.
Key capabilities include:
Preemptive IOFA that identify malicious infrastructure months before attacks are launched.
API-first integration for enrichment, scoring, infrastructure context, bulk lookups, and automated security workflows.
MCP Server integration for AI-native and agentic security environments.
Historical DNS and WHOIS intelligence, behavioral fingerprinting, and Traffic Origin data to accelerate threat research and campaign analysis.
Custom intelligence feeds tailored to specific threat categories, geographies, or infrastructure patterns.
Supporting a Broad Range of Security Use Cases
Silent Push APIs enable security vendors and technology partners to build next-generation detection and investigation capabilities into their products, enrich existing threat intelligence platforms with continuously updated infrastructure data, and power published threat research with deterministic, first-party intelligence.
The platform also accelerates AI-assisted security operations and threat hunting while helping organizations identify lookalike domains, malicious infrastructure, and adversary activity before attacks occur, enabling a more proactive approach to cyber defense.
Silent Push offers flexible deployment options, including direct Data API access, MCP Server integration for AI workflows, full platform access for research teams, and customized intelligence feeds. The company already provides proprietary intelligence to cybersecurity organizations that use Silent Push data to enrich their products and power customer-facing threat intelligence offerings.
For more information about Silent Push’s cybersecurity company offering, visit www.silentpush.com or contact [email protected].
About Silent Push
Silent Push is the preemptive cyber defense company. It provides a complete view of emerging threat infrastructure in real time through its Indicators of Future Attack® data, enabling security teams to proactively block threats. The platform is also available via API and integrates with SIEM, XDR, SOAR, TIP, and OSINT tools. Customers include Fortune 500 companies and government agencies.
Start a conversation with one of our platform experts to see how our solutions, powered by the latest capabilities of the Context Graph, can help your team neutralize threats before attacks are fully launched.
In January 2026, the Silent Push research team mapped a cluster of adversary infrastructure staged for takeover of single sign-on accounts across more than 100 large organizations. Amgen was one of the named targets, grouped with other pharmaceutical and biotech companies.
On July 31, Amgen filed a Form 8-K with the SEC confirming that attackers had stolen patient protected health information and proprietary data from cloud environments run by its third-party vendors.
Seven months passed between the January infrastructure findings and Amgen’s July disclosure. That is enough time for a targeted organization to block the infrastructure, watch the named accounts, and tighten identity controls before an attack lands. In Amgen’s case, the disclosure came at the end of it.
Who is ShinyHunters, and who do they target?
ShinyHunters is a data theft and extortion group that operates as part of Scattered LAPSUS$ Hunters, an alliance that also includes Scattered Spider and LAPSUS$. The group gets in through social engineering, moves through connected cloud platforms, and uses the stolen data to pressure its victims into paying. Its focus is identity and SaaS access, which is what makes a single compromised SSO account so valuable to it.
The targets are large enterprises with heavy cloud footprints, the kind of organizations that run day-to-day operations through platforms like Salesforce, Microsoft 365, and SharePoint. The infrastructure behind this campaign has pointed at more than 100 such organizations across several industries, and recent activity has concentrated on healthcare, medical technology, and pharmaceutical companies. Amgen sits squarely in that profile.
What Silent Push saw in January
The Silent Push platform maps adversary infrastructure by watching for the setup work that happens before an attack, the domains a group registers, the certificates and hosting it stands up, and the tooling it stages while preparing to move against a target. We turn that activity into Indicators of Future Attack® (IOFA), which give a security team a named threat and a timeframe to act on before anything reaches their environment. In January, that work identified the Scattered LAPSUS$ Hunters campaign while it was still being built, months before any of it was used against a target.
In Silent Push research, the average lead time between spotting this kind of infrastructure and an attack landing is 154 days. In Amgen’s case, the public timeline ran to about seven months.
How the attack chain works
Health-ISAC, the information-sharing group for the healthcare sector, published an advisory on July 24 describing the pattern in detail. The short version is that the attack runs on social engineering aimed at a vendor’s helpdesk. Someone calls posing as internal IT and persuades a representative to reset multi-factor authentication on a chosen employee’s account. The weak point is the human process that verifies who is calling, so the attacker never has to defeat a technical control. That reset hands over a single signed-in session, and that session reaches the cloud apps the account can open. From there the group pulls data out of connected platforms before alerting catches up.
Amgen’s disclosure places the unauthorized activity in cloud environments run by third-party service providers, and the company reported no impact to its products, manufacturing operations, or financial reporting systems. The exposed records sat with outside vendors contracted to store and process patient data on Amgen’s behalf, in infrastructure Amgen does not run or directly monitor. An organization can operate a mature security program across its own estate and still inherit the risk carried by every vendor that holds its regulated data.
What is preemptive cyber defense?
Preemptive cyber defense means finding adversary infrastructure while it is being built and acting on it before it gets used in an attack. The signal for that work is an Indicator of Future Attack® (IOFA), which names a threat while it is still being staged, early enough for a team to respond. An Indicator of Compromise (IOC) is the older, well-known kind of signal, the forensic evidence collected after a breach that helps with investigation once the loss has already happened.
Silent Push maps the infrastructure a threat group stages against its targets and delivers it as IOFAs. That gives teams time to block domains, monitor key accounts, and harden identity controls while the attack is still being set up.
What security teams can do now
The Health-ISAC advisory lists controls that are procedural more than technical. The first control to adopt is a no-same-call rule, which stops a helpdesk from resetting a password, resetting MFA, or enrolling a new device on the same call that requests it. The request goes into a ticket and gets a callback to a number already on file for the account. That single step breaks the part of the chain the group relies on most.
For higher-risk accounts such as administrators, security staff, and finance employees, the advisory recommends a second approval and an out-of-band identity check before any credential change. It also points to phishing-resistant MFA such as FIDO2 keys or passkeys, which cannot be talked out of a person over the phone.
The point of seeing it early
Amgen is one company, and the pattern is common across the sector. A strong internal security program can still carry the risk of a vendor it can vet but cannot watch in real time. Spotting the infrastructure in January gives a targeted team the chance to act months before the attack lands. That is what ‘neutralize before compromise’ means in practice. It is the chance to move on a threat while it is still being built, before it reaches a patient’s data.
This post is commentary on public reporting and regulatory frameworks. It is not legal or compliance advice.
Did Silent Push predict the Amgen breach?
Silent Push did not predict a specific breach. In January 2026 the Silent Push team mapped adversary infrastructure staged for SSO account takeover and named Amgen among more than 100 targeted organizations. Amgen disclosed a breach of patient data held by third-party vendors on July 31, 2026. Amgen has not confirmed the threat actor, and no group has publicly claimed the attack, so the connection is a strong pattern match that stops short of confirmed attribution.
What is an Indicator of Future Attack?
An Indicator of Future Attack (IOFA) is a signal that identifies adversary infrastructure while it is being staged, before it is used in an attack. It gives a security team a named threat and a timeframe to act on in advance. An Indicator of Compromise is the related but later signal, the forensic evidence collected after a breach has already happened.
How did attackers reach Amgen’s data without breaching Amgen?
According to a July 24 Health-ISAC advisory, the group uses voice social engineering to get a vendor helpdesk to reset multi-factor authentication on an employee account. That opens a signed-in SSO session that reaches connected cloud apps, and the attackers pull data from those apps. The compromised systems belonged to Amgen’s third-party vendors, which is why Amgen’s own operations were unaffected while patient data was still exposed.
What is preemptive cyber defense?
Preemptive cyber defense is the practice of finding and acting on adversary infrastructure while it is being built, before it is used in an attack. Silent Push maps the infrastructure a threat group stages against its targets and delivers it as Indicators of Future Attack, so teams can block domains, monitor accounts, and harden identity controls during the planning window.
Silent Push Simulation Demonstrates Why Dangling DNS Domains Continue to Pose Global Threats
Key Findings
Our research team conducted a simulation examining dangling DNS infrastructure across four industry sectors: government, banking, automotive manufacturing, and pharmaceuticals.
We applied simple, agent-based instrumentation and AI workflows to find, enumerate, and uncover subdomains that could be exploited.
Using the same single technique over and over produced successful results, leading us to determine we were only scratching the surface of an immense scale of takeover possibilities.
There are billions of forgotten, abandoned, and misconfigured subdomains on the internet that point to nowhere. Seemingly harmless on the surface, they aren’t necessarily an imminent cyber threat warranting an immediate call to arms from analysts, agents, or defenders.
Looking at this “dangling DNS” infrastructure, the Silent Push research team asked a simple question: What if we looked at it the same way a trained nation-state attacker would?
And what if we simulated a scaled exploit of this “highly exploitable” infrastructure that the world has not yet seen? What would the impact be? How widespread could it become, and how quickly could a massive-scale takeover be possible?
Our analysts conducted this threat research initiative specifically against a sample group that included government and Fortune 500 companies, initially targeting Microsoft infrastructure. We named the project “Danglegeddon.”
Our Approach
Sample Size of Dangling DNS Infrastructure
We targeted 12,500 total domains as our initial infrastructure sample size. This represented a small sample of the total companies and infrastructure changes we see daily in the Silent Push data set. Silent Push selected into each target organization’s VDP (Vulnerability Disclosure Program)/BBP (Bug Bounty Program) programs and safe harbor for passive vulnerability testing.
Every record we observed was dangling and represented a liability for each company. However, among the 12,500 apex domains, we isolated 16,000 dangling subdomains and automated the takeover of 4,000 of them. There were 7,000 subdomains that required additional steps to determine whether they met the conditions for takeover. Upon review, 5,000 of those were safe due to the provider’s safeguard measures.
One Singular Technique: DNS Takeover
In this simulation, we exposed various DNS misconfigurations and broad cookie session scoping to allow credential harvesting and OAuth redirection from a successfully deployed phishing campaign, employing the singular technique of dangling DNS takeover, one of many techniques that’s been around for years and is well known in the industry.
Then, simple, agent-based instrumentation and AI workflows were applied to expand the range of DNS domains and subdomains, which proved to be a force multiplier for leveraging this technique at scale and at an accelerated pace across domain and subdomain discovery and enumeration.
Using AI to Accelerate
We continued to leverage AI’s ability to find, enumerate, and uncover subdomains as our research progressed.
The Claude model Opus 5 quickly enabled script generation after enriching the context with in-scope BBPs and the VDP. The process mapped the targets’ 12,500 domains to known vulnerable providers’ CNAMEs in EdOverflow’s Can-I-take-over-xyz GitHub project.
Using Silent Push’s Dangling DNS API, we further filtered to those resources that lacked allocation or DNS registration. This technique isolated several hundred domains that we further cross-validated against the providers for availability. Next, the process rapidly enabled the discovery of new registers and platforms that support customizable CNAMEs without DNS domain verification. After this discovery process, we were able to extract several unknown vulnerable providers.
Within hours, we had a fully developed takeover script to mass-exploit all vulnerable domains. As security providers, we are mindful of our legal exposure when conducting these investigations. Advanced threat actors could simply broaden to all resolvable domains in the beginning to start Dangleggedon in time for their morning coffee.
Exploitation of Vulnerable Conditions and Bad IT Hygiene
Most of the victim networks simply had old resource calls, receiving inbound referrals or XSS (cross-site scripting) directly from the corporate websites and scripts. This allowed the simulated attack not only to be possible but also to demonstrate that it could cut across any industry, any piece of dangling organizational infrastructure, anywhere in the world.
Employee attrition, merged infrastructure ownership (via M&A activity), and large-scale layoffs created highly exploitable conditions, making organizations even more vulnerable to exploitation when IT hygiene is not adhered to comprehensively and immediately during change control and employee termination processes.
Microsoft Infrastructure = Easiest, Most Accessible
Our work focused on Microsoft Azure Blobs, Azure VMs, Web Apps, APIs, and Power Pages instances as a starting point. As an initial sample size of real-world takeover in mission-critical industries, the team selected infrastructure in the Government, Banking, Pharma, and Automotive industries. It was clear that the same single technique, applied over and over, produced the same successful returns. At that point, we realized we were only scratching the surface of the scale of takeover possibilities.
The Impact
During our simulation, we examined organizations across various industry sectors, including Automotive, Banking/Financial, Energy, Government, Health Care, Pharmaceutical, Manufacturing, Transportation, Utilities, and beyond.
Government. Targeting a single U.S. federal government entity, using the techniques described above, we modeled the downstream effect if applied to all possible systems and accessible employee credentials using Microsoft infrastructure:
The immediate impact would affect thousands of systems and millions of employees, causing multiple disruptions:
The downstream impact, for example, in the Department of Defense (DoD), could affect its $66 billion budget.
With an estimated 31% of DOD infrastructure within the Federal government, the takeover could involve thousands of systems used by over 2 million employees.
Given the interdependence of departments and the documented cybersecurity oversight gap, the attack surface could grow monumentally.
A cascading attack could extend far beyond the DOD, involving different branches of the military and national security systems, with the potential impact on national security arguably being severe.
Banking. Targeting a large international bank with the same simulated action using the identical technique, the downstream modeling shows a potentially big impact on the broader banking industry, given the industry’s hyper-reliance on Microsoft infrastructure:
Azure serves as a cloud provider for an estimated 80+% of the world’s largest banks and 75+% of major financial institutions; a disruption could cause serious complications and potential panic.
Applied globally, these disruptions would affect high-performance risk modeling, secure data workloads, and the deployment of generative AI capabilities across multinational firms, including Bank of America, UBS, and the Bank of Montreal.
The downstream impact on the global financial sector would include paralysis of online banking and real-time payments, as well as the blocking of trading platforms. Customer account lockouts, transaction processing delays, and widespread communication breakdowns across institutions would be felt by global consumers.
Big Pharma. Targeting a global pharmaceutical organization, our downstream model projected an enormous takeover impact because so many pharmaceutical organizations use Azure Cloud.
An estimated 75% to 85% of major global pharmaceutical enterprises utilize Microsoft Azure for their operations. This means Fortune 500 companies in the sector, and non-Fortune 500 companies globally.
As an example, the 2017 NotPetya attack (estimated at $10 billion worldwide) on Merck downed 40,000 systems within minutes and caused reported losses of $1.4 billion, prompting pushback from insurers. In addition to outages and cascading issues, it also resulted in landmark insurance decisions that were drawn out over more than 10 years of litigation.
The speed of a takeover cascading into a magnitude involving multiple global pharma organizations would undermine high-performance R&D, disrupt clinical trials, and pose even more serious consequences for the supply chain necessary to deliver drug and therapeutic solutions on a global scale.
Estimated losses across organizations could be in the hundreds of billions.
Automotive. Targeting a Fortune 500 manufacturer, we successfully took over a subdomain from a historic American automotive company.
Historically, a single cyberattack on a top-tier automaker can cost billions and paralyze national supply chains within days.
The 2025 Jaguar Land Rover (JLR) cyberattack shut down production for five weeks, cost the company $350 million directly, and drove an estimated $2.5 billion in broader UK economic damage, impacting more than 5,000 supplier and dealer organizations and prompting an unprecedented government-backed loan to keep the supply chain solvent.
Disruption compounded fast and hit beyond the automaker: JLR’s shutdown was cited by the Bank of England as a factor in a UK GDP contraction that quarter, illustrating how a single manufacturer’s IT outage can ripple into national economic indicators, a dynamic that scales with how deeply operations, from production scheduling to supply-chain logistics, are impacted.
An attacker who was able to take over this automaker’s subdomain could:
Host malicious content and serve phishing pages, malware, or other malicious content under the legitimate car maker’s domain.
Cause reputational damage by abusing the trusted brand’s subdomain.
Steal user credentials to create convincing phishing pages that appear to be legitimate services.
Perform cookie theft and potentially steal session cookies if scoped to the parent domain.
Bypass security controls if the legitimate brand’s subdomain is whitelisted in security tools, allowing malicious content to bypass filters.
This vulnerability poses a significant security risk, as attackers can leverage the trust associated with the brand’s domain to carry out malicious activities.
Details on the Simulated Attack
As described in our AI research above, we checked the accounts in multiple ways to determine the best methods for taking over a domain. This workflow highlighted the key industries and government entities we feared were vulnerable due to turnover and infrastructure dependencies. All takeovers were disclosed responsibly.
In each instance, our researchers successfully took over the abandoned resource associated with the identified organization’s dangling DNS infrastructure. The organization then redirected its subdomain to our site to serve whatever content we wanted. For each of the organizations involved, we reached out to alert them of the exposed domain(s)/dangling DNS infrastructure through VDPs, among other methods.
Based on the vulnerable DNS infrastructure list we identified, we chose an organization from each sector and assessed its willingness to be tested. Our goal was to demonstrate that virtually any organization with dangling DNS infrastructure is vulnerable to a subdomain takeover.
A taken-over subdomain isn’t itself an intrusion; it’s a start, or a trusted launchpad. Because it inherits the parent organization’s reputation and can obtain a TLS certificate, an attacker typically uses it to host convincing phishing pages or credential-harvesting forms, or, in some misconfigured cases, to intercept shared session tokens directly.
From there, reaching internal systems or causing real operational disruption requires the organization to have made additional, separate mistakes beyond the dangling DNS record itself, such as weak multi-factor authentication, overly broad internal trust between systems, or third-party relationships that extend trust further than they should. The dangling DNS is the initial foothold, but the ultimate severity of impact depends on how many additional layers of security hygiene fail after that foothold is gained. Much of it depends on the location of the former valid device and the internal trust that the device the former DNS record pointed to remains in place.
Below is a breakdown of the simulation details, sector by sector.
HOW THE SILENT PUSH PLATFORM WAS APPLIED
Government Simulation
In this simulation, we selected a U.S. federal entity from our sample size. This organization was vulnerable because its DNS record pointed to an unassigned Azure Blob Storage resource.
After hosting the site, the nautical-themed subdomain can be seamlessly integrated into a spear-phishing topic. In addition to being hard to detect during human inspection, the domain can now bypass automated safeguards by leveraging the trust associated with .gov domains.
Banking Simulation
In our second sampling, we isolated a large French global bank. This company faced the same IT hygiene issue as its U.S. sibling. It had left an unassigned Azure Blob storage resource pointing to an application.
Automotive Manufacturing Simulation
Our third simulation is a beloved Fortune 500 U.S. automotive titan.
The company left a dangling DNS record pointing to a developmental application gateway hosted by an Azure virtual machine (VM). This device can potentially be operationalized and passively receive stored XSS from internal scripts and API calls.
Developer’s credentials, like API keys and authentication headers, could be harvested for reuse to expand access into the company. In addition, the VM could serve as a platform for malware hosting with the coveted TLS lock.
Pharmaceutical Simulation
A major pharmaceutical company we identified left a record pointing to an Apple device guide. This presented a strong thematic which could allow an attacker to focus on a specific set of targets and events.
As proof of the discovery process, we found an online publishing platform, Paperturn, that allowed for custom CNAME assignment. The platform can host and convert files such as PDFs.
Using the Platform: A Proactive Hunting Mechanism with AI Instrumentation
Claude excelled at bulk data summarization, coupled with our DNS dangling-records search.
Coupled with some simple availability checks to see if the resource could be taken over:
The hypothetical scenario of a Danglegeddon became a very real threat in minutes.
After clearing the context window and the agent team swapping in Claude, the automation of the infrastructure build-out was a simple task, bypassing any CVP flags and setting us one button away from Dangle Day.
An Analysis Engine to Inform Mitigations
Silent Push provides the insights you need to add this IT hygiene task to your Defender playbook in a simple, one-step process. After which, you can modify your DNS records and avoid a potential disaster.
Everything described so far was possible because of how the underlying data is collected. Most subdomain takeover hunting starts with a guess. An analyst picks a target, runs a wordlist against it, resolves what comes back, and checks whether any of the answers point at an unclaimed resource. That approach only finds hostnames someone thought to suggest, for the one organization being tested, and at the moment the scan runs.
Silent Push doesn’t guess. We re-resolve every hostname in our dataset every day. When a CNAME’s target stops resolving, when an MX host disappears, when a delegated name server goes quiet, we see the answer change the day it happens, across the entire namespace we observe rather than one target at a time. Dangling records surface as a byproduct of continuous resolution, rather than as a scan you have to launch.
That distinction matters more for defenders than for attackers. Records that get an organization compromised are the ones nobody remembers creating. They don’t appear in the CMDB, they weren’t in scope for the last pentest, and they belong to a team that reorganized two years ago. Asking an organization to scan its own infrastructure only finds what it already knows it owns. Our discovery process has no such dependency, which is why the 12,527 apex domains in this study yielded 85,254 raw dangling records and 16,544 rows worth reviewing.
Reading the Dangling DNS View
The screenshots below show the Dangling DNS tab inside Total View, our single-pane record for a domain. Note the tab strip across the top: PADNS, WHOIS, Certificates, Subdomains, and Threat Feeds. Dangling DNS sits beside them because it is one facet of the same record; anything found here pivots directly into passive DNS history, certificate issuance, and the rest of the organization’s footprint without leaving the page.
Two panels do the work.
The Dangling DNS Records Count chart buckets findings into “Danglers Unchanged,” “Danglers Added,” and “Danglers Removed,” with record type color-coded: teal for NS, blue for MX, and yellow for CNAME. Because we re-resolve daily, this is a change ledger rather than a snapshot. Unchanged is a standing exposure that has survived at least one collection cycle. Added is the new exposure created since the last one, which is the bar a defender should be alerting on. “Removed” shows records that were cleaned up or that stopped resolving entirely.
The Dangling DNS Record Details table below breaks out the same findings by type, with a count on each tab, and four columns per row. “Query” is the organization’s own hostname. “Answer” is where that hostname still points. “Foreign_target” marks the answer as internal or external, telling whether the broken pointer lands somewhere the organization still controls, or somewhere it does not. “External” is where takeover risk lives. “State” carries the same unchanged or removed status as the chart.
The volumes in these four screenshots are the point. A financial organization with 27 dangling CNAMEs and a dangling MX. An automotive manufacturer with 1,437 dangling CNAMEs on a single apex. A pharmaceutical company with 271, including the Paperturn record we used in the simulation. A federal agency with 221 dangling CNAMEs, 10 dangling MX records, and a dangling NS delegation, several of them pointing at unclaimed Azure Blob Storage. None of these organizations knew. Every one of them was reachable through a public disclosure channel.
Why CNAME, MX, and NS Each Carry a Different Kind of Risk
Dangling CNAME. The hostname still answers, but the service it aliases has been deprovisioned. Whoever claims the resource name at the provider inherits the hostname, the parent brand’s reputation, and, in most cases, a valid TLS certificate through automated domain validation. This is the condition we exploited in every simulation. It is also the most common by a wide margin, which is why the yellow bar dominates all four charts.
Dangling MX. Mail addressed to the domain is being routed to a host that no longer exists. Two consequences follow. Legitimate mail fails silently, including DMARC reports and anything routed through that exchanger. More seriously, an attacker who can claim or re-register that mail host receives inbound mail addressed to the organization. That means password reset links, invoices, vendor correspondence, and the email-based verification step that gates certificate issuance and account recovery at most providers.
Dangling NS. This is the worst of the three and the least common, which is exactly why it gets missed. A dangling NS record means a zone or subzone has been delegated to a name server that no longer answers, usually because a domain lapsed or a hosted DNS zone was deleted. Anyone who takes control of that name server controls the entire zone beneath it. Not one hostname: every hostname, plus the ability to create records that never existed, including A, MX, and the TXT records used for wildcard certificate validation. One dangling NS record can be worth more to an attacker than a thousand dangling CNAMEs.
What to Do About It
Work the record types in order of blast radius. NS first, then MX, then external CNAMEs, then internal.
For each record, the fix is to delete it from the authoritative zone. Re-point it only if the service behind it is genuinely still in use. Where a hostname is still referenced by live pages or scripts and the underlying resource is still claimable, reclaim the resource defensively first, then remove the reference and the record.
The process fix is a sequencing rule: the DNS record dies before the cloud resource does. Most of the exposure in this study results from teams deprovisioning a storage account, a web app, or a VM and leaving the record behind. Reversing that order in decommissioning runbooks eliminates the condition at the source.
Measures Going Beyond
Prefer providers that require domain ownership verification before accepting a custom hostname. In Azure, that means using a TXT verification record, such as asuid. The 4,925 records we found to be not claimable could be protected by exactly this kind of provider-side safeguard.
Assign an owner and a review date to every DNS record. Employee attrition, layoffs, and merged infrastructure ownership after M&A activity are what produce orphaned zones, and none of those events currently trigger a DNS review at most organizations.
Publish CAA records to restrict which certificate authorities can issue for your namespace, and monitor certificate transparency logs for issuance you did not request.
Audit any security control that allows lists by domain suffix/TLD. A subdomain taken over from a trusted brand passes those filters.
Monitor continuously rather than periodically. Our Dangling DNS API returns these findings programmatically, so this becomes a scheduled job that alerts the SecOps and IT teams instead of a quarterly project.
Silent Push Total View query for financial organization infrastructure
Silent Push Total View query for automotive organization infrastructure
Silent Push Total View query for pharmaceutical organization infrastructure
Silent Push Total View query for federal agency infrastructure
Conquering Danglegeddon
The objective of this research initiative was to develop a few simple ways for organizations to better identify vulnerabilities and defend against attackers who leverage existing internet infrastructure against them.
To achieve this, it was necessary to run the attack simulation to analyze infrastructure samples from organizations across a few key industry sectors. We used the same set of techniques throughout the simulation to successfully take over “dangling” infrastructure associated with each targeted organization and, within a safe and controlled environment, redirect it to demonstrate how easily it could be exploited on the open internet.
Our intent with this initiative is to raise awareness of how extremely dangerous dangling DNS domains and subdomains can be when organizations are not practicing secure IT hygiene across their networks.
As evidenced by our approach, scoping the downstream impact of dangling DNS takeovers, assessed across a small but significant sample of global infrastructure, paints a clear picture of how quickly and easily organizations can be exploited, especially since attackers can simply stand up third-party infrastructure for exactly this purpose.
In addition to adhering to consistent IT hygiene practices, organizations can use the Silent Push Platform to identify dangling infrastructure and other assets, among many proactive measures, to preemptively protect their networks.
Despite the significant business and critical service disruptions in this scenario, Microsoft is just one cloud provider among many carrying this same exposure. The substantial non-Microsoft infrastructure still out in the wild represents an enormous attack surface we’ll explore in a follow-up to this report.
Interested in Learning More?
Start a conversation with one of our platform experts to learn how our preemptive cyber defense can give your team more lead time on adversary infrastructure, before an attack is launched.
Australia’s Security of Critical Infrastructure Act 2018, usually shortened to the SOCI Act, has quietly become one of the most demanding pieces of cyber regulation in the Asia Pacific. If you run security for an organisation in energy, financial services, healthcare, telecommunications, transport, data storage, or one of the other regulated sectors, it now shapes how you identify risk, what you report, and how quickly you report it.
The framework has also changed a great deal in the past two years, and another round of changes is in consultation right now. This article walks through what the SOCI Act asks of responsible entities, what has shifted recently, and where working ahead of an attack, rather than behind it, helps you meet those obligations rather than just document them.
A note before we start. This is a practitioner explainer, not legal advice. For a formal view on whether your assets are captured and which obligations apply, talk to cyber legal counsel.
What the SOCI Act covers
The SOCI Act sets out the obligations you carry if you own, operate, or hold a direct interest in a critical infrastructure asset. It applies across eleven sectors: communications, financial services and markets, data storage or processing, defence industry, higher education and research, energy, food and grocery, healthcare and medical, space technology, transport, and water and sewerage.
Industries affected
The SOCI Act covers eleven sectors
Communications
Financial services and markets
Data storage and processing
Defence industry
Higher education and research
Energy
Food and grocery
Healthcare and medical
Space technology
Transport
Water and sewerage
A critical infrastructure asset is defined in the Act for each sector, and the definition turns on function. If several components operate together as one system or network that meets the definition, they count as a single asset. If they operate as separate systems, then they are treated separately. The government’s own framing is that these are the facilities, supply chains, and networks that would cause significant harm to the country’s economic or social wellbeing if they were degraded or offline for any length of time.
The interconnection is the part that tends to catch people out. Think of it this way. A prolonged failure in energy does not stay in energy. It reaches medical supply, food and groceries, water and sanitation, telecommunications, transport, and banking. The regulation is written with that cascade in mind.
The obligations, in plain terms
For most responsible entities, the SOCI Act comes down to three positive security obligations.
Register the asset
You provide operational and ownership information to the Register of Critical Infrastructure Assets, maintained by the Cyber and Infrastructure Security Centre (CISC).
Report cyber incidents
A critical incident that has a significant impact on the availability of your asset must be reported to the Australian Signals Directorate within 12 hours of you becoming aware of it. Incidents with a relevant but lesser impact carry a 72 hour reporting window.
Maintain a risk management program
You adopt, maintain, and comply with a written Critical Infrastructure Risk Management Program, the CIRMP. It has to identify and manage material risk across cyber, physical, personnel, and supply chain hazards, it has to be approved by the board, and it has to be reported on annually.
There is a second tier for assets designated as Systems of National Significance (SoNS), which carry four Enhanced Cyber Security Obligations. These cover incident response planning, cyber security exercises, vulnerability assessments, and providing system information so the government can build and maintain a near real-time threat picture. That last obligation is worth thinking about, because it points directly at the kind of forward visibility this Act increasingly expects.
What has changed, and what is coming
SOCI today is not the SOCI of a few years ago. The ERP Act 2024 widened the framework in late 2024, bringing in data storage and telecommunications and giving the regulator broader powers, and the Cyber Security Act 2024 added related obligations on ransomware reporting and IoT security. A further round of reforms is in consultation now, with proposals to extend duties to third parties such as managed service providers and to tighten supply chain expectations under the CIRMP.
If you own, operate, or supply an Australian critical infrastructure asset, these obligations can reach you wherever your organisation is based, and they keep expanding what counts as your risk surface while asking you to show you are on top of it before something goes wrong.
Where preemptive cyber defense fits
These obligations all turn on timing in one way or another. A CIRMP is meant to show you are managing material cyber risk while it is still developing, and the enhanced SoNS obligations go further, expecting you to feed into a near real-time threat picture and to keep finding vulnerabilities before they are used against you. Even the incident reporting rules reward early awareness, since the clock starts as soon as you become aware of an incident, well before you have worked out its full scope.
Traditional detection tooling only tells you sooner in relative terms. It fires once an adversary is ‘live’, already inside your environment or already interacting with your asset, and by that point the reporting clock is running and the risk has already materialised.
Preemptive cyber defense works in the window before that. The most capable actors targeting regulated infrastructure do not appear without warning. They register domains, age them, stand up hosting, and stage campaigns for weeks or months before anything is delivered. Silent Push maps that preparation phase. The Context Graph continuously tracks how infrastructure is created, managed, and connected across DNS, WHOIS, certificate, and hosting data at internet scale. When those patterns match the way adversaries build and run campaigns, Silent Push issues Indicators of Future Attack® (IOFA): verified signals that a staging ground exists now, before it has been pointed at anyone.
For a responsible entity, that maps onto SOCI obligations in a few concrete ways:
It strengthens the threat picture the SoNS obligations ask for, because origin and infrastructure intelligence gives your team visibility into adversary activity that is aimed at your sector before a campaign launches.
It gives your CIRMP something to act on. Material cyber risk is easier to identify and manage when you can see the infrastructure being assembled against organisations like yours, rather than reconstructing it after an incident.
It supports the reporting obligations by shortening the distance between adversary activity and your awareness of it, which is exactly what a 12 hour clock demands.
And as the 2026 proposals push supply chain risk to the front, mapping the infrastructure connected to your suppliers and partners becomes part of the same picture.
Preemptive cyber defense
The window where risk is reduced
Before
Adversary stages infrastructure
You act here
Silent Push issues IOFA®
Day zero
Attack launches
After
Public IOCs emerge
None of this replaces a CIRMP, an incident response plan, or the legal work of confirming which obligations apply to you. What it does change is the position you operate from. SOCI is steadily raising the bar on how early and how thoroughly you are expected to understand the threats facing your assets. Seeing adversary infrastructure while it is still being built is how you meet that expectation with room to act, instead of documenting a breach after the fact.
If you run critical infrastructure in the region and want to see what that early visibility looks like against your own environment, book a demo and we will walk you through it.
What is the SOCI Act? The Security of Critical Infrastructure Act 2018, known as the SOCI Act, is Australian law that sets cyber, physical, personnel, and supply chain security obligations for organisations that own or operate critical infrastructure assets across eleven sectors, including energy, financial services, healthcare, telecommunications, transport, and data storage.
Who does the SOCI Act apply to? It generally applies to entities that own, operate, or hold a direct interest in an Australian critical infrastructure asset, regardless of where the organisation is headquartered. Whether a specific asset is captured is a legal question for your counsel.
What are the main obligations under the SOCI Act? For most responsible entities there are three: registering the asset, reporting cyber incidents, and maintaining a board-approved Critical Infrastructure Risk Management Program. Assets designated as Systems of National Significance carry additional Enhanced Cyber Security Obligations.
What are the cyber incident reporting timeframes? As it stands, a critical incident with a significant impact is reported within 12 hours of awareness, and an incident with a relevant but lesser impact within 72 hours. Confirm the current thresholds against the legislation, since reporting rules have been changing.
Does the SOCI Act reach overseas or third-party providers? It can. Foreign owners of Australian assets are captured, and the proposed 2026 reforms would extend duties to third parties such as managed service providers, alongside stronger supply chain expectations. The detail is still being consulted on.
How does Silent Push preemptive cyber defense support the SOCI Act obligations? Obligations like contributing to a near real-time threat picture and meeting the incident reporting clock are easier to satisfy with early warning. Seeing adversary infrastructure while it is still being built lets teams reduce risk before an incident, which is the gap Silent Push works in.
