If an attacker probes your infrastructure and fails, is that good news?
Yes, but only partly.
NBC News reported on September 2, 2026, that Iranian hackers had recently attempted cyberattacks against a range of U.S. infrastructure, including water, telecommunications, energy, and other systems. The reported attempts were unsuccessful, but the larger lesson is difficult to ignore: critical infrastructure remains attractive, reachable, and in many cases dependent on systems that were never designed for today’s threat environment.
Key Takeaway: An unsuccessful cyberattack can still expose a serious security problem. The bigger question is not only who is attacking, but whether organizations have left systems exposed or given attackers too much freedom once access is gained.
So what exactly happened?
According to NBC News, Iranian-linked attackers attempted to target multiple categories of U.S. infrastructure in recent weeks.
The report cited four people with access to government and industry cyberthreat information. As of September 5, the specific campaign details had not been publicly confirmed in a formal CISA or FBI attribution, so the reporting should be treated as credible but still developing.
That distinction matters.
There is, however, substantial historical evidence of Iranian government-linked cyber actors targeting U.S. critical infrastructure.
CISA, the FBI, NSA, EPA, and international partners previously documented IRGC-affiliated actors compromising internet-facing programmable logic controllers used in water, energy, food and beverage manufacturing, healthcare, and other sectors.
In those incidents, some affected systems were exposed to the public internet and protected by default passwords, weak credentials, or default ports.
Why should an unsuccessful attack concern business leaders?
Because failure today can reveal the path to success tomorrow.
Attackers learn from unsuccessful attempts. They identify exposed systems, weak remote access, poor segmentation, legacy technology, reused credentials, and systems that are easier to reach than they should be.
The FBI and EPA warned on July 30, 2026, that since July 27, water and wastewater utilities in at least seven states had reported attacks against internet-facing programmable logic controllers. Some of that activity degraded water operations. The FBI did not publicly attribute those specific July incidents to Iran.
The immediate lesson is not that every utility or manufacturer is about to be compromised.
It is that exposed operational technology is actively being tested by attackers.
Does an attacker need sophisticated malware to cause disruption?
Not always.
That may be one of the most important lessons in the current reporting.
CISA has previously documented Iranian-linked actors gaining access to industrial systems through basic weaknesses such as default credentials, internet exposure, and poorly protected remote access.
An attacker does not necessarily need a previously unknown zero-day if a critical controller is reachable from the internet with weak authentication.
That is why reducing attack surface matters.
The objective is not simply to detect more attacks. It is to give attackers fewer usable paths in the first place.
What changes when IT and operational systems are connected?
Connectivity creates business value, but it also creates pathways.
Industrial environments increasingly depend on Windows workstations, engineering stations, remote administration tools, jump servers, vendor access, cloud services, and interconnected business systems.
That means an incident does not always begin inside a PLC or industrial controller.
An attacker may begin with a credential, a workstation, a remote support tool, an exposed application, or a compromised third party and then attempt to move toward more sensitive systems.
This is why segmentation matters.
CISA recommends separating operational technology from unnecessary internet exposure, using secure gateways and firewalls, implementing strong authentication, controlling remote access, inventorying exposed assets, and limiting communications to expected systems.
Those are not theoretical recommendations. They directly reduce the number of ways an attacker can reach operational systems.
What if the attack reaches a Windows endpoint?
This is where endpoint strategy becomes important.
Detect and Respond remains necessary. EDR, logging, monitoring, threat intelligence, and incident response all have important roles.
But detection should not be the only control determining whether an attacker succeeds.
An attacker that reaches a Windows endpoint may still need to launch processes, abuse trusted applications, access memory, manipulate files, establish persistence, move laterally, reach sensitive data, or encrypt files.
Changing the attack does not necessarily change the endpoint actions the attacker ultimately needs in order to succeed.
That is an important distinction because unknown does not automatically mean unstoppable.
Can an attack be restricted without first identifying it?
Yes, in some cases, by restricting what applications and processes are allowed to do.
Isolation and Containment focus on reducing execution freedom inside the endpoint.
Instead of relying entirely on determining whether something is malicious, the security model constrains unauthorized applications and limits what higher-risk or trusted applications can access.
The objective is not to predict every attack. It is to restrict the actions an attacker needs in order to succeed.
AppGuard is a proven endpoint protection solution with more than a decade of production history focused on prevention through Isolation and Containment.
AppGuard does not need to know the name of every attack to restrict endpoint behaviors the attack may require.
It does not replace EDR, network segmentation, OT security controls, patching, or strong identity security. It adds another prevention layer designed to reduce what an attacker can actually do on a Windows endpoint.
That distinction becomes increasingly important as attacks become more automated.
IBM’s 2026 Cost of a Data Breach research found that one in four malicious breaches were AI-enabled, a 56% increase from the prior year. IBM also reported that 62% of AI-driven attacks in its study targeted critical infrastructure sectors.
Attack methods are changing quickly.
The endpoint actions needed to cause damage often are not.
What Should Businesses Do Next?
Business and infrastructure leaders should focus on reducing opportunities for attackers rather than assuming every attempt will be detected in time.
- Remove unnecessary internet exposure from operational technology and industrial control systems.
- Change default credentials and eliminate weak or shared passwords.
- Put secure gateways, firewalls, and strong authentication in front of remote access.
- Segment operational systems from business networks and unnecessary third-party access.
- Inventory internet-facing assets and identify systems no one realized were exposed.
- Review vendor and remote-support access paths.
- Keep supported systems patched where operationally feasible.
- Assume some threats will evade detection and add prevention layers accordingly.
- Reduce unnecessary execution freedom on Windows endpoints.
- Use Isolation and Containment where appropriate to restrict attacker behavior and reduce blast radius.
- Test what happens if a workstation, engineering station, remote-access account, or management system is compromised.
- Maintain tested backups and an incident response plan that accounts for operational disruption.
The bigger lesson
The identity of the attacker matters, but architecture matters more.
Iranian actors, ransomware groups, criminal affiliates, and AI-assisted attackers may use different code, credentials, vulnerabilities, and delivery methods.
They still need something usable to attack.
A reachable system.
A weak credential.
An application they can abuse.
A process they can launch.
A resource they can access.
A path they can move through.
The goal of prevention-first cybersecurity is to reduce those opportunities before an attacker turns access into disruption.
An unsuccessful attack should not simply be recorded as a win.
It should be treated as a warning to ask a more important question:
What could the attacker have done if the next attempt had worked?
That is the question infrastructure operators, MSPs, IT leaders, and business owners should be answering now.
September 11, 2026