INSIGHTS | September 3, 2026

The DRM Flag That Isn’t DRM

By Elvin Gentiles

SetWindowDisplayAffinity makes a window disappear from screenshots, screen shares, and Recall snapshots. Vendors sell that as “screenshot protection,” and procurement checklists tick it off as data-exfiltration risk mitigated. Microsoft’s own documentation for the API says otherwise. This post breaks down what the flag actually guarantees, who can route around it and how, and why a black screenshot is the beginning of a threat model rather than the end of one.

The Pitch, and the Problem with It

Open a modern secure-messaging app, password manager, or exam browser on Windows 11, hit PrtSc, and paste. The result is a black rectangle, or nothing at all. Vendor marketing calls it “screenshot protection.” Privacy blogs call it “blocks Recall.” The procurement checklist gets a tick next to data exfiltration: mitigated.

Microsoft’s own documentation for the API doing the work says otherwise:

Unlike a security feature or an implementation of Digital Rights Management (DRM), there is no guarantee that using SetWindowDisplayAffinity … will strictly protect window content.

The feature that makes a window disappear from screenshots is explicitly not a security feature, according to the people who built it. Yet vendors build a whole category of “privacy” and “DLP” features on top of it.

Microsoft is not consistent about this either. The Recall management documentation, aimed at developers whose remote desktop clients lack screen capture protection, calls adding it “an easy feature,” labels it “This DRM flag,” and points them to the very same SetWindowDisplayAffinity API whose own reference page insists it is not DRM. Two documents, one API, opposite claims.

That gap, between what the control implies and what it guarantees, is what this post takes apart. Attackers route around it without much thought. Defenders keep inheriting it as a checkbox someone else already ticked.

How the Flag Works

The Win32 function doing the work:

BOOL SetWindowDisplayAffinity(
  [in] HWND  hWnd,      // top-level window, must belong to the calling process
  [in] DWORD dwAffinity // the exclusion mode
);

Three values for the dwAffinity parameter matter:

Constant	Value	Behavior in a capture
WDA_NONE	0x00000000	No restriction. Normal capture.
WDA_MONITOR	0x00000001	Window shows only on a physical monitor; captures render it black.
WDA_EXCLUDEFROMCAPTURE	0x00000011	Window shows only on a physical monitor; captures omit it entirely (no suspicious black box).

WDA_EXCLUDEFROMCAPTURE is the newer, “better” flag. It arrived in Windows 10 Version 2004 (build 19041). Before that, WDA_MONITOR was the only option, and it left a tell-tale black rectangle. The upgrade is cosmetic from a defense standpoint: black box versus empty space. The security boundary is identical.

The difference is in what the capture comes back with. Under WDA_MONITOR, a screenshot or a screen share contains a black rectangle sitting exactly where the window is, and whatever the window overlaps is hidden along with it. Anyone looking at that capture learns that something was being withheld, how big it was, where it sat, and, in the case of a recording, how long it stayed open and when it closed. Under WDA_EXCLUDEFROMCAPTURE, the window is not in the frame and the desktop behind it shows through, so the capture looks like the application was not running at all. The user sharing their screen has no black box to explain, and the people watching get no cue that anything was hidden.

The Desktop Window Manager (DWM) enforces the exclusion. It is the compositor that assembles every window into the final image on screen. When a capture tool asks DWM for a frame of the desktop, DWM builds that frame and leaves the flagged window out of it. The pixels still reach the physical display; they never reach the composited frame handed to the capture tool. The flag embeds nothing in the window’s content and blocks no capture tool from running. Every bypass later in this post is a version of the same idea: get the image from somewhere other than DWM’s composited output, and the exclusion never applies.

Why Developers Reach for It Anyway

It’s an attractive control because:

It’s one line of code. No kernel driver, no service, no secure enclave.
It’s OS-native. No third-party dependency to vet.
It defeats the lazy attacker. PrtSc, Snipping Tool, Zoom/Teams/Meet screen share, OBS via the standard desktop-duplication path: all come up empty. Against a casual insider or an over-eager AI screenshotter, that’s a win.

The Signal case is the honest version of the story. When Microsoft shipped Recall, a background feature that silently snapshots the screen every few seconds into a searchable database, Signal had no developer-facing opt-out to keep chats out of the index. So, Signal set the display-affinity flag on its window. Signal’s own engineers described it, more or less, as a “one weird trick”: abusing a media-protection flag because Microsoft gave privacy apps no proper API. That’s a defensible decision against that specific threat, an OS feature capturing through the normal compositor path. It is not a general-purpose confidentiality control, and Signal never claimed it was.

The failure mode is the marketing leap: a product that “defeats normal screenshots” gets sold as one that “protects sensitive data,” with no threat model in between.

Who This Does Not Stop

Every control ever shipped can be bypassed, so the useful question is who can bypass this one, holding what access. Three capability tiers cover it.

Tier 0: The User Who Avoids the Blocked Path

Even with zero special access, plenty of capture paths never touch the DWM-composited surface the flag protects.

The analog hole: a phone camera pointed at the monitor. The pixels that reach a retina reach a camera sensor the same way. No API closes this, and Microsoft’s docs concede as much.
Context that breaks DWM: the protection only works while DWM is composing the desktop, a limit Microsoft states in its documentation. Remote Desktop sessions disable DWM, so a window invisible to a local screenshot can render perfectly over RDP. Certain remote-assistance and mirroring stacks, and some virtual-display configurations, land in the same bucket. The control silently fails open, which is the worst way for a control to fail.
VM quirks: in basic VMs without GPU acceleration, the compositor path can differ enough that the exclusion doesn’t behave as advertised.

None of these require privilege escalation. They require not using the one capture method the flag was designed to block. Tier 0 is where most real-world leakage happens, and it leaves almost nothing behind on the host.

Tier 1: The Local User Willing to Run Code

The window belongs to a process, and processes on a user’s own machine are not a trust boundary against that user. IOActive consultant Taha Draidia recently published the concrete version of this in Signal Windows Desktop: contentProtection Bypass, which takes apart Signal Desktop’s screen-capture protection. Signal reaches this same Win32 call through Electron’s setContentProtection() wrapper, so the write-up doubles as a case study in what the flag is worth.

Flip the flag back from inside the process. Draidia tested the obvious approach first: call SetWindowDisplayAffinity(hwnd, WDA_NONE) on Signal’s window from another process. That fails with ERROR_ACCESS_DENIED, and running elevated fails the same way, because the kernel check compares the caller’s process identity against the window’s owner rather than its privilege level. Administrator rights do nothing here. CreateRemoteThread into Signal’s own process satisfies the check, and the protection turns off with no error, no prompt, and nothing on screen to mark the change.

Capture below the compositor. DWM removes the window while assembling the desktop image, so the removal exists only in the copy DWM hands out. Capture that reads frames lower in the stack and closer to the hardware never receives that copy, and may see the window intact. The flag protects one rendering path rather than the content.

This explains where the protection breaks down, not how to build something that breaks it. Anyone who can run code in the user’s session can neutralize the flag, and the barrier is measured in API calls rather than in exploit development. The control is therefore exactly as strong as whatever stops code execution in that session.

Tier 2: Kernel, Driver, or Physical Access

The flag does not apply here at all. DWM checks the exclusion while it builds the desktop image, so code running at or below the display driver gets the pixels without that check ever happening. Independent kernel-mode research makes the point from the other direction: the proof-of-concept driver DWMShield skips the public API entirely and calls the undocumented internal routine GreProtectSpriteContent directly, passing a target window handle over an IOCTL from a non-elevated client. It reaches the same DWM enforcement point Draidia’s work identified, but from underneath the ownership check rather than by satisfying it — the mirror image of the CreateRemoteThread approach in Tier 1, and a separate piece of research rather than an extension of it.

The Actual DRM, for Comparison

The irony in the title is that real DRM exists on the same platform and works on a different principle.

Hardware-backed protected media paths (Widevine L1, PlayReady SL3000, FairPlay) decrypt and composite content inside a Trusted Execution Environment, a secure media path that user-mode and often kernel-mode capture cannot reach. That’s why screen-recording a premium streaming-video service yields a black frame even with admin rights: the pixels never exist in a framebuffer the OS will hand out.

The flag that isn’t DRM, side by side with the DRM that is:

	SetWindowDisplayAffinity	Hardware DRM (protected media path)
Enforced by	DWM composition, kernel-side owner check on the flag	Secure hardware / TEE
Where the viewable image lives	Normal framebuffer; omitted only from the copy handed to capture	Inside the TEE; never in a framebuffer the OS can hand out
What it covers	One top-level window at a time, per HWND, re-applied for every new window	The content stream itself, wherever it plays
Stops normal screenshots	Yes	Yes
Kept out of Recall snapshots	Yes	Yes (Microsoft: Recall won’t store DRM content)
Stops a local user with admin	No (admin enables injection)	Yes
Survives process injection	No	Yes
Survives RDP / DWM-off contexts	No (fails open)	Yes
Stops a phone camera	No	No
Who can disable it	Any code running inside the owning process	No software path; requires defeating the hardware
How it fails	Open and silent: no error, no log, no visual change	Closed: the license refuses to bind, playback stops or drops quality
Cost to adopt	One API call per window, no licensing	Device certification, license server, key management; SL3000 is device-only
Microsoft’s own classification	“Not a security feature or DRM”	Actual content protection

SetWindowDisplayAffinity is a hardening measure against opportunistic capture. Hardware DRM is a confidentiality control. Treating the flag as a confidentiality control is where the false sense of security begins.

What Developers Should Do

Using SetWindowDisplayAffinity is reasonable. Products go wrong when they treat that one API call as the finished control.

Set it on every top-level window, not just the main one. Affinity is a per-HWND property and every new window starts at WDA_NONE. Dialogs, tooltips, context menus, toasts, and the separate windows that WPF popups and Electron render into each get their own HWND. Flag the main window but not the dialog, and the screenshot catches the secret in full while the ordinary window behind it is the part that gets hidden.

Check the return value. The call returns FALSE on a window that isn’t top level or doesn’t belong to the calling process, and a silent failure still looks protected in code review. Treat it as a security event. On builds older than 19041, WDA_EXCLUDEFROMCAPTURE succeeds and behaves as WDA_MONITOR, so the window turns black instead of vanishing and the API never mentions the difference.

Re-read the flag. GetWindowDisplayAffinity reads the current value from any process, so the app or a monitoring agent can poll it. A change to WDA_NONE the app didn’t make means something else is writing to its process: log it, alert on it, and consider blanking the view until the app can verify its own state.

Use the supported control when one exists. Recall now has real policy: Allow Recall to be enabled (AllowRecallEnablement) and Turn off saving snapshots for Recall (DisableAIDataAnalysis), and managed devices have it removed by default. The flag was a workaround for consumer machines with no opt-out, which is still where it earns its keep.

Document the threat model. Name what the feature stops: screenshot tools, screen sharing, OS-level snapshotting. Name what it doesn’t: cameras, remote sessions, code running in the user’s session, anything at kernel level. Microsoft’s Azure Virtual Desktop documentation is the model to copy: it states plainly that the feature isn’t DRM-level protection and isn’t a substitute for one, and recommends pairing it with other controls.

Pair it with content-level controls. Reveal-on-tap for secrets, short display timeouts, redaction by default, per-session watermarking.

What Defenders Should Monitor

You cannot stop capture on a machine the user controls. You can often catch the attempt.

Injection into the protected app: the Tier 1 bypass is a common and ordinary injection, and the Signal bypass used CreateRemoteThread, the loudest option available. Watch Sysmon Event ID 10 (ProcessAccess) against that target with PROCESS_VM_WRITE, PROCESS_VM_OPERATION, or PROCESS_CREATE_THREAD; Event ID 8 (CreateRemoteThread); Event ID 25 (ProcessTampering); and Event ID 7 (ImageLoad) for unsigned modules or anything from a user-writable path.

Tamper events the app reports about itself: this depends on developers implementing the affinity re-read above, so ask whether they did. An app reporting “my window affinity changed and I didn’t change it” is a detection with almost no false-positive surface.

Capture and remote-control tooling on regulated hosts: OBS, ShareX, Snagit, ffmpeg with a screen-grab input, and support stacks such as AnyDesk, TeamViewer, and ScreenConnect. Inventory and policy rather than alerting, since none are malicious by default. The question is why a capture stack is installed on a host whose security depends on capture being hard.

Policy drift: if Recall is disabled by policy, verify it stayed disabled on the endpoint rather than trusting that the GPO exists. BYOD is the harder case, because Recall is available by default there and the user decides.

Everything a camera sees: out of reach of host telemetry. That leaves physical controls and per-session watermarking that survives a photograph. “We can’t stop the screenshot, but we can tell whose session it came from” is a more defensible promise than “the screenshot came out black.”

Conclusion

Read the flag as what it is and Microsoft’s two pages stop contradicting each other: it keeps sensitive windows out of casual captures and out of Recall on machines where the user is not the adversary, and it does nothing about the three tiers above. When a datasheet or a control matrix claims more than that, the difference is data with nothing protecting it, and another control has to cover the gap. A design that depends on a screenshot-proof window for confidentiality is a finding rather than a control.

References

Microsoft Learn — SetWindowDisplayAffinity function (winuser.h)
Microsoft Learn — Manage Recall for Windows clients
Microsoft Learn — Screen capture protection in Azure Virtual Desktop
IOActive — Signal Windows Desktop: contentProtection Bypass
GitHub — ahossu/DWMShield

INSIGHTS | September 1, 2026

Offensive Security Best Practices for Modern Enterprises

By IOActive

Security professional reviewing server infrastructure in a data center as part of offensive security best practices.)

Annual assessments are not enough. A strong security program tests its defenses against realistic attack scenarios throughout the year. Can an attacker reach a critical service? Will the security team see the activity? Can the organization contain it before the business feels the impact?

The answers depend on people, processes, and technology working together. These offensive security best practices help security leaders build an ongoing, threat-informed capability.

Offensive Security Best Practices at a Glance

Best practice	What it does	What to do	Business value
Threat-informed objectives	Prioritizes relevant threats, assets, and risks	Select two test objectives: one high-value asset path and one critical service path	Better use of security resources
Adversary emulation	Recreates realistic attacker behavior and objectives	Map one chained attack path and define evidence for each step	More accurate risk insight
Red and Purple Team exercises	Challenges defenses, then improves them collaboratively	Run an independent Red Team exercise, then retest the highest-risk gap with the Blue Team	Measurable defensive learning
Continuous validation	Retests controls after change, remediation, and new threats	Define retest triggers and compare the original result with the new result	Ongoing assurance
Full-stack coverage	Evaluates people, processes, technology, and dependencies	Map one business-critical service and test an attack across at least two layers	Fewer blind spots
Enterprise risk integration	Connects findings to business priorities and decisions	Assign an owner, a treatment decision, and a 90-day remediation path	Better governance and investment

Use the table to plan the work. The sections below show how to implement each practice and choose reporting measures.

Set Threat-Informed Objectives

Effective testing starts with the threats and assets that matter most. Before choosing an assessment, identify critical services and sensitive data. Also identify privileged identities and operational systems, and map the dependencies that support them.

Mandiant’s 2025 data shows why this prioritization matters. Exploits were the most common initial infection vector in its investigations, accounting for 33%. Stolen credentials accounted for another 16%. Prioritize the attack paths most likely to affect the business.

Create a risk register using four fields: business service, high-value asset, likely threat scenario, and security question. Rank each scenario by business impact, then assess its exposure and the ability to detect and contain it. Turn the highest-ranked scenarios into test objectives.

What to do

Choose two objectives: test one path to a high-value asset and one path that could disrupt a critical business service.
Write the security question: for example, “Can an attacker with a compromised identity reach the payment environment without triggering a response?”

These objectives set a clear destination and make the result easier to measure. Next, model how an attacker might reach it.

Use Adversary Emulation to Test Real Attack Paths

Adversary emulation recreates realistic attacker behavior and objectives. Moving well beyond isolated weaknesses, it tests whether an attacker can join techniques, move through the environment, and reach a clear target.

A scenario may include initial access and privilege escalation. It may include lateral movement and persistence. It may end with access to a high-value asset. A Red Team approach uses threat intelligence to shape the scenario. It also uses attacker tactics, techniques, and procedures to model a real attack chain.

Turn each step into a control-validation action. Record the failed control and the evidence available, then record the owner, remediation action, and retest date. This keeps the exercise focused on reducing risk and assigning follow-up work.

Mandiant reported a global median dwell time of 11 days in its 2025 report. When an outside party found the intrusion, the median was 26 days. Use these figures as context for your own baseline. For each exercise, record whether the path was completed, along with detection coverage, time to detect, time to contain, business impact, and internal discovery time.

Emulation should show which improvement can reduce risk next.

What to do

Build one attack chain: map the path from the selected entry point to the target asset, including the control expected to stop each step.
Define the evidence in advance: agree on the alerts, logs, response actions, and timing measures that will determine whether each control worked.

With the path defined, pair independent attack pressure with collaborative defensive improvement.

Combine Red Team and Purple Team Exercises

Red Team exercises provide an independent challenge. Skilled operators try to bypass controls and follow realistic attack paths. They work toward a defined objective. Threat-emulation services include Red Team, Purple Team, physical security and breach assessment, and social engineering.

Purple Team work turns that challenge into measurable defensive improvement. The offensive and defensive teams examine alerts together. They tune detection logic, refine response playbooks, and rerun the highest-risk failed step. Red Team shows what an attacker may accomplish. Purple Team tests whether defenders can detect and stop it.

Start with the highest-risk failed step, and focus the first retest on the control that matters most. Have the Blue Team confirm the expected alert, then run the response action. Repeat the step until the result is measurable. Track time to detect, time to contain, technique coverage, and recurring false positives.

No single improvement percentage applies across Red Team and Purple Team exercises. Compare the baseline with the retest result to show whether the organization became faster, more visible, or more resilient.

What to do

Run two exercises: use an independent Red Team scenario to test the attack path, then use a Purple Team session to validate the highest-risk detection and response gaps.
Retest the failed step: after tuning the alert, repeat the technique and confirm that the response works under realistic conditions.

The resulting evidence feeds the next practice: continuous validation.

Use Security Validation to Continuously Test Controls

Controls can lose effectiveness after configuration changes, new technology, security incidents, or shifts in attacker behavior. Security validation provides a repeatable way to check priority controls over time.

Build validation into risk, change, and remediation workflows. A practical cycle is: test the control, identify gaps, remediate them, retest, and report progress.

Define a retest trigger for each priority control. Verizon’s 2026 Data Breach Investigations Report found that software vulnerabilities began 31% of breaches and ransomware appeared in 48% of breaches. The report also found that 15% of breaches involved attack techniques bolstered by generative AI. These findings support validation whenever the environment or threat picture changes.

What to do

Set five triggers: retest after a material configuration change, a new exposed service, a high-severity vulnerability, a relevant threat-intelligence update, or completed remediation.
Report one outcome: record whether the original failure was reproduced, contained, or resolved, and attach the evidence.

Continuous Validation Triggers and KPIs

Validation trigger	Minimum response	KPI to report
Material configuration change	Rerun the affected attack step	Detection coverage before and after the change
New exposed service	Test access, authentication, and monitoring	Unauthorized paths found
High-severity vulnerability	Validate exploitability and containment	Exploit success and time to contain
Relevant threat-intelligence update	Add or revise an emulation scenario	Techniques covered
Completed remediation	Retest the original failure and record evidence	Failure reproduced: yes or no

When a failed control crosses a system boundary, extend the test across the full stack and verify the handoff.

Test the Full Stack

Attack paths cross security teams and technology layers. A weakness in identity management may expose an application. An application compromise may then provide access to cloud infrastructure, operational technology, or sensitive data.

A mature program tests people and processes as well as technology. The scope may include applications, APIs, cloud environments, endpoints, connected devices, AI systems, supply chains, hardware, and firmware. Shape the assessment around business risk and the dependencies that could change the outcome.

Full Stack Security Assessments cover physical security, hardware, embedded systems, and silicon-level systems. They also cover software, people, processes, and supply-chain security. This cross-layer view helps teams understand one attack path from entry point to business impact.

AI adoption adds another cross-layer dependency that can span several teams. Include identity, cloud, data, and AI workflows in the same risk conversation. Keep those workflows connected to the broader security program.

Measure the layers that matter to the selected service. Useful KPIs include social-engineering success and reporting rates. Track privileged paths, authorization bypasses, cross-zone paths, asset-to-asset paths, and untested dependencies.

What to do

Start with one service: map every dependency that supports a business-critical service, from people and facilities to applications and data.
Cross two layers: select one attack scenario that moves across at least two layers, such as identity to cloud or physical access to a workstation.

This produces a practical full-stack test and gives business leaders evidence they can use.

Connect Findings to Enterprise Risk Management

Offensive security creates value when each significant finding answers four questions. What could an attacker do? Which business service is affected? Which control failed? What should the organization address first?

The financial stakes make this translation important. IBM’s 2025 Cost of a Data Breach Report put the average global breach cost at $4.44 million and the mean time to identify and contain a breach at 241 days. Connect each finding to exposure, disruption, response performance, and the cost of reducing the risk.

NIST’s 2026 Cybersecurity Framework 2.0 quick-start guide links cybersecurity risk, enterprise risk, and workforce decisions. Give each priority finding a business owner, risk scenario, treatment decision, target date, and success measure.

Useful measures include priority attack paths validated and detection and containment performance. Track recurring control failures and the time between remediation and retesting. Map those measures to decisions about ownership, funding, staffing, architecture, and accepted risk.

What to do

Assign a decision owner: give each priority finding one accountable business owner and a technical lead.
Build a 90-day roadmap: put the highest-impact attack paths first, define retest dates, and report progress in the same forum used for enterprise risk decisions.

Enterprise Risk Decision Matrix

Security evidence	KPI to report	Enterprise decision
A priority attack path succeeds	Percentage of priority paths completed	Fund remediation or formally accept the risk
Detection is missing or delayed	Median time to detect	Prioritize monitoring, logging, or staffing
A control fails after remediation	Repeat-failure rate	Revisit the control design or implementation
Retesting is repeatedly delayed	Days overdue	Escalate ownership and delivery risk
A business service has several exposed layers	Number of exposed layers	Sequence a full-stack improvement plan

The real result is a better question: “Which risk decision should this evidence change?”

Make Offensive Security an Ongoing Capability

An ongoing capability links four activities: threat intelligence shapes the scenario, testing produces evidence, an owner handles remediation, and retesting confirms the result.

IOActive offers Red Team and Purple Team exercises, physical security and breach assessments, and social engineering. Its services also include full-stack assessments, penetration testing, code review, reverse engineering, secure development, advisory services, security training, and OCP SAFE assessments.

Select the service combination that matches the attack path. One engagement can expose the path, while follow-on testing and advisory support can help teams sustain the fix.

What to do

Schedule the retest first: define the evidence required to close the finding before the initial engagement begins.
Review the cycle quarterly: refresh threat scenarios, check overdue remediation, and select the next business-critical attack path.

Talk to IOActive About Offensive Security Best Practices

A mature offensive security program turns realistic attack testing into clear decisions. Test a business-critical attack path, measure how quickly defenses detect and contain it, fix the highest-risk gap, and retest.

If you need help connecting these activities across your technology stack, talk to IOActive. The team can help you apply these practices to a clear business risk.

Talk to IOActive about offensive security best practices

Sources

Google Threat Intelligence, “M-Trends 2025: Data, Insights, and Recommendations From the Frontlines,” https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2025
IOActive, “Red Team & Purple Team Services,” https://www.ioactive.com/service/red-team-and-purple-team-services/
Verizon, “2026 Data Breach Investigations Report,” https://www.verizon.com/business/resources/reports/dbir/
IOActive, “Full Stack Security Assessments,” https://www.ioactive.com/service/full-stack-security-assessments-2/
IBM, “2025 Cost of a Data Breach Report: Navigating the AI rush without sidelining security,” https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai
National Institute of Standards and Technology, “NIST Cybersecurity Framework 2.0: Cybersecurity, Enterprise Risk Management, and Workforce Management Quick-Start Guide,” https://csrc.nist.gov/pubs/sp/1308/final

INSIGHTS | August 26, 2026

Signal Windows Desktop: contentProtection Bypass

By Taha Draidia

Signal Desktop on Windows ships a screen-capture protection feature that prevents the application window from appearing in screenshots or screen recordings. In this post, we walk through how we identified the underlying Windows API powering that feature, why naïve attempts to disable it fail even from a privileged process, and how we ultimately bypassed the protection by executing code within Signal’s own process context using CreateRemoteThread.

In this post we cover two distinct phases of the research:

Static analysis — locating the contentProtection API chain through Signal’s open source code and Electron documentation.
Kernel internals — reverse engineering win32kfull!NtUserSetWindowDisplayAffinity to confirm the ownership check that enforces the protection and understand exactly why cross-process calls are rejected.

Background

During an internal discussion, a colleague mentioned noticing that Signal’s window did not appear during a screen-share session. This prompted us to investigate the mechanism behind it and, naturally, to ask whether that mechanism could be bypassed.

Signal Windows Desktop contentProtection Bypass Signal Windows Desktop contentProtection Bypass

Finding the API Behind contentProtection

Signal Desktop is an Electron application and its source code is publicly available on GitHub. A ripgrep search for contentProtection across the codebase quickly identified the relevant call site:

SHELL · RIPGREP · SIGNAL-DESKTOP SOURCE

C:\Users\tahai\code\Signal-Desktop>rg contentProtection
app\main.main.ts
566:  const contentProtection = ephemeralConfig.get('contentProtection');
571:    (contentProtection ?? isContentProtectionEnabledByDefault(OS, os.release()))
3022:  if (name !== 'contentProtection') {
3026:  const contentProtection = ephemeralConfig.get('contentProtection');
3029:    if (typeof contentProtection === 'boolean') {
3030:      window.setContentProtection(contentProtection);

ts\windows\preload.preload.ts
6:installEphemeralSetting('contentProtection');

ts\util\createIPCEvents.preload.ts
208:        ((await getEphemeralSetting('contentProtection')) ??
216:      await setEphemeralSetting('contentProtection', value);

The call at line 3030, window.setContentProtection(contentProtection), is the Electron API responsible for the behaviour. Checking the Electron documentation reveals how this maps to platform-specific system calls:

On Windows, setContentProtection(true) calls SetWindowDisplayAffinity with the flag WDA_EXCLUDEFROMCAPTURE. On Windows 10 version 2004 and later the window is excluded from capture entirely. On older versions the flag falls back to WDA_MONITOR behaviour, which renders the window as a black rectangle in any capture.

This setContentProtection path is a well-trodden one outside Signal, and community write-ups describing it match what we observed. On Windows the call resolves to SetWindowDisplayAffinity(WDA_EXCLUDEFROMCAPTURE) (and on macOS to CGWindowSetSharingType(kCGWindowSharingNone)), it requires Windows 10 build 19041 — the May 2020 Update — or newer for true exclusion rather than the black-rectangle WDA_MONITOR fallback, and the exclusion happens at the Desktop Window Manager (DWM) / kernel display layer rather than in the application. As a result the window is omitted from every user-mode capture pipeline that goes through Windows Graphics Capture (WGC) — Zoom, Teams, Meet, OBS, Game Bar, and ordinary PrintScreen and BitBlt captures alike. One documented caveat worth noting for defenders is that certain DXGI / direct-GPU capture paths can, on some GPU and driver combinations, still capture a window flagged this way — the exclusion is strong but not literally universal.

Windows SetWindowDisplayAffinity()

The API signature is straightforward — a window handle followed by a DWORD affinity value:

WDA_NONE (0x00000000) — no restrictions
WDA_MONITOR (0x00000001) — content displayed only on a monitor
WDA_EXCLUDEFROMCAPTURE (0x00000011) — content excluded from all capture

To disable the protection, we need to call this API with a valid top-level window handle for Signal and pass WDA_NONE. Obtaining the handle is straightforward: EnumWindows() paired with GetWindowTextW() and GetWindowThreadProcessId() lets us identify Signal’s window by cross-matching title text and process name.

Disabling the Protection — Three Approaches

Approach 1 — Cross-Process API Call

With a valid handle in hand, the first attempt was direct: call SetWindowDisplayAffinity(hwnd, WDA_NONE) from a separate process. This returns immediately with ERROR_ACCESS_DENIED (5). Windows is enforcing an ownership check — a process cannot modify the display affinity of a window it does not own.

Approach 2 — Elevated Privileges

The same call was retried from a process running as Administrator. The result is identical: ERROR_ACCESS_DENIED. The check is not privilege-gated. Even a fully elevated process is rejected when calling SetWindowDisplayAffinity against a window it does not own.

Approach 3 — Remote Thread Injection (Successful)

The key constraint the previous two attempts revealed is that the call must originate from within Signal’s own process. We satisfied this using CreateRemoteThread to execute SetWindowDisplayAffinity(hwnd, WDA_NONE) inside Signal’s process context. Because the call is issued from Signal’s process, it passes the ownership check and the protection is silently removed. The proof of concept is available on GitHub.

SetWindowDisplayAffinity() — Kernel Internals

Having confirmed the ownership constraint empirically, we verified it through static analysis of the kernel implementation. The userland call chain is:

user32!SetWindowDisplayAffinity
  └─ win32u!NtUserSetWindowDisplayAffinity   [syscall boundary]

SetWindowDisplayAffinity in user32.dll is a thin wrapper around the NtUserSetWindowDisplayAffinity syscall exported by win32u.dll:

Locating the Implementation in the Kernel

In the kernel the syscall is handled across two modules. We confirmed this with the WinDbg x command:

WINDBG KD · MODULE SEARCH

1: kd> x win32*!*SetWindowDisplayAffinity*
fffff805`5d55ad40 win32k!stub_UserSetWindowDisplayAffinity
fffff805`5d51d320 win32k!_win32kstub_NtUserSetWindowDisplayAffinity
fffff805`5d4fe5ac win32k!NtUserSetWindowDisplayAffinity
fffff805`618bb180 win32kfull!NtUserSetWindowDisplayAffinity

Disassembling win32k!NtUserSetWindowDisplayAffinity shows it calls win32k!W32GetSessionState for a desktop-session sanity check, then dispatches through nt!KscpCfgDispatchUserCallTargetEsSmep — a first-layer check with no ownership logic. The ownership enforcement lives in win32kfull!NtUserSetWindowDisplayAffinity.

The Ownership Check

Working through the disassembly, the sequence is:

WINDBG KD · WIN32KFULL!NTUSERSETWINDOWDISPLAYAFFINITY — ANNOTATED

; Resolve the target window to its internal struct (via ValidateReceivingHwnd)
fffff805`618bb1ac  call  win32kfull!ValidateReceivingHwnd
fffff805`618bb1b3  mov   rdi, rax          ; rdi = window object

; Get the Win32 process object of the *current* (calling) process
fffff805`618bb1c2  call  nt!PsGetCurrentProcessWin32Process
fffff805`618bb1c7  mov   r8, rax            ; r8 = current process

; Compare: does the window's owning process match the calling process?
fffff805`618bb1db  mov   rax, [rdi+10h]     ; rax = window's thread info
fffff805`618bb1df  cmp   [rax+1D0h], r8    ; owning process == calling process?
fffff805`618bb1e6  jne   +0xe2              ; NO -> ACCESS_DENIED

; ACCESS_DENIED path
fffff805`618bb262  mov   ecx, 5             ; ERROR_ACCESS_DENIED
fffff805`618bb267  jmp   win32kfull!UserSetLastError

The check is explicit: PsGetCurrentProcessWin32Process returns the Win32 process object for the calling thread, and that value is compared against the process stored at offset 0x1D0 of the window’s owning thread structure. If they differ, the call is rejected. Administrator privilege does not factor into this path — the check is purely about process identity, which is why elevated callers receive the same ERROR_ACCESS_DENIED as unprivileged ones.

CreateRemoteThread satisfies this check because it causes the API call to execute on a thread within Signal’s own process, making PsGetCurrentProcessWin32Process return Signal’s process object — an exact match.

Going Below the API — Kernel-Level Enforcement

The ownership check above lives in the syscall handler for SetWindowDisplayAffinity, but that syscall is only the documented front door. The exclusion state it sets is ultimately applied deeper in the graphics stack, inside DWM. Independent kernel-mode research reinforces this: a proof-of-concept driver (DWMShield) skips the public API entirely and calls the undocumented internal routine win32kfull!GreProtectSpriteContent directly, passing a target HWND and the same 0x11 (WDA_EXCLUDEFROMCAPTURE) flag. It works from kernel mode by exposing a device and symbolic link, taking the target window handle over an IOCTL from a non-elevated client, and invoking GreProtectSpriteContent on its behalf — after which DWM applies the same capture-exclusion state that the official path would have produced.

That work is the mirror image of ours. Where CreateRemoteThread bypasses the kernel ownership check by making the call originate from inside the target process, the driver bypasses it from the other side — by dropping below the user-mode API to the routine that actually enforces the flag, where the per-process identity comparison never runs. It carries the usual kernel-research friction: because GreProtectSpriteContent is not exported, its address must be resolved manually and shifts on every reboot under KASLR, and the driver depends on an internal signature that Windows updates can change. But the takeaway is the same one the ownership check hints at: the capture-exclusion decision is made by DWM in kernel space, and it can be reached — by moving code into the owning process, as we did, or by reaching the enforcing routine directly, as the driver does.

Conclusion

EnumWindows is a powerful Win32 API: it allows any process, regardless of privilege, to enumerate top-level windows within the current desktop session and receive a handle to each. Those handles do not, by themselves, grant meaningful access — what can be done with a handle is gated separately by each target API’s own access controls. In the case of SetWindowDisplayAffinity, the gate is a kernel-level ownership check that correctly rejects cross-process calls from any caller, including administrators.

However, the check is bounded by process identity rather than a broader integrity or trust model. CreateRemoteThread — a documented, widely-available Windows API — provides a straightforward way to move code execution into the target process and thereby satisfy that identity check. The result is a silent, runtime removal of screen-capture protection with no indication to the user.

This finding illustrates a recurring theme in Windows security: individual API-level checks are often well-implemented, but the combination of legitimate APIs can produce outcomes the checks were not designed to prevent. Defence-in-depth controls like screen-capture protection are most effective when the device is uncompromised. Once an attacker has local code execution they are in a position to erode multiple such controls through in-process execution. Signal’s protection is a solid user-mode control. What these two paths show is only that, like any capture-exclusion built on the same DWM mechanism, it rests on the integrity of the endpoint rather than on a boundary the local attacker cannot cross.

References

Reach Out to a Security Specialist at IOActive

INSIGHTS | August 20, 2026

Key Takeaways from the 2026 OCP APAC Summit

By Alejandro Hernandez

IOActive recently attended the 2026 OCP APAC Summit in Taipei. Below are our key takeaways from two days with the Open Compute community, along with a short recap video from the show floor at the end of this post.

Key Takeaways

The 2026 OCP APAC Summit (August 11–12) drew hyperscalers, semiconductor companies, device manufacturers, and infrastructure providers under the theme “Leading the Future of AI.”
AI security conversations extended beyond compute performance to the full stack: networking, cooling, storage, power, firmware, and the security controls underneath all of it.
Openness was a recurring theme, anchored by a dedicated SONiC Workshop on the open-source network operating system.
Multiple talks and vendor conversations pointed to growing interest in OCP S.A.F.E., the framework for independent security review of device firmware.
IOActive helped develop OCP S.A.F.E. from its early stages and continues to evaluate firmware security for device manufacturers today.

AI in the Agentic Era

AI was naturally at the center of this year’s summit, but the conversation went well past GPUs and raw compute performance.

The future of AI depends as much on trustworthy infrastructure as it does on faster accelerators and larger clusters. That means thinking about security across the whole stack, from applications and operating systems down to the firmware and hardware controlling the physical devices.

Open Data Centers and Open Networking

Openness was the other constant. The Open Compute Project’s philosophy of open hardware specifications, interoperable architectures, open firmware increasingly extends to networking, and the summit’s dedicated SONiC Workshop was a good example. SONiC, the open-source network operating system, brought together developers, users, maintainers, and vendors to compare notes on real-world deployments.

The direction of travel is toward data centers built from a diverse ecosystem of components rather than a single vertically integrated platform. That shift raises a practical question for operators: as devices and firmware arrive from a wider set of suppliers, how do you know they were built securely?

OCP S.A.F.E. and the Case for Independent Security Review

That question was the throughline of many of our conversations at the summit. Multiple technical talks and device-vendor discussions pointed to growing interest in OCP S.A.F.E., which lets vendors have their products evaluated by independent security reviewers against an established methodology.

For manufacturers, that’s more than a compliance checkbox. An independent review can surface vulnerabilities in firmware and other security-critical components before devices ship at scale, and it gives customers a concrete basis for confidence in what they’re deploying. As the supply chain behind any given rack grows more diverse, security assurance needs to travel with it.

IOActive has been involved in developing the OCP S.A.F.E. framework since its early stages, and we continue to work with device manufacturers on firmware and security assessments across the infrastructure being deployed today.

Taipei as a Meeting Point

Taipei was a fitting location for these conversations. Taiwan sits at the center of the global technology supply chain, home to a dense concentration of semiconductor companies, server manufacturers, ODMs, component suppliers, and firmware developers—much of the ecosystem responsible for the infrastructure data centers worldwide run on.

The summit itself made room for those conversations to happen: networking lounges, meeting areas, and coffee stations throughout the venue, lunch on-site, and reception drinks in the Expo Hall on the first evening. Live translation kept the technical sessions accessible to an international audience.

If you’re a device vendor preparing for OCP S.A.F.E. or looking to strengthen your firmware’s security, contact IOActive. Our team supports OCP S.A.F.E. assessments and independent firmware source-code security reviews.

Watch Our OCP APAC Summit Recap

Want to see the event from the show floor? We captured some of the technologies, conversations, and demonstrations from our time at the 2026 OCP APAC Summit in Taipei.

INSIGHTS | August 18, 2026

The Five Eyes AI Shift in Cyber Risk Statement: What Industry Leaders Need to Know Now

By IOActive

Key Takeaways

On 22 June 2026, the leaders of the Five Eyes cyber security agencies issued a joint statement, The AI Shift in Cyber Risk: Why Leaders Must Act Now, warning that frontier AI is transforming cyber risk on a timeline measured in months, not years.
The statement is signed by the heads of the National Cyber Security Centre (NCSC, UK), Cybersecurity and Infrastructure Security Agency (CISA, US), National Security Agency (NSA, US), Australian Signals Directorate (ASD, Australia), Communications Security Establishment (CSE, Canada), and Government Communications Security Bureau (GCSB, New Zealand) — an unusually unified articulation of urgency from the Five Eyes partnership.
Cyber risk is explicitly reframed as a core business risk and board-level responsibility, not a technical issue to be delegated downward.
Five practical actions are prescribed: reduce attack surface, accelerate patching, address legacy systems, strengthen identity and access controls, and prepare for incidents before they happen.
The statement lands days after the NCSC’s own CEO disclosed that 75% of attacks on UK critical infrastructure over the past year are linked to hostile states, and weeks after NCSC guidance warning of an incoming “vulnerability patch wave” driven by AI-accelerated exploitation.
Organisations that treat this as a compliance afterthought will be out of step with where their regulators, and their adversaries, are already heading.

A Statement for a Narrowing Window

Joint statements from the Five Eyes cyber agencies are not issued lightly, and this one is notable for its tone as much as its content. Published on 22 June 2026, The AI Shift in Cyber Risk [1] is signed jointly by Stephanie Crowe (ASD), Rajiv Gupta (CSE), Catriona Robinson (GCSB), Richard Horne (NCSC), David Imbordino (NSA), and Nick Andersen (CISA). The framing is unambiguous: frontier AI models are expected to exceed current industry expectations, and the timeline for that shift is not years, it is months.

This is not an isolated warning. Five days before the statement was published, NCSC CEO Dr Richard Horne told the Royal United Services Institute’s Annual Security Lecture that the NCSC had managed more than 200 cyber incidents affecting the UK’s critical national infrastructure in the year to May 2026, with around 75% believed linked to hostile state actors including Russia, China, and Iran [2]. Horne went further, arguing that cyber security should no longer be framed as a risk to be tolerated within appetite, but as an ongoing contest with capable adversaries. He also pointed to an NCSC assessment that by 2028, AI-enabled capabilities will likely be used to exploit known vulnerabilities in legacy technology at scale across UK critical infrastructure.

That assessment builds directly on guidance the NCSC published in May 2026, warning organisations to prepare for a “vulnerability patch wave”: a forced correction in which AI-accelerated exploitation surfaces decades of accumulated technical debt across commercial, open source, and proprietary software simultaneously [3]. The Five Eyes statement should be read as the international consolidation of that warning, not a standalone development.

What Does the Statement Set Out?

The statement is short and deliberately free of new technical detail. Its purpose is to compress urgency into a small number of leadership-level actions, structured around four overarching asks and five practical steps [1].

Leaders are urged to:

Understand and assess risk, readiness, and accountability. Boards need a clear, current picture of organisational exposure, not a static risk register reviewed annually.
Prioritise foundational cyber security practices and controls. Sophistication in tooling does not substitute for getting the fundamentals right.
Empower cyber leaders with authority and resources. Cyber leadership requires the mandate to act, not just the responsibility to report.
Stay actively engaged as threats and guidance evolve. Static governance models cannot keep pace with a threat landscape that is itself accelerating.

Two structural points distinguish this statement from prior Five Eyes guidance. First, it reframes AI not solely as an adversary capability but as a defensive obligation: organisations are explicitly told to use AI deliberately to strengthen defence, not merely to improve efficiency. Second, it sets an expectation that breaches are not preventable in absolute terms; preparedness is reframed as the capability to contain incidents quickly before they escalate into operational and financial crises [1].

Who is Affected by the Statement?

Boards and Executive Leadership

The statement is addressed primarily upward, not downward. It states plainly that cyber resilience is not an IT issue, it is central to operational continuity and market trust, and that it is not enough to have controls; leaders must be confident those controls will perform during a real incident [1]. This places direct accountability on boards and executives to verify resilience, not simply to fund it.

CISOs and Security Leadership

For security leaders, the statement is a mandate to escalate. The call to empower cyber leaders with authority and resources [1] gives CISOs a clear external reference point when seeking budget, headcount, or the organisational authority to challenge unsafe trade-offs that have previously been accepted in the name of operational convenience.

Operators of Critical National Infrastructure

For CNI operators, the statement reinforces direction already set domestically. The NCSC’s own intervention five days prior, disclosing that three-quarters of attacks on UK CNI are state-linked [2], makes clear that the threat described in the Five Eyes statement is not a future scenario for this sector. It is the current operating environment.

Vendors and Technology Providers

The statement explicitly calls on leaders across industry, including vendors, to act now [1]. Combined with the NCSC’s separate warning that a wave of vulnerability disclosures is approaching across commercial, open source, and proprietary software [3], vendors should expect both faster exploitation of existing flaws and intensifying customer expectations around patch velocity and secure-by-design practice.

What are the Key Challenges Organisations Will Face?

Compressed Exploitation Timelines

The central technical claim underpinning the statement is that AI is shrinking the window between vulnerability discovery and exploitation [1]. Patch cadences and change-management processes built around weeks or months of lead time were not designed for this. Organisations with manual patching processes, particularly across operational technology environments with long update cycles, face a widening gap between the speed of the threat and the speed of their own response.

Your Adversary Already Has an AI Upgrade

Even if your organization hasn’t touched AI, your attackers have. The patch window that once gave defenders breathing room is effectively gone — Mandiant’s time-to-exploit tracking shows exploits now landing on or before the day a CVE goes public. Exploitation itself has become a commodity: working proof-of-concept exploits can be generated in about 15 minutes, and autonomous vulnerability discovery campaigns can be run for roughly $50. This isn’t theoretical. Recovered logs from a June incident (via OALABS) showed a single operator driving over 1,000 AI-agent sessions across 14+ companies, with the models flagging a policy violation only about 10 times — because every request was simply framed as “authorized red-team” work. Social engineering has scaled right alongside it: Arup lost $25.6 million in 2024 after a video call where every “colleague” on the line was a deepfake, and the economics of that kind of attack have only gotten cheaper since. None of this requires exotic new attack vectors. It’s the same attack surface organizations have always had, now facing an adversary that doesn’t sleep, doesn’t hesitate, and operates at machine speed.

Legacy and Unsupported Systems

The statement is blunt that unsupported systems are not just technical debt, they are strategic liabilities [1]. This sits uncomfortably with sectors where legacy estate is structural rather than incidental, where replacement cycles are measured in years and safety-critical considerations constrain how quickly systems can be patched or retired.

Governance Gaps Between Boards and Technical Teams

Repeated emphasis on board-level accountability assumes a level of cyber literacy that many boards do not yet have. The gap between technical risk and the language boards use to govern it remains one of the most persistent obstacles to the kind of confident assurance the statement demands.

AI as a Dual-Use Capability

The statement’s insistence that organisations use AI deliberately to strengthen defence, not just improve efficiency [1], is a meaningfully higher bar than most organisations’ current AI security posture. Many security teams have adopted AI tooling for productivity gains. Far fewer have built the detection, monitoring, and response capability the statement envisages, while simultaneously managing the new attack surface that frontier AI systems themselves introduce.

Shipping Faster Means Shipping More Attack Surface

AI coding assistants have undeniably accelerated software delivery — but speed and security are moving in opposite directions. Veracode’s testing across more than 100 models found that roughly 45% of AI-generated code carries a security weakness. What’s more concerning is the trendline: functional correctness has raced past 95%, while the security rate has stayed flat at around 55% for two years running. Newer, smarter models are writing code that works — not code that’s safe. The practical impact is that attack surface is now growing at delivery speed, with code merging faster than any human review process was designed to handle, whether that code was sanctioned by the organization or introduced through shadow AI use, often with no clear provenance to trace it back. At the same time, client appetite for security testing is rising faster than budgets are — creating a widening gap between how much validation organizations want and how much they’re actually resourcing. Closing that appetite-budget gap is, in many ways, the central challenge facing security teams right now.

Checkout Our Blog to Learn More – The Security Gap in AI-Generated Code

Zero-Day Proliferation

The statement warns directly that as AI systems evolve, new and previously unknown vulnerabilities will emerge, including zero-day vulnerabilities [1]. Defence-in-depth, rather than reliance on any single control or technology, is positioned as the only credible response to a vulnerability landscape that is itself becoming less predictable.

How IOActive Can Help

IOActive’s work across offensive security, operational technology and industrial control system (OT/ICS) assessment, and critical infrastructure advisory positions us to support organisations translating this statement’s leadership-level mandate into operationally credible defence. Testing, not assumption, is how organisations find out whether their controls will actually perform under pressure, which is precisely the bar the statement sets.

Red Team and Purple Team Services

The statement’s call to verify that controls will perform during a real incident, not merely exist on paper [1], is best answered through adversarial testing rather than compliance review. IOActive’s Red Team operations emulate the tactics of the threat actors most likely to target a given organisation’s sector and assets, while our Purple Team engagements translate offensive findings directly into measurable improvements in detection and response.

Full Stack Security Assessments

Reducing attack surface and accelerating patching, two of the statement’s five practical actions [1], both depend on first knowing where exposure actually sits. Our full stack assessments examine internet-facing systems, cloud environments, and on-premises infrastructure together, identifying the specific systems an attacker would prioritise rather than producing a generic vulnerability count.

Supply Chain Integrity

The statement’s call for action extends explicitly to vendors [1]. IOActive’s Supply Chain Integrity service assesses the security posture of technology providers and critical third parties, reviewing firmware, embedded systems, and procurement processes for inherited risk before it becomes either a compliance finding or an incident vector.

Preparedness and Resilience Testing

The statement’s framing of preparedness as a capability to be trusted, not assumed, aligns directly with our tabletop exercise and crisis simulation work. We help organisations stress-test detection, escalation, and recovery processes ahead of a real incident, building the operational muscle memory boards are now being asked to assure.

Threat Modeling and Advisory

Understanding and assessing risk, readiness, and accountability, the statement’s first call to action [1], requires a structured, evidence-based view of organisational exposure. Our threat modelling and advisory engagements give CISOs and boards a shared, prioritised picture of risk that can be acted on with confidence rather than debated indefinitely.

What are the Recommended Next Steps?

The statement is explicit that delay carries growing and avoidable risk [1]. We recommend the following immediate actions.

Brief your board now on the statement’s core claim, that cyber risk assumptions can become outdated in months, and translate that into business, financial, and reputational terms.
Map your patch and change-management cycle against the compressed exploitation timelines the statement describes, identifying where current processes cannot keep pace.
Inventory legacy and unsupported systems with explicit reference to their exposure on external attack surfaces, not just their internal criticality.
Review identity and access controls across critical systems, with particular attention to permissions that have accumulated without recent review.
Test your incident response plan through a structured exercise that assumes a breach has already occurred, rather than one that tests whether it can be prevented.
Evaluate how AI is currently used across your security function, distinguishing tools adopted for efficiency from capability genuinely built to strengthen detection and response.

Conclusion

The Five Eyes statement is short by design, but its brevity should not be mistaken for limited weight. Six of the world’s most authoritative cyber security agencies have chosen to speak with one voice, in plain language, to say that the basis on which most organisations currently assess cyber risk is already out of date.

The statement does not introduce new technical obligations. It does something arguably more consequential: it removes the option of treating AI-accelerated cyber risk as a future planning consideration. Combined with the NCSC’s own recent disclosures on the scale of state-linked attacks against UK critical infrastructure and the coming vulnerability patch wave, the message to leaders is consistent and increasingly difficult to defer.

Organisations that wait for a forcing event, whether a breach, a regulatory deadline, or a sector-specific mandate, will be acting from a position of weakness. Those that act now, testing their assumptions rather than reviewing them, will be the ones still standing when the window the statement describes finally closes.

If you would like to discuss how your organisation’s current posture measures up against the expectations set out in this statement, or how IOActive can support your cyber resilience programme, we welcome the conversation.

References

[1] Australian Signals Directorate, Communications Security Establishment, Government Communications Security Bureau, National Cyber Security Centre (UK), National Security Agency, Cybersecurity and Infrastructure Security Agency. The AI Shift in Cyber Risk: Why Leaders Must Act Now. 22 June 2026. https://www.ncsc.gov.uk/news/the-ai-shift-in-cyber-risk-why-leaders-must-act-now

[2] National Cyber Security Centre. NCSC CEO: Hostile States Linked to Three-Quarters of Cyber Attacks Affecting UK’s Critical Systems. 17 June 2026. https://www.ncsc.gov.uk/news/ncsc-ceo-hostile-states-linked-to-three-quarters-of-cyber-attacks

[3] National Cyber Security Centre. Preparing for a ‘Vulnerability Patch Wave’. 1 May 2026. https://www.ncsc.gov.uk/blogs/prepare-for-vulnerability-patch-wave

INSIGHTS | August 13, 2026

Red Team vs Penetration Testing: Key Differences

By IOActive

“Penetration testing identifies vulnerabilities. Red teaming evaluates how effectively an organization can detect and respond to realistic attacks.” IOActive Security Team

The decision between red team vs penetration testing comes down to one question: What are you trying to learn? Most mature security programs need both methodologies, deployed in sequence: penetration testing to close technical gaps, and red teaming to validate that the controls protecting what remains will hold under real adversarial pressure.

This article breaks down the differences between red team vs penetration testing so your organization can choose the right approach.

Red Team vs Penetration Testing at a Glance

Dimension	Penetration Testing	Red Team Engagement
Primary objective	Find and exploit as many vulnerabilities as possible	Simulate a targeted adversary; test detection and response
Scope	Defined: specific systems, apps, or networks	Broad: may include physical access, social engineering, supply chain
Duration	Days to weeks	Weeks to months
Stakeholders	Internal stakeholders are aware	Only select executives are involved; blue team is typically unaware
Methodology	Transparent, checklist-oriented	Covert, adversary-emulation, objective-based
Threat model	Generic opportunistic attacker	Specific threat actor (e.g., APT29, FIN7)
Output	Vulnerability list with severity rankings and remediation steps	Detection timelines, playbook gaps, response readiness report
Best for	Organizations building foundational security controls	Organizations with a mature SOC and incident response capability
Compliance value	High (PCI DSS explicitly requires it; the proposed HIPAA Security Rule update would mandate annual testing if finalized; SOC 2 auditors widely expect it)	Lower direct compliance value; higher strategic value
Cost	$5,000–$50,000 depending on scope; most mid-market engagements fall between $10,000 and $35,000	$20,000–$100,000+ depending on duration and complexity; full adversary simulations typically run $40,000–$100,000

Penetration Testing

What it is: A penetration test is a time-boxed, authorized engagement in which ethical hackers identify and exploit vulnerabilities across a defined set of systems, applications, or networks.

The goal: Find as many exploitable weaknesses as possible, demonstrate their real-world impact, and deliver actionable remediation guidance.

Pros: Penetration testing goes beyond automated vulnerability scanning by adding human judgment: chaining vulnerabilities, testing business logic flaws, and filtering genuine risk from noise. Findings are immediately actionable.

Cons: Internal teams are typically aware the test is underway, which limits the value for measuring detection and response.

Choose a pentest when:

A compliance mandate requires it (PCI DSS, HIPAA, SOC 2 Type II)
You have deployed new infrastructure, applications, or cloud environments
You are validating remediation from a prior assessment
You are establishing your organization’s first formal testing program

Red Team Testing

What it is: A red team engagement is a full-scope adversarial simulation in which expert ethical hackers pursue specific objectives, such as accessing sensitive data or compromising executive accounts. Red team engagements use the same tactics, techniques, and procedures (TTPs) as real-world threat actors.

The goal: Determine whether your organization’s people, processes, and technology can detect, contain, and respond to a sophisticated attacker pursuing a specific objective, before a real adversary tests those same capabilities.

Pros: The engagement runs covertly, often without notifying the organization’s own security staff. This generates realistic data on detection timelines and incident response effectiveness.

Cons: Red team engagements are not optimized for cataloging technical vulnerabilities at scale. If foundational controls are weak, the red team will often achieve its objectives before meaningful detection data can be collected. In those cases, a penetration test would have surfaced the same findings faster and at lower cost.

Choose a red team engagement when:

Your SOC monitors alerts but has never been validated against a sophisticated intrusion
You need to test people and processes, not just technical controls
You want to measure detection and response against a specific, realistic threat scenario
Your security program has matured beyond foundational vulnerability management

Choose Based on Security Maturity

The most reliable decision factor is security maturity, which determines which question you are ready to answer. Organizations that have not yet closed known vulnerabilities will get more value from a pentest than from a red team engagement.

Organizations early in their security journey should run penetration tests first. If a red team can compromise your environment in hours without triggering a single alert, those findings could have been reached more efficiently with a pentest. Closing known vulnerabilities first allows a red team engagement to surface detection and response gaps that actually matter.

Security Maturity and Testing

Maturity Stage	Indicators	Recommended Approach
Foundational	No formal pentest history; basic patching	Penetration testing
Developing	Regular pentests; security tooling in place	Pentesting + targeted red team scenarios
Established	Functioning SOC, SIEM, incident response plan	Both methodologies on a defined cadence
Advanced	Mature threat intelligence; purple teaming capability	Red team + purple team for continuous validation

Most organizations overestimate their maturity. If you have not run a penetration test within the past 12 months, or if your SOC has never responded to a simulated intrusion, a red team engagement will tell you less than a rigorous pentest will.

How the Two Methodologies Work Together

Penetration testing and red teaming are not competitors: they serve different stages of a security program. The typical progression is to run a pentest, remediate vulnerabilities, and build detection and response capabilities. From there, a red team engagement tests whether the SOC would detect a sophisticated attacker exploiting what remains.

Red team findings routinely drive improvements to SIEM detection rules, incident response playbooks, and security awareness training. It’s also recommended to use purple team exercises, which pair red team attackers with the organization’s blue team in a collaborative format to accelerate control tuning in real time.

Work With IOActive for Red Team Engagements and Penetration Testing

With over 25 years of offensive security research and engagements across some of the world’s most complex environments, IOActive has the experience to determine the right methodology for your risk profile and execute it with precision. IOActive’s penetration testing practice goes beyond off-the-shelf tooling, applying an attacker’s perspective and human judgment to chain vulnerabilities, expose business logic flaws, and deliver findings with clear remediation priority. Our red and purple team engagements run multi-vector, goal-based adversary simulations across technical, physical, and human attack surfaces, testing prevention, detection, response, and recovery under realistic conditions.

Talk to an IOActive expert about the right security testing approach for your organization

INSIGHTS | August 10, 2026

When the Advisory Arrives First: Minnesota’s Water Utilities and the Limits of Warning

By IOActive

Key Takeaways

More than 30 Minnesota community water systems were targeted across July 26 and 27, 2026 in what Minnesota IT Services (MNIT) has characterized as a coordinated cyberattack. Automated control functions were affected at several utilities, and the City of Braham briefly took its water treatment plant offline [4][6][9].
No attribution has been made. Officials have not named a threat actor, identified an exploited vulnerability, confirmed which products were affected, or established whether data was taken [4][7].
The incidents followed four days after the July 22 update to joint advisory AA26-097A, which widened observed Iranian-affiliated targeting of internet-facing programmable logic controllers (PLCs) from Rockwell Automation equipment to include Schneider Electric and Siemens devices [1][3].
The City of Plymouth reported that impact was confined to equipment reached over cellular links. Remote assets — water towers, lift stations, pump stations — frequently sit outside the boundary of formal risk and vulnerability assessments [4][10].
The consequence class here is loss or manipulation of view and control, not data loss. Operators in the UK and Europe carry equivalent exposure, under a regulatory regime that is tightening as the UK Cyber Security and Resilience Bill progresses through Parliament [16].

Why This Incident Matters Now

A joint advisory told critical infrastructure operators, in specific terms, that state-linked actors were reaching internet-facing PLCs at water and wastewater utilities and manipulating what those controllers do. Four days later, more than 30 water systems in a single US state reported disrupted automated controls over a 48-hour period.

Whether the two events are connected has not been established publicly, and this analysis does not assume they are. The more useful question for security leaders is what the sequence reveals about the distance between a warning being issued and a warning being actioned. Advisory AA26-097A has been in circulation since April 7, 2026 [1]. Its July update did not describe a novel technique. It broadened the list of affected manufacturers and added detection guidance. For any operator running an internet-reachable controller from one of the named vendors, the required response was already documented, already free, and already several months old.

The Minnesota incidents are therefore worth examining less as a novel threat and more as a measurement of how much of the sector is positioned to act on advisories at the speed at which they are now being issued.

What Actually Happened in Minnesota

MNIT confirmed that more than 30 community water systems were targeted on July 26 and 27, 2026, and activated a statewide cybersecurity incident response [4][6][8]. The agency is coordinating with CISA, the Environmental Protection Agency (EPA), the FBI, state agencies and affected utilities [5][6]. The FBI has confirmed it is in contact with victims [6].

Four cities disclosed incidents publicly: Braham, Maple Plain, Plymouth and South St. Paul [4][9][10][11][12]. The reported pattern is consistent across them. Automated control functions were affected; contingency procedures were activated; in most cases water and wastewater operations continued. Braham took its treatment plant offline after detecting the incident and asked residents to limit water use, later reporting that the attackers had shut down operating controls, taking the well and treatment plant with them [4][9]. Maple Plain declared a local state of emergency to support its response [5][12]. South St. Paul reported that manual intervention by public works staff maintained normal operations despite the loss of some automated controls [4][11]. Plymouth attributed communications problems at two water towers and multiple lift stations to the incident, and stated that the impact was limited to equipment connected via cellular communications [4][10].

The affected cities have consistently informed residents that drinking water remains safe. MNIT stated on July 28 that it was aware of no active requests for residents to alter their water use [5].

Several material facts remain unpublished. MNIT has not released a full list of affected systems. No exploited vulnerability, affected product line or exfiltration finding has been made public. No actor has been named. Iranian-affiliated groups such as CyberAv3ngers and Handala fit the profile of the activity, and several outlets have noted the resemblance, but investigators have stressed that formal attribution has not been made [4][7]. Analysts should treat the attribution question as open.

What Changed in Advisory AA26-097A on July 22

Advisory AA26-097A was first published on April 7, 2026 by the FBI, CISA, the NSA, the EPA, the Department of Energy and US Cyber Command’s Cyber National Mission Force. It documented Iranian-affiliated advanced persistent threat (APT) actors exploiting internet-connected operational technology (OT) devices across the Government Services and Facilities, Water and Wastewater Systems, and Energy sectors, with confirmed disruption at victim organizations since at least March 2026 [1][2].

The July 22 update made three substantive changes [1][2][3].

Manufacturer Scope Widened

Observed targeting now extends beyond Rockwell Automation and Allen-Bradley controllers to Schneider Electric and Siemens PLCs, and potentially other branded devices. Specific models are named in the advisory, including Rockwell CompactLogix and Micro850, Schneider Modicon M340, and the Siemens S7-1200 series [3].

Detection Guidance for Reusable Code Modules

The update adds guidance on identifying malicious modifications to reusable logic — Add-On Instructions within Rockwell programs, for example — including validating project files and comparing running logic against a known-good baseline [3].

A Refreshed Indicator Set and a New Co-Authoring Agency

The update publishes a refreshed set of indicators of compromise, and the Department of the Treasury is added as a co-authoring agency [1][17].

The access method described in the advisory is the part that should concern operators most, because it is not a vulnerability in the conventional sense. Actors reach internet-exposed controllers from leased overseas hosting infrastructure and connect using the manufacturers’ own engineering software — Studio 5000 Logix Designer, EcoStruxure Control Expert, TIA Portal — the same tooling legitimate engineers use [1][3]. Connections made this way are difficult to separate from authorized administrative activity. From there, the advisory documents modification of control logic, disabling of alarm and shutdown functions, and alteration of data presented on operator displays [3].

Water and Wastewater Systems is named explicitly among the targeted sectors, and internet-exposed PLCs remain the primary access point [3].

Who Is Affected by Internet-Exposed OT?

US Water and Wastewater Operators

The sector’s risk profile varies enormously by resource level. Large municipal utilities often run segmented networks, dedicated security staff and formal asset lifecycle management. Most community water systems are small municipal utilities or rural cooperatives, some serving only a few hundred customers, without dedicated cybersecurity personnel or continuous monitoring [14]. A technique that a well-resourced utility would contain quickly can cause prolonged operational impact in a small system. The EPA leads federal water sector cybersecurity efforts but has no explicit statutory authority to mandate cybersecurity measures, relying on voluntary engagement and technical assistance [15].

UK and European Operators

Drinking water is an in-scope sector under the UK’s NIS Regulations 2018, and the UK Cyber Security and Resilience (Network and Information Systems) Bill would expand obligations, incident reporting requirements and regulatory powers across those sectors [16]. The Bill received its second reading in the House of Lords on July 14, 2026 [16]. The technical exposure is not materially different: the same vendors, the same engineering tooling, and the same practice of reaching remote assets over public networks.

Critical National Infrastructure (CNI) Operators in Other Sectors

Energy and government facilities are named alongside water in AA26-097A. Any organization running the named controller families in an internet-reachable configuration is within the described targeting scope, regardless of sector [1][3].

System Integrators and OT Suppliers

Where control system architecture is delivered by an integrator, the connectivity decisions — including secondary and backup communication paths — are frequently made outside the asset owner’s direct visibility. Under the Cyber Security and Resilience Bill, suppliers to regulated entities face obligations of their own [16].

What Are the Practical Challenges for Operators?

Plymouth’s disclosure that impact was limited to cellular-connected equipment is the most operationally instructive detail released so far. Water towers, lift stations and pump stations commonly report back to supervisory control and data acquisition (SCADA) systems over cellular modems, and these secondary or alternative communication links are routinely omitted from risk and vulnerability assessments [4]. This is not a new failure mode. In the 2020 attacks on Israeli water facilities, actors linked to the Iranian government used vulnerable cellular routers as the point of entry [4]. An assessment scoped to the plant boundary will not find a modem on a tower six miles away.

The Relevant Consequence Is Not Data Loss

In MITRE ATT&CK for industrial control systems (ICS) terms, the consequences at stake are denial or loss of view, denial or loss of control, and manipulation of view or control [4]. A physical process can continue running while operators lose the ability to see or influence it. Manipulation is the more dangerous case, because the process may be in a state that differs from what the screens report — precisely the scenario AA26-097A describes when it documents altered operator display data [1][3]. Detection strategies built around data exfiltration will not register any of this.

Advisory Volume Exceeds Absorption Capacity

Four days is a short interval between an advisory update and a sector-wide incident, but the underlying advisory was nearly four months old. The constraint is not awareness. It is the engineering time to inventory controllers, establish logic baselines, remove internet exposure and rehearse manual operation — work that competes with statutory obligations for water quality, capital works and day-to-day service delivery.

Attribution Absorbs Attention That Belongs Elsewhere

Whether the Minnesota incidents prove to be Iranian-affiliated changes very little about the required response. The controls that reduce exposure to this activity are the same controls regardless of who is behind it, and waiting for attribution before acting concedes time to the adversary.

How IOActive Can Help

IOActive’s work in critical infrastructure spans the technical and strategic worlds of OT and ICS security, from the semiconductor inside a controller to the governance program around it. Our team has operated in ICS environments since building the first proof-of-concept worm against the smart grid in 2009 [20], and has helped define standards and best practices including NIST 800-53 and 800-37. The two gaps this incident exposes are assessment problems before they are tooling problems: assessment scope that stops at the plant boundary and misses remote, cellular-connected assets, and the absence of an authoritative baseline against which controller logic can be validated. The services below address each directly.

Full Stack Security Assessments

Most providers scan at the network or application layer only. Our Full Stack Security Assessments examine the entire environment, drilling down to the facility and silicon level and up through the personnel, process, and supply-chain layers around it. For a water or wastewater operator, that means scoping to the whole estate rather than the plant boundary — the towers, lift stations and pump stations that report back over cellular modems, the OT/IT boundary, and the third-party managed links that are frequently the only route in. Drawing on our hardware research background, it also extends to the firmware and silicon of PLC and human-machine interface (HMI) devices themselves through penetration testing, reverse engineering, side-channel analysis, and fault injection. It is the same class of work behind our research Compromising Industrial Facilities from 40 Miles Away, which showed how a memory-corruption flaw in widely deployed industrial wireless automation devices could be exploited remotely to disable field sensor nodes — exactly the kind of remotely reachable field connectivity that Plymouth’s disclosure points to [18].

Red Team and Purple Team Services

Manipulation of view and control is the consequence class that matters here, and it is precisely what adversarial testing exists to surface. Our Red Team engagements emulate the tradecraft AA26-097A describes, including the “living off the land” use of vendors’ own engineering software in place of exploits, while our Purple Team work translates those findings into measurable improvements in whether your operators and analysts would actually detect unauthorized logic changes in time to act. It is the tabletop in step 6 below, run against the live environment rather than a whiteboard. IOActive research has repeatedly shown how attackers can blind the humans in the loop: our study SCADA and Mobile Security in the IoT Era found that more than 20% of the vulnerabilities identified across dozens of ICS mobile applications could let an attacker misinform operators or influence the industrial process directly [19].

Supply Chain Integrity

Where control system architecture is delivered by an integrator, connectivity decisions — including secondary and backup communication paths — are frequently made outside the asset owner’s visibility, and AA26-097A documents the vendors’ own configuration software being used as the access channel. Our Supply Chain Integrity service assesses the security posture of technology providers and critical third parties, reviewing firmware, embedded systems, remote-access arrangements, and procurement processes for inherited risk before it becomes an incident vector. Under the UK Cyber Security and Resilience Bill, suppliers to regulated entities will carry obligations of their own [16].

Secure Development Lifecycle

The advisory urges device manufacturers to adopt secure-by-default design rather than leaving operators to compensate for exposed controllers [1]. For the vendors and OEMs in the PLC, remote terminal unit (RTU) and HMI supply chain, our Secure Development Lifecycle work embeds security review into design and engineering — from threat modeling through code review and pre-release testing — so that the next generation of devices does not ship with the internet-reachable defaults this campaign depends on.

Advisory Services

Removing internet exposure is an architectural program, not a one-time patch, and there is no CVE here to wait for. Our Advisory Services — spanning programmatic security review, security program development and management, and Virtual CISO support — help water sector leaders and boards turn an advisory into a prioritized remediation plan, close the gap between a warning being issued and a warning being actioned, and prepare for the reporting obligations that arrive with an incident: Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) timelines in the US, and current and forthcoming NIS duties in the UK [15][16].

What Are the Recommended Next Steps for Operators?

Establish whether any controller is reachable from the internet. This means verification against the live estate, not a review of the network diagram. Include devices reached over cellular, satellite, radio and any third-party managed link, in line with the joint NCSC-UK, CISA and FBI secure connectivity principles for OT [13].
Extend assessment scope to every remote asset. Towers, lift stations, pump stations and any site with an independent communications path. Where an integrator built the connectivity, request the full inventory of links in writing.
Capture an offline logic and configuration baseline for every controller. This is both a detection capability and a recovery capability. Without it, comparing running logic to known-good logic — the core of the advisory’s new detection guidance — is not possible.
Apply the AA26-097A mitigations directly. Remove direct internet exposure, change default credentials on PLCs and HMIs, enforce multi-factor authentication on all remote OT access, and enable controller key switches or run/program mode protections where the platform supports them [1][3].
Ingest the refreshed indicators and hunt for engineering software activity. Look specifically for vendor engineering tooling running on hosts that are not designated engineering workstations, and for connections to controllers from unexpected sources [1].
Rehearse the manipulation scenario, not the outage scenario. Run a tabletop in which operator displays report normal conditions while the process deviates. The exercise should establish how staff would detect the discrepancy, what independent instrumentation exists, and how manual operation would be initiated and sustained.
Verify that incident reporting obligations are understood before they are triggered. For US utilities, CIRCIA reporting timelines; for UK operators, current and forthcoming NIS obligations under the UK Cyber Security and Resilience Bill [15][16].

Conclusion

The Minnesota utilities appear to have avoided serious consequences largely because staff reverted to manual operation and contingency plans held. That is a real result, and it reflects institutional competence that deserves acknowledgment. It is also a thin margin, and it depended on operators noticing that something was wrong.

The uncomfortable element of this incident is not that it happened without warning. It is that the warning was issued, updated, distributed through federal channels and sector information sharing and analysis centers (ISACs), and reported in the trade press — and the interval between that warning and disrupted controls in more than 30 communities was four days. Advisories are only a control if the organization receiving them has the capacity to act. For much of the water sector, on both sides of the Atlantic, that capacity is the constraint that needs addressing, and it will not be resolved by another advisory.

If you would like to discuss how your organization’s controller exposure and remote-asset connectivity measure up against the activity described here, or how IOActive can support your OT/ICS resilience program, we welcome the conversation.

References

[1] CISA, FBI, NSA, EPA, DOE, CNMF and US Department of the Treasury. Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure (AA26-097A), published April 7, 2026, updated July 22, 2026. https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-097a

[2] Internet Crime Complaint Center (IC3). Advisory AA26-097A (PDF), July 22, 2026. https://www.ic3.gov/CSA/2026/260722.pdf

[3] WaterISAC. (TLP:CLEAR) CISA Updates Iranian-Affiliated PLC Targeting Advisory (AA26-097A), July 2026. https://www.waterisac.org/tlpclear-cisa-updates-iranian-affiliated-plc-targeting-advisory-aa26-097a

[4] E. Kovacs. Dozens of Minnesota Water Utilities Targeted in Coordinated OT Attacks, SecurityWeek, July 29, 2026. https://www.securityweek.com/dozens-of-minnesota-water-utilities-targeted-in-coordinated-ot-attacks/

[5] Coordinated Cyberattack Targets 30+ Minnesota Water Systems as One Plant Goes Offline, The Hacker News, July 2026. https://thehackernews.com/2026/07/coordinated-cyberattack-targets-30.html

[6] Authorities investigating a coordinated cyberattack against Minnesota water systems, Cybersecurity Dive, July 28, 2026. https://www.cybersecuritydive.com/news/authorities-investigating-a-coordinated-cyberattack-against-minnesota-water/826427/

[7] Coordinated cyberattack disrupts water utilities in 30+ Minnesota communities, StateScoop, July 28, 2026. https://statescoop.com/coordinated-cyberattack-disrupts-water-utilities-in-30-minnesota-communities/

[8] Hackers target over 30 Minnesota water utilities in coordinated OT attack, BleepingComputer, July 29, 2026. https://www.bleepingcomputer.com/news/security/hackers-target-over-30-minnesota-water-utilities-in-coordinated-ot-attack/

[9] City of Braham. Cyber security incident statements, July 2026. https://brahammn.gov/

[10] City of Plymouth. News release, July 2026. https://www.plymouthmn.gov/Home/Components/News/News/8977/542

[11] City of South St. Paul. News release, July 2026. https://www.southstpaulmn.gov/m/newsflash/Home/Detail/900

[12] City of Maple Plain. Press Release: Cyber Security Incident, July 2026. https://www.mapleplainmn.gov/administration/page/press-release-cyber-security-incident

[13] NCSC-UK, CISA, FBI and international partners. Secure Connectivity Principles for Operational Technology, January 2026. https://www.cisa.gov/news-events/news/cisa-uk-ncsc-fbi-unveil-principles-combat-cyber-risks-ot

[14] Testimony before the US Senate Committee on Environment and Public Works. The Cybersecurity State of the Water Sector, February 4, 2026. https://www.epw.senate.gov/public/_cache/files/5/3/53d93dfe-ed8c-4e48-b705-0b16cb92c90a/FA38A32EE48D7F3D4B0C069FDC08A69E6327376EB85838A03310B2E91C8582C1.02-04-2026-dr.-simonton-testimony.pdf

[15] Nossaman LLP. Water Utilities: Congress Temporarily Extends Cyber Laws, EPA Releases New Guidance, November 2025. https://www.nossaman.com/newsroom-insights-water-utilities-congress-temporarily-extends-cyber-laws-epa-releases-new-guidance

[16] House of Lords Library. Cyber Security and Resilience (Network and Information Systems) Bill: HL Bill 32 of 2026–27, June 2026. https://lordslibrary.parliament.uk/research-briefings/lln-2026-0032/

[17] ComplianceHub. CISA Updates AA26-097A: Iranian-Affiliated PLC Targeting Widens to Schneider and Siemens, July 2026. https://compliancehub.wiki/cisa-aa26-097a-update-iranian-plc-targeting-critical-infrastructure-july-2026/

[18] IOActive. Compromising Industrial Facilities from 40 Miles Away (white paper). https://www.ioactive.com/wp-content/uploads/2018/05/IOActive_Compromising_Industrial_Facilities_from_40_Miles_Away.pdf

[19] IOActive (A. Bolshev, I. Yushkevich). SCADA and Mobile Security in the IoT Era. https://www.ioactive.com/scada-and-mobile-security-in-iot-era/

[20] M. Davis, IOActive. Advanced Metering Infrastructure (Smart Grid) Device Security, Black Hat USA 2009. https://blackhat.com/presentations/bh-usa-09/MDAVIS/BHUSA09-Davis-AMI-SLIDES.pdf

AI & MACHINE LEARING, INSIGHTS | August 6, 2026

Security Challenges in AI Adoption: 2026

By IOActive

Security professional using a laptop to review AI code

As enterprise AI adoption accelerates in 2026, organizations are discovering that deploying AI responsibly requires a fundamentally different security approach. AI is now embedded in development pipelines, customer-facing applications, operational workflows, and automated decision-making systems. Each deployment extends the attack surface in ways that existing security controls were not built to detect or contain.

This article breaks down the most significant security challenges in AI adoption for Global 1000 enterprises, supported by current research and IOActive’s adversarial testing experience. Attackers are exploiting the risks documented here right now, and every one of them can be measured and tested. For security leaders building the internal case for AI security investment, the benchmarks and risk categories below provide the data to start that conversation.

Security Challenges in AI Adoption in 2026

Enterprise AI Security Challenges at a Glance

Security Challenge	Primary Attack Vector	Documented Exposure Rate	Detectable by Traditional Tools?	Assessment Method
AI-Generated Code Vulnerabilities	Insecure code deployed without security review	31.6% of AI-generated code samples are fully exploitable²	Partial	Adversarial code review and automated scanning
Prompt Injection	Direct or indirect input manipulation	Present in 73%+ of tested LLM deployments¹	Rarely	Adversarial red-teaming
Data Leakage via AI Tools	Employee input, RAG over-disclosure, memorized training data	50% of organizations expect a breach via AI tools in 12 months³	Rarely	Pipeline security review
Shadow AI Incidents	Unauthorized AI tool adoption outside approved channels	49% of organizations expect incidents in 12 months³	No	Inventory and governance review
Training Data Poisoning	Upstream supply chain contamination	Growing; no established baseline	Very difficult	Data provenance audit
Third-Party Model Risk	Pre-trained models, external inference APIs	97% of organizations had a supply chain breach in 2025⁴	No	Architecture review
Agentic AI Misuse	Prompt engineering, agent manipulation	40% of enterprise apps will include AI agents by end of 2026⁵	Very difficult	Threat modeling
AI Governance Gaps	Fragmented ownership, absent or ad hoc policy	70% of organizations lack optimized AI governance³	N/A	Program efficacy assessment

AI Application Security: Where Traditional Controls Fall Short

AI-enabled applications introduce attack surfaces that standard penetration testing was not designed to probe. When a model sits between user input and backend systems, the authorization boundary shifts in ways that static analysis and WAF rules cannot capture. Traditional security testing verifies that code executes as intended. AI security testing must verify that a model behaves as intended across adversarial inputs it was never built to anticipate.

How Tool-Calling Chains Expand the Attack Surface

Tool-calling features are pathways that allow AI models to take actions in connected systems, such as accessing files, querying databases, or triggering API calls. These are among the most exploitable surfaces in deployed AI stacks. A successful attack against a tool-calling chain does not require shell access; it requires a crafted input that persuades the model to act against its operator’s intent.

What the Research has Found in 2026

IOActive’s 2026 research quantifies how broadly this problem affects AI in production. In an evaluation of 27 leading AI models using 730 real-world programming prompts across 27 programming languages and 219 vulnerability categories, average security performance across all models was just 59%.² Nearly one-third of AI-generated code samples (31.6%) were fully exploitable, and no model achieved 100% secure output.² Even the best-performing configuration produced 90 vulnerabilities.² Infrastructure and DevOps code, including Dockerfiles, Terraform configurations, and CI/CD pipelines, exceeded 70 to 97% vulnerability rates.²

The practical takeaway is direct: organizations using AI in software development must treat AI-generated code as untrusted input requiring mandatory security review before deployment, particularly for authentication, cryptography, and infrastructure.

Traditional Application Security vs. AI Application Security

Dimension	Traditional Application Security	AI Application Security
Primary attack surface	Code logic, APIs, and user inputs	Prompts, model behavior, tool-calling chains
Testing approach	Static and dynamic analysis	Adversarial red-teaming, behavioral evaluation
Attack success prediction	Deterministic	Probabilistic
Authorization bypass method	Credential theft, injection	Prompt manipulation, context override
Data leakage path	Database exfiltration	Model output, RAG retrieval over-disclosure
Governing framework	OWASP Top 10	OWASP LLM Top 10, MITRE ATLAS

Prompt Injection: The Most Prevalent and Exploitable AI Vulnerability

Prompt injection holds the top position in OWASP’s LLM Top 10 (ranked LLM01:2025) for a measurable reason. It appears in over 73% of tested LLM deployments¹ and carries attack success rates of 50 to 84% against unprotected systems, depending on configuration.⁶ In 2025, researchers documented over 461,640 prompt injection submissions in a single dataset, confirming that this attack class is being weaponized at scale.⁷

Why Prompt Injection Is a Structural Problem

Prompt injection is the AI equivalent of social engineering the system itself. An attacker submits instructions disguised as normal input, and the model follows them instead of its original instructions. Because large language models process operator instructions and user input through the same channel, this vulnerability is structural, not a configuration error that can be patched away.

Direct and Indirect Injection: How Attacks Are Delivered

The two dominant variants are direct injection, arriving through the user interface, and indirect injection, embedded in content that the model retrieves as context, including documents, emails, and database records. IOActive’s AI application assessments test both variants, as well as chained injection across multi-step workflows and persistent injection that survives into model memory or session history. Every finding is delivered with prompts and replay harnesses so engineering teams can reproduce, regression-test, and track remediation.

“The greatest AI security risks rarely originate in the model itself; they emerge from how AI systems interact with data, applications, and business processes.”

Prompt Injection Types, Delivery Methods, and Risk Levels

Injection Type	Delivery Method	Potential Impact	Execution Difficulty
Direct injection	User input via chat interface	System prompt override, sensitive data disclosure	Low
Indirect injection	RAG context, documents, email content	Exfiltration, unauthorized API calls	Medium
Chained injection	Multi-step agent workflow	Full pipeline compromise	High
Persistent injection	Model memory or session history	Recurring unauthorized behavior	High

Data Leakage, Shadow AI, and Training Data Integrity

AI systems process, memorize, and sometimes reproduce sensitive data in ways that fall entirely outside traditional data loss prevention models. The risk operates at two distinct levels: what the model was trained on, and what it is exposed to at inference time.

Training-Level Risk: What Models Memorize

At the training level, models can memorize specific records from their training data, including personally identifiable information, internal documents, and proprietary source code. IOActive’s adversarial evaluation methodology includes membership inference testing, which determines whether specific data has been memorized by a model rather than inferred from general training patterns. In enterprise fine-tuned models, sensitive training data can surface in model outputs under targeted prompting conditions, and no application-layer control will catch it after deployment.

At the inference level, 50% of organizations expect data loss caused by AI tools within the next 12 months.³ Employees entering customer records, regulated data, or internal strategy documents into third-party AI applications create a leakage path that exists entirely outside security visibility and DLP enforcement. Shadow AI compounds this exposure: 49% of organizations expect incidents from unauthorized AI tool adoption within the same timeframe.³ These tools process real business data while remaining invisible to security monitoring and data classification controls.

AI Data Leakage Pathways and Mitigation Approaches

Leakage Pathway	Source	Detectable by Standard DLP?	Mitigation
Training data memorization	Fine-tuned enterprise models	No	Membership inference testing
Inference-time user input	Employee-entered prompts	Partial	Policy enforcement, input filtering
RAG retrieval over-sharing	Vector database query results	No	Access scoping, retrieval audit
Model output over-disclosure	AI assistant or chatbot responses	Rarely	Output filtering, red-teaming
Shadow AI tool adoption	Unauthorized external applications	No	Inventory, governance, monitoring

Third-Party Model Risk and AI Supply Chain Exposure

Most enterprise AI deployments don’t start from scratch. They rely on pre-trained foundation models, open-source frameworks, third-party datasets, and external inference APIs. Each dependency introduces a trust assumption that few organizations have formally assessed.

Why AI Supply Chain Risk Is Broader Than Traditional Software Risk

OWASP’s LLM03:2025 Supply Chain classification identifies AI supply chain vulnerabilities across training data, models, and deployment platforms. The scope is broader than traditional software supply chain risk: a model’s behavior is directly shaped by its training provenance. A foundation model built on manipulated or low-quality data carries those defects into production, and application-layer security controls cannot correct them after deployment.

The Scale of Current Exposure

The broader supply chain risk baseline is severe. In 2025, 97% of organizations experienced at least one supply chain breach, a 20% increase from 2024.⁴ Software engineering teams account for nearly 50% of enterprise AI use,⁸ meaning AI-generated code is entering software supply chains at a volume that manual review alone cannot keep pace with.

How IOActive Assesses Third-Party Model Risk

IOActive’s third-party model risk assessments cover model signing and artifact lineage, access privileges around model weights, and deployment integrity testing. Threat modeling is aligned to MITRE ATLAS, the adversarial threat landscape framework built specifically for AI systems, so findings connect directly to real-world attack patterns rather than abstract risk categories.

Third-Party AI Risk Areas and Assessment Methods

Risk Area	Key Assessment Questions	Assessment Method
Foundation model provenance	Who trained it? On what data?	Architecture review
Model integrity	Is the model signed? Has it been modified in transit?	Integrity and custody testing
Inference API exposure	What data transits external inference endpoints?	Penetration testing
Open-source dependencies	Are framework vulnerabilities patched and tracked?	Dependency and code audit
Training data provenance	Is training data labeled, validated, and auditable?	Data pipeline security review
Artifact lineage	Can high-influence training samples be identified?	Pipeline assurance review

Agentic AI: When Autonomous Systems Inherit Your Risk Surface

Agentic AI refers to AI systems that take actions independently, without waiting for human approval at each step. They can browse the web, send emails, execute code, call APIs, and trigger workflows autonomously. Gartner predicts that 40% of enterprise applications will incorporate these task-specific AI agents by the end of 2026, up from fewer than 5% in 2025.⁵ Deloitte’s 2026 State of AI report anticipates that 75% of companies will use agentic AI to some degree by 2028.⁹

The Permission Problem: Why Agentic Systems Are Inherently High-Risk

To operate effectively, agents require broad cross-environment permissions, including access to files, APIs, email systems, payment workflows, and production databases. Many AI tools connecting to external systems currently operate in a trust-by-default mode, creating significant vulnerabilities.¹⁰ When an agent is manipulated through prompt injection, the blast radius extends to every system that agent can reach. In multi-agent systems, a compromised upstream agent can propagate malicious instructions to downstream agents before any human checkpoint has the opportunity to intervene.

What Agentic AI Attacks Look Like in Practice

Attack scenarios are concrete. Indirect prompt injection embedded in a retrieved document can cause an agent to forward sensitive files, execute unauthorized API calls, or authorize transactions, all without user interaction. Identity and access management risks expand dramatically in these environments: agent credentials and permissions require the same rigor as for human users, yet most organizations have not yet built that infrastructure.

IOActive’s threat modeling for agentic systems traces attacker paths across SDKs, agents, plugins, and the surrounding supply chain. Exposures are mapped to ATLAS-style TTPs, the AI-specific adversarial technique catalog, so that detections and guardrails emerge as engineering tasks with clear owners rather than policy abstractions without enforcement.

Agentic AI Attack Scenarios and Business Impact

Attack Scenario	Entry Point	Agent Action	Business Impact	Recommended Assessment
Prompt injection via retrieved document	RAG or email context	Forwards sensitive files externally	Data exfiltration	AI Application Security Assessment; Prompt Injection Testing
Chained agent manipulation	Compromised upstream agent	Propagates malicious task downstream	Cascading unauthorized system access	Agentic AI Threat Modeling; Red Team Exercise
RAG-based indirect injection	Vector database retrieval	Executes unauthorized API calls	Unauthorized transactions or data modifications	AI Pipeline Security Assessment; RAG Architecture Review
Excessive permissions abuse	Misconfigured agent identity	Deletes or modifies production data	Data loss, operational disruption	Agentic AI Architecture Review; Identity and Access Management Review
Multi-agent trust exploitation	Inter-agent communication channel	Escalates privileges across systems	Lateral movement, IP theft	Full-Scope Red Team Exercise; Agentic AI Threat Modeling

AI Governance: The Structural Security Challenge Behind Every AI Adoption Decision

Most AI security failures share a common root cause: governance structures that haven’t kept pace with deployment speed. Proofpoint’s 2025 State of AI Security research found that 70% of organizations lack optimized AI governance, and 39% operate with no AI-specific governance at all.³ These organizations are deploying AI while simultaneously expecting data loss events and shadow AI incidents within the next 12 months.

The Ownership Fragmentation Problem

Ownership fragmentation compounds the problem. CIOs control 29% of AI security decisions, while CISOs rank fourth at 14.5%.³ That distribution reflects an AI adoption curve that outran the security function entirely. Effective AI governance requires unified ownership, board-level risk visibility, and continuous monitoring. Those capabilities don’t emerge naturally from a model where each function applies different controls to different risk definitions.

Building the Internal Case for AI Security Investment

For security leaders working to build internal momentum around AI risk, the business case is now straightforward: nearly one-third (31%) of organizations are redirecting their largest security investment toward AI supply chain security over the next 12 months.³ Organizations deploying AI ahead of a governance framework are also accumulating compliance exposure as AI-specific audit requirements mature across financial services, critical infrastructure, and government sectors, including CREST-aligned assessments and Cyber Essentials mandates increasingly applied to vendor supply chains.

Establishing Your Baseline

Reaching a governed state requires knowing where you stand today. An independent AI security assessment establishes the baseline across model behavior, pipeline integrity, application security, and governance maturity so that improvements can be sequenced, budgeted, and measured.

AI Governance Maturity Levels

Governance Maturity Level	Description	Est. % of Organizations	Primary Risk
None	No AI-specific governance in place	3%³	Uncontrolled and unmeasured AI deployment
Ad hoc	Informal practices, no documentation	16%³	Inconsistent controls, high shadow AI exposure
Defined	Documented framework, limited enforcement	20%³	Framework exists; enforcement gaps create exposure
Managed	Measured effectiveness and reporting	31%³	Controls in place but not continuously optimized
Optimized	Board visibility, automated monitoring, incident-driven updates	30%³	Closest to secure; still requires adversarial validation

Frequently Asked Questions

What is the most commonly exploited AI security vulnerability in enterprise environments?

Prompt injection holds the top position in OWASP’s LLM Top 10 and appears in over 73% of tested LLM deployments.¹ Its success rate against unprotected systems ranges from 50 to 84%, making it the first vulnerability class to address in any structured AI security assessment.⁶

How does AI security testing differ from standard penetration testing?

Standard penetration testing validates code execution paths, authentication controls, and API security. AI security testing additionally requires adversarial evaluation of model behavior, prompt injection testing across direct and indirect attack vectors, membership inference analysis (which confirms whether sensitive data was memorized by the model rather than inferred), training data poisoning assessment, and model extraction simulation. IOActive’s AI security assessments cover the full stack, from model and pipeline through application and infrastructure, with findings delivered as reproducible, engineering-ready remediation tasks.

What governance steps should organizations prioritize before expanding AI deployment?

Establish an AI system inventory, assign unified ownership of AI security decisions to the CISO function, and define data handling policies for AI tools before expanding deployment. Treat AI-generated code as untrusted input requiring mandatory security review, particularly for authentication, cryptography, and infrastructure configurations. An independent assessment of existing deployments is the fastest path to identifying where governance gaps create measurable exposure and where emerging compliance requirements may impose near-term deadlines.

What makes agentic AI uniquely risky compared to traditional AI deployments?

Traditional AI deployments produce outputs that a human reviews before acting. Agentic systems take actions autonomously across multiple systems at machine speed. When a manipulated agent can send emails, authorize payments, delete files, and call APIs without a human approval step, the blast radius of a single successful injection attack is orders of magnitude larger than in a passive AI deployment.

Conclusion

The security challenges in AI adoption in 2026 are measurable, documented, and addressable with the right adversarial methodology. Prompt injection succeeds against 50 to 84% of unprotected systems. Nearly one-third of AI-generated code is fully exploitable by default. Seventy percent of organizations lack the governance structures needed to detect or contain AI-related incidents. Those are the current baselines, not the inevitable outcomes. Organizations that instrument their models, secure their pipelines, enforce governance, and apply adversarial testing as a standard part of AI delivery are the ones that move through enterprise AI adoption with the least exposure and the clearest audit trail.

With more than 25 years of independent security research, physical testing labs across three continents, and a track record of identifying emerging threats before they reach headline status, IOActive brings the depth that enterprise AI security demands.

Schedule an AI Security Assessment with IOActive

Sources

1.) Obsidian Security. “Prompt Injection Attacks: The Most Common AI Exploit in 2025.” obsidiansecurity.com/blog/prompt-injection

2.) IOActive. “The Security Gap in AI-Generated Code.” April 2026. ioactive.com/the-security-gap-in-ai-generated-code/

3.) Proofpoint. “The State of AI Security 2025.” proofpoint.com/us/resources/threat-reports/state-ai-security-2025

4.) Atlas Systems. “Third-Party Risk Management Statistics.” atlassystems.com/blog/third-party-risk-management-statistics

5.) Gartner. “Gartner Predicts 40 Percent of Enterprise Apps Will Feature Task-Specific AI Agents by 2026.” August 2025.

6.) Vectra AI. “Prompt Injection: Types, Real-World CVEs, and Enterprise Defenses.” vectra.ai/topics/prompt-injection

7.) Securance. “Prompt Injection: The OWASP #1 AI Threat in 2026.” securance.com/blog/prompt-injection-the-owasp-1-ai-threat-in-2026

8.) Zscaler ThreatLabz. “AI Security Report 2026.” zscaler.com/resources/industry-reports/threatlabz-ai-security-report-2026.pdf

9.) Deloitte. “State of AI 2026.” deloitte.com/content/dam/assets-zone3/us/en/docs/services/consulting/2026/state-of-ai-2026.pdf

10.) Recorded Future. “Emerging Enterprise Security Risks of AI.” recordedfuture.com/research/emerging-enterprise-security-risks-of-ai

INSIGHTS | August 4, 2026

Cyber Attack Trends 2026: What Security Teams Face

By IOActive

Cyber Attack Trends 2026 at the Silicon Level; Firmware, Silicon, Software Supply Chains, Industrial Control Systems.

“The most significant cyber attacks of 2026 will target the systems organizations depend on most, not the systems they monitor most closely.”

Most cybersecurity forecasts treat ransomware, AI-enabled attacks, and supply chain risks as parallel threats of equal weight; a framing that produces the wrong priorities for security teams protecting complex organizations. The cyber attack trends in 2026 share a specific characteristic: they exploit environments organizations depend on most but monitor least, from industrial control systems running legacy protocols to firmware supply chains lacking integrity verification. This article evaluates which attack patterns represent confirmed, active risk across key threat categories.

Threat	Key Risk Indicator	Level of Concern	Recommended Assessment
Ransomware Targeting OT and critical infrastructure	$74B global damage projected¹	Escalating	Red team, OT security assessments
Software Supply Chain Attacks Build pipelines, open-source dependencies	$80.6B cost projection by 2026²	Underestimated	Secure development lifecycle (SDL)
OT/ICS Threats PLCs, RTUs, engineering workstations	3,300+ industrial orgs impacted³	Underdetected	OT/ICS security assessment
AI-Enabled Attacks Dev pipelines, social engineering	31.6% of AI code fully exploitable⁴	Mixed: some confirmed, some speculative	Secure code review, SDL
Critical Infrastructure Cyberattacks Energy, water, transport, defense	$4.82M average breach cost⁵	Underreported	Full-stack ICS/OT assessment

Ransomware: From File Encryption to Operational Disruption

Ransomware groups have moved beyond encrypting files and demanding payment. The operational model has shifted toward the targeted disruption of systems that organizations cannot quickly stop or replace.

Ransomware incidents reached 6,500 in 2025, up from under 1,400 in 2020, a more than 360% increase over five years.⁶ Global damage costs are projected to reach $74 billion in 2026, a 30% increase from $57 billion in 2025.¹ For organizations in critical sectors, the average breach cost stands at $4.82 million per incident, excluding production loss and regulatory response.

Ransomware Characteristic	Traditional Model (Pre-2022)	2026 Model	Recommended Assessment
Primary objective	File encryption, ransom demand	Operational disruption plus ransom	OT incident response planning
Target selection	Opportunistic, volume-based	Sector-targeted, timing-aware	Threat modeling
OT environment knowledge	Low	Active, documented reconnaissance	OT security assessment
Recovery timeline	Hours to days (IT)	Days to weeks (OT)	OT business continuity review
Payment pressure lever	Threat of data exposure	Extended process downtime	Red team exercise

How Threat Groups Are Targeting OT Environments

The threat model has changed in a specific way. Groups with OT knowledge now time attacks around operational windows: peak demand periods for energy utilities, scheduled maintenance cycles at manufacturers, pre-harvest windows in agricultural processing. Dragos tracked 3,300 industrial organizations affected by ransomware in 2025.³ These are not random hits. They reflect adversaries who understand operational context well enough to maximize financial leverage.

What Separates Fast Recovery From Extended Downtime

Organizations recovering fastest from ransomware incidents are those that have run realistic OT continuity exercises against adversary scenarios. Applying untested IT recovery playbooks to industrial environments results in extended downtime because the two environments fail differently and recover on different timelines.

Software Supply Chain Attacks: The Dominant Third-Party Risk Vector

The SolarWinds compromise in 2020 demonstrated that trusted software update mechanisms could deliver malware to thousands of organizations simultaneously. The XZ Utils backdoor in 2024 showed that state-sponsored actors were willing to invest years in maintaining access to open-source projects before activating a payload. Neither incident was an outlier. Both represent a confirmed shift in how sophisticated threat actors approach access at scale.

Supply Chain Attack Type	Notable Case	Detection Difficulty	Downstream Scope	Recommended Assessment
Software build tool compromise	SolarWinds (2020)	High	18,000+ organizations	Secure development lifecycle (SDL) review
Open-source package backdoor	XZ Utils (2024)	High	Millions of Linux systems	Software composition analysis
Firmware implant	Vendor hardware (multiple)	Very high	Full device lifecycle	Firmware security assessment
AI model poisoning	Emerging (2025–2026)	Very high	Development pipelines	AI supply chain review
Hardware and silicon-level attack	AMD Sinkclose (2024)⁷	Extremely high	Endpoint device fleets	Silicon security assessment

Third-Party Risk Is Growing Faster Than Programs Can Track

Third-party involvement in security breaches rose from 15% to 30% in 2025.² Supply chain attack costs are projected to exceed $80.6 billion by 2026.² The attack surface is not shrinking: organizations now average over 1,000 third-party vendors, and the majority lack visibility into the security posture of their software dependencies beyond first-tier vendors.

One Compromise Can Expose Every Downstream Organization

The risk is systemic, not incidental. A single compromise of a widely used build tool, package manager, or firmware update process exposes every downstream organization that relies on it. Your environment’s security now depends in part on the security of every component that touches your build pipeline, whether or not you have audited it.

OT/ICS Threats: Adversaries Mapping Physical Processes

The 2026 Dragos OT Cybersecurity Year in Review documents a specific evolution in how adversaries approach industrial environments. They are no longer staging for future disruption. They are actively mapping control loops to understand how to manipulate physical processes with precision.³

OT Threat Group	Primary Target Sector	Documented 2025 Activity	ICS Kill Chain Stage	Recommended Assessment
VOLTZITE	Electric, oil and gas	Gateway compromise, configuration extraction	Stage 2	OT network security assessment
KAMACITE	Energy, water, heating (EU, US)	Four-month ICS reconnaissance campaign	Stage 1	ICS threat hunting
ELECTRUM	Ukrainian, Polish infrastructure	Destructive wiper deployment (PathWiper)³	Stage 2	OT incident response planning
SYLVANITE	US utilities, SAP environments	Zero-day exploitation (CVE-2025-31324)	Stage 1	Vulnerability assessment
BAUXITE	Israeli critical infrastructure	Dual wiper variants deployed	Stage 2	Full-stack ICS/OT assessment

Active OT Threat Groups

Three new OT threat groups emerged in 2025. Established groups expanded operations globally. Dragos now tracks 26 OT threat groups.³ KAMACITE conducted four months of sustained reconnaissance against US internet-exposed ICS assets, targeting specific device types in sequence. VOLTZITE compromised Sierra Wireless Airlink gateways across electric and oil-and-gas sectors, then pivoted to engineering workstations to extract configuration and alarm data. ELECTRUM deployed coordinated destructive wiper malware against eight Ukrainian ISPs and, in December 2025, Polish CHP facilities.³

Why Most Organizations Cannot See the Threat

The visibility problem is structural. Only 30% of OT networks have the monitoring capability to detect these threats before operational impact. 56% of organizations cannot see below the IT/OT boundary. 88% struggle with detection and response in OT environments.³

IOActive’s research into OT security architecture has identified a persistent strategic blind spot. The standard AIC reordering (Availability-Integrity-Confidentiality) used in many OT environments prioritizes availability, which is precisely where the most capable adversaries operate. Stuxnet manipulated centrifuge speeds while feeding false readings to operators for months. Triton/TRISIS targeted Safety Instrumented Systems to remove the safeguard layer before causing process failure. Industroyer sent commands directly to substation equipment using native industrial protocols. All three targeted integrity, not availability, because integrity failures often go undetected, whereas availability failures trigger an immediate response.⁸

AI-Enabled Attacks: Separating Confirmed Risk From Speculation

AI’s role in offensive security requires more precision than most threat briefings provide. The meaningful 2026 risk is not the speculative scenario of fully autonomous AI attackers. It is the measurable deterioration in code security caused by AI-assisted development tools, and the accelerated pace at which phishing and social engineering campaigns now operate.

AI Attack Vector	Operational Maturity	Documented Risk Indicator	Defender Priority	Recommended Assessment
AI-generated insecure code in production	High	31.6% of samples fully exploitable⁴	Critical	Secure code review, SDL
AI-accelerated phishing and spear-phishing	High	Volume and personalization increase confirmed	High	Social engineering assessment
Deepfake-based social engineering and fraud	Medium-High	Active in financial and executive targeting	High	Red team exercise
AI-assisted vulnerability discovery by threat actors	Medium	Being used by advanced groups	Medium	Threat modeling
Autonomous AI attack agents	Low	Demonstration cases only; no confirmed deployment at scale	Monitor only	No immediate action required

AI-Generated Code Is Already a Security Liability

IOActive’s April 2026 whitepaper evaluated 27 leading AI models and AI-powered coding tools using 730 real-world programming prompts across 27 languages and 219 vulnerability categories. Security outcomes were measured against 72 automated vulnerability detectors, producing nearly 20,000 analyzed code samples. The results were direct: average security performance across all models was 59%, and 31.6% of AI-generated code samples were fully exploitable.⁴

No model achieved 100% secure output. Infrastructure and DevOps code (Dockerfiles, Terraform, CI/CD pipelines) produced the worst results, with vulnerability rates between 70% and 97%. Authentication, rate limiting, and cryptography consistently failed across nearly all models.⁴ According to IOActive’s research, GitHub Copilot is now generating nearly half of developers’ code.⁴ Organizations deploying AI coding tools without mandatory security review before production deployment are introducing exploitable risk at scale as a present, documented condition.

Where AI Is Accelerating Offensive Capabilities

The WEF Global Cybersecurity Outlook 2026 found that 87% of respondents identified AI-related vulnerabilities as the fastest-growing cyber risk over 2025.⁹ AI is accelerating phishing volume, enabling more convincing social engineering, and lowering the technical barrier for credential-based attacks.

Critical Infrastructure: The Widening Gap Between Visibility and Exposure

64% of organizations now account for geopolitically motivated cyberattacks against critical infrastructure in their 2026 risk strategies.⁹ 91% of the world’s largest organizations have changed their cybersecurity strategies due to geopolitical volatility.⁹ Awareness has grown. Technical detection coverage has not kept pace with it.

Critical Infrastructure Sector	Primary 2026 Threat Vector	Current Avg. Visibility	Recommended Assessment
Energy (grid and generation)	OT compromise, wiper malware	Low (30% avg. OT visibility³)	Full-stack ICS/OT assessment
Water and wastewater	ICS manipulation, ransomware	Very low	OT network segmentation review
Telecommunications	Supply chain implants, espionage	Medium	Hardware and firmware audit
Transportation	Embedded system attacks, GPS manipulation	Low	Embedded systems assessment
Defense industrial base	Hardware supply chain, insider access	Variable	Silicon-level security review

Active Campaigns Against Energy Infrastructure

The December 2025 coordinated attack on Polish CHP facilities and renewable energy management systems, attributed by Dragos to Russian state-linked actors consistent with ELECTRUM, confirmed that energy infrastructure in NATO-aligned countries is an active target.³ The same month, a new destructive wiper variant from ELECTRUM confirmed an active malware development pipeline. These are not isolated incidents: they reflect sustained, organized campaigns with documented capability to disrupt physical processes.

Where Conventional Monitoring Falls Short

IOActive’s critical infrastructure research spans SATCOM terminal vulnerabilities across aviation, maritime, and military systems; avionics security in DAL-A certified systems; and industrial control assessments across energy, chemical, and defense sectors. That body of work consistently surfaces the same pattern: the most consequential vulnerabilities reside in layers below where most monitoring tools operate. Software-layer monitoring does not detect the reconnaissance and lateral movement techniques being used by the most capable OT threat groups.

For organizations in these sectors, sophisticated adversaries have both the motive and the documented capability to access environments through the layers that receive the least security scrutiny. The more urgent question is whether that access is already established.

Frequently Asked Questions About Cyber Attack Trends 2026

Which of these five threat categories should security teams prioritize first?

OT/ICS threats and software supply chain attacks warrant the highest priority for organizations that have not assessed them recently, because both operate below the visibility threshold of most existing monitoring tools. Ransomware remains the highest-volume threat. AI-enabled attacks require immediate attention in development pipelines. Specifically, autonomous-AI attack scenarios do not warrant the same urgency as the confirmed, active attack patterns documented above.

How should security teams distinguish real business risk from vendor-amplified hype?

Apply two tests. First: Does the threat have documented, confirmed use in real environments, not proof-of-concept demonstrations? Second: Does it target environments your organization depends on but under-monitors? Threats that pass both tests warrant defense investment. Threats that fail the first should be tracked, but should not displace attention from attack patterns already operating at scale.

What makes IOActive’s perspective on attack trends distinct from standard threat intelligence reports?

IOActive’s assessments are grounded in research spanning hardware, firmware, embedded systems, industrial control systems, and live adversarial engagements across industries. Most threat intelligence derives from network-layer telemetry. IOActive’s research includes silicon-level attack techniques, OT protocol analysis, and hardware supply chain evaluation, which is where the most consequential vulnerabilities in 2026 are concentrated. Learn more about IOActive’s Full-Stack Security Assessment approach.

Attackers Target the Layers You Are Not Watching

The cyberattack trends in 2026 share one thing in common: they target the layers that most organizations aren’t watching. IOActive’s research spans silicon, firmware, OT, and live adversarial engagements, giving security teams a complete picture of where real exposure exists and what to do about it.

Schedule a Full-Stack Security Assessment with IOActive

Sources

1. Cybersecurity Ventures, via SLCyber (2026). The True Cost of a Ransomware Attack in 2026. https://slcyber.io/blog/the-true-cost-of-a-ransomware-attack-in-2026/

2. Vectra AI / Think Ahead Tech (2025–2026). Supply chain attack cost and third-party breach data. https://www.vectra.ai/topics/supply-chain-attack; https://think-ahead.tech/en/blog/software-supplychain-security

3. Dragos. 2026 OT Cybersecurity Year in Review. https://www.dragos.com/ot-cybersecurity-year-in-review

4. IOActive. The Security Gap in AI-Generated Code (April 2026). https://www.ioactive.com/the-security-gap-in-ai-generated-code/

5. IBM. Cost of a Data Breach Report 2025, via StationX. https://app.stationx.net/articles/ransomware-statistics

6. Industrial Cyber. Hacktivists and Cybercriminals Expand Attacks on ICS, OT, and AI Systems Across Critical Infrastructure. https://industrialcyber.co/reports/hacktivists-and-cybercriminals-expand-attacks-on-ics-ot-and-ai-systems-across-critical-infrastructure/

7. IOActive. Tales from the Call Gate: AMD Sinkclose Vulnerability (2024). https://ioactive.com/tales-from-the-call-gate-an-smm-supervisor-vulnerability/

8. IOActive. Rethinking the CIA Triad in Operational Technology Environments (2026). https://www.ioactive.com/rethinking-the-cia-triad-in-operational-technology-environments/

9. World Economic Forum. Global Cybersecurity Outlook 2026 (January 2026). https://reports.weforum.org/docs/WEF_Global_Cybersecurity_Outlook_2026.pdf

INSIGHTS | July 27, 2026

Iranian-Affiliated Actors Expand PLC Targeting to Siemens and Schneider Electric: What CISA’s Updated Advisory Means for CNI

By IOActive

Key Takeaways

On 22 July 2026, CISA, the FBI, NSA, and five other US agencies updated joint advisory AA26-097A, expanding the scope of an ongoing Iranian-affiliated campaign against internet-exposed PLCs from Rockwell Automation to now include Schneider Electric and Siemens devices [1].
The update adds a new exfiltration technique (MITRE ATT&CK T1041): actors are using vendors’ own legitimate engineering software to steal PLC project files from victim environments [1].
At one confirmed US victim, actors modified ladder logic to disable safety shutdown and alarm functions, allowing unsafe conditions to develop without alerting operators [1].
Government Services, Water and Wastewater Systems (WWS), and Energy sector organisations are named as directly affected; the multi-vendor scope means the realistic exposure is broader.
New IOCs and mitigation guidance are available, but the core weakness enabling this campaign — internet-exposed OT, often reachable via cellular modems — has been publicly known since at least April 2026 [1][4].

Why This Update Matters Now

Advisory AA26-097A is not a new warning — it was first published on 7 April 2026, when the authoring agencies (FBI, CISA, NSA, EPA, DOE, and US Cyber Command’s Cyber National Mission Force) disclosed active exploitation of internet-exposed Rockwell Automation/Allen-Bradley PLCs by an Iranian-affiliated group [1]. That group has been previously tracked under the CyberAv3ngers alias, tied to Iran’s IRGC Cyber Electronic Command, and is the same actor set implicated in the 2023 Unitronics PLC compromises across US water utilities [5].

The 22 July 2026 update adds new guidance on detecting malicious changes in reusable code modules exploited within Rockwell Automation PLC programs, and expands scope to include observed targeting of Schneider Electric, Siemens, and potentially other branded PLCs [1]. The Department of the Treasury also joined as a co-authoring agency, an addition worth noting given the financial-sector implications of Treasury’s involvement.

For CISOs overseeing critical national infrastructure, the update signals two things: the campaign has not been contained by the original advisory’s mitigations, and the actors’ targeting logic is protocol- and port-based rather than vendor-specific — meaning any internet-exposed PLC, regardless of manufacturer, is realistically in scope.

What Actually Changed in the Update

The July revision is substantive rather than cosmetic. Three additions stand out.

Expanded Manufacturer and Device Scope

The advisory now names specific targeted models: Rockwell’s CompactLogix and Micro850, Schneider Electric’s BMX P34/Modicon M340, and Siemens’ S7-1200 series. Inbound malicious traffic has been observed on ports associated with each vendor’s protocols — 44818 and 2222 for Rockwell, 102 for Siemens, and 502 for Modbus — alongside port 22 targeting on connected cellular modems [1].

A New Exfiltration Technique

For the first time, the advisory documents actors using the vendors’ own configuration software — Rockwell’s Studio 5000 Logix Designer, Schneider Electric’s EcoStruxure Control Expert, and Siemens’ TIA Portal — on leased, third-party infrastructure to pull device project files out of victim environments (MITRE ATT&CK T1041). This is a “living off the land” pattern: no exploit is required, because the tools used are the same ones legitimate engineers and integrators use daily [1].

Confirmed Safety-Logic Tampering

In one documented case, actors downloaded a malicious project file that preserved the PLC’s downstream ladder logic function but overrode the instruction sets responsible for maintaining safe operating parameters — disabling shutdown and alarm logic so operators would not be notified when the system entered an unsafe state. This is the detail that should reframe the conversation for CNI leaders: this is not credential theft or data exposure, it is a direct line to physical-process manipulation [1]. IOActive research has repeatedly shown how attackers can blind the humans in the loop: our study SCADA and Mobile Security in the IoT Era found that more than 20% of the vulnerabilities identified across dozens of ICS mobile applications could let an attacker misinform operators or influence the industrial process directly [7].

Who Is Affected by This Update?

Water and Wastewater Systems Operators

WWS remains a named sector, consistent with the actor group’s history since the 2023 Unitronics campaign [5]. Many WWS facilities rely on cellular-connected PLCs for remote pump stations and field sites — precisely the exposure pattern flagged in this advisory.

Energy Sector Asset Owners

Named alongside WWS, energy sector organisations running any of the three named vendors’ controllers should treat this as a direct exposure notice, not general awareness content.

Government Services and Facilities, Including Municipalities

Smaller municipal operators frequently lack the OT security maturity of larger CNI operators, and their PLC deployments may be exposed without an internal team fully aware of the risk.

Integrators and Managed Service Providers

The advisory specifically calls out that service providers may be maintaining internet connectivity to OT systems for remote monitoring purposes without being aware of active threat targeting — placing a burden on operators to proactively brief their vendors and MSPs [1].

Security Leaders in Adjacent Sectors

Rockwell, Schneider Electric, and Siemens PLCs are used far beyond the three named sectors — in manufacturing, transportation, and building automation. CISOs outside WWS, Energy, and Government Services should not assume this advisory doesn’t apply to them.

Open Questions and Risk Context

Independent research adds useful context the advisory itself doesn’t fully quantify. Censys identified 5,219 internet-exposed hosts globally responding to EtherNet/IP on port 44818 and self-identifying as Rockwell Automation/Allen-Bradley devices when the original advisory was published in April [3] — and a large share of that exposure traced back to cellular carrier networks rather than fixed corporate connections, indicating field-deployed devices such as pump stations and substations reachable through cellular modems as their sole path to the internet. Comparable exposure figures for Schneider Electric and Siemens devices under this expanded campaign have not yet been independently published at the time of writing; organisations should treat any current third-party exposure estimate for those vendors with appropriate caution.

It’s also worth flagging what the advisory explicitly does not claim: this is not a new vulnerability disclosure. The authoring agencies state that this activity reflects opportunistic targeting of exposed devices, not a vendor-specific flaw — device manufacturers are urged to adopt secure-by-default design, but no new CVE is attached to this update [1]. Organisations should not wait on a vendor patch; the primary mitigation is architectural (removing internet exposure), not a fix to be deployed.

Finally, attribution to a specific Iranian-affiliated group beyond the general IRGC-CEC/CyberAv3ngers lineage has not been formally re-confirmed in the July update — the advisory refers to “an Iranian-affiliated APT group” without reasserting the CyberAv3ngers name directly in the new content [1]. CISOs briefing boards should be precise about what is confirmed versus inferred from the group’s historical TTP overlap.

How IOActive Can Help

IOActive’s work in critical infrastructure spans the technical and strategic worlds of OT and ICS security, from the semiconductor inside a controller to the governance programme around it. Our team has operated in ICS environments since building the first proof-of-concept worm against the smart grid in 2009 [8], and has helped define standards and best practices including NIST 800-53 and 800-37. The services below map directly to the exposure pattern AA26-097A describes — internet-reachable PLCs, legitimate engineering tools turned against their owners, and safety logic that can be altered without detection.

Full Stack Security Assessments

Most providers scan at the network or application layer only. Our Full Stack assessments examine the entire environment, drilling down to the facility and silicon level and up through the personnel, process, and supply-chain layers around it. For the exposure this advisory describes, that means identifying internet-facing Rockwell, Schneider Electric, and Siemens controllers, testing the OT/IT boundary and the cellular-modem paths that so often provide the only route in, and — drawing on our hardware research background — examining the firmware and silicon of PLC and HMI devices themselves through penetration testing, reverse engineering, side-channel analysis, and fault injection. It is the same class of work behind our research Compromising Industrial Facilities from 40 Miles Away, which showed how a memory-corruption flaw in widely deployed industrial wireless automation devices could be exploited remotely to disable field sensor nodes — exactly the kind of remotely reachable field connectivity the advisory flags at cellular-connected pump stations and substations [6].

Red Team and Purple Team Services

The advisory’s most alarming detail — actors modifying ladder logic to disable safety shutdown and alarm functions without alerting operators — is exactly the scenario adversarial testing exists to surface. Our Red Team engagements emulate the tradecraft of the Iranian-affiliated actors described here, including the “living off the land” use of vendors’ own engineering software in place of exploits, while our Purple Team work translates those findings into measurable improvements in whether your monitoring would actually detect project-file tampering and unauthorised logic changes in time to act.

Supply Chain Integrity

AA26-097A places a specific burden on integrators and managed service providers maintaining remote connectivity to OT systems, and documents the vendors’ own configuration software — Studio 5000 Logix Designer, EcoStruxure Control Expert, and TIA Portal — being used as an exfiltration channel. Our Supply Chain Integrity service assesses the security posture of technology providers and critical third parties, reviewing firmware, embedded systems, remote-access arrangements, and procurement processes for inherited risk before it becomes an incident vector.

Secure Development Lifecycle

The advisory urges device manufacturers to adopt secure-by-default design rather than leaving operators to compensate for exposed controllers. For the vendors and OEMs in the PLC and HMI supply chain, our Secure Development Lifecycle work embeds security review into design and engineering — from threat modelling through code review and pre-release testing — so that the next generation of devices does not ship with the internet-reachable defaults this campaign depends on.

Advisory Services

Removing internet exposure is an architectural programme, not a one-time patch, and the advisory is explicit that there is no CVE to wait for. Our Advisory Services — spanning programmatic security review, security program development and management, and Virtual CISO support — help CISOs and boards turn this advisory into a prioritised remediation plan, brief leadership with precision about what is confirmed versus inferred regarding attribution, and build the incident readiness to respond if targeting is found in their environment.

What are the Recommended Next Steps?

Inventory PLC exposure immediately. Identify all internet-facing Rockwell, Schneider Electric, and Siemens devices, prioritising the specifically named models (CompactLogix, Micro850, BMX P34/Modicon M340, S7-1200 series).
Query logs against the July 2026 IOCs. Cross-reference the newly published STIX indicators against traffic logs for ports 44818, 2222, 102, and 502, and port 22 on connected cellular modems.
Remove direct internet exposure. Route all remote access through a secure gateway or jump host; do not rely on the device’s built-in access controls alone.
Validate project file integrity. Compare running logic against known-good baselines using vendor integrity tools, with particular attention to Add-On Instructions (AOIs) and safety/alarm logic.
Brief integrators and MSPs directly. Confirm that any third party with remote access to your OT environment is aware of this advisory and has reviewed their own access paths.
Set controllers to RUN mode where physically possible, switching to program mode only for authorised maintenance windows.

Conclusion

The expansion of AA26-097A from a single-vendor warning to a multi-vendor advisory in just over three months is a signal in itself: this is an active, adapting campaign, not a contained incident. For CNI security leaders, the technical specifics matter less than the underlying pattern — internet-exposed OT, reached through legitimate engineering tools, is producing real operational and financial consequences. The organisations that treat this as a one-time patching exercise will likely see a third update to this advisory before the underlying exposure problem is solved.

If you would like to discuss how your organisation’s PLC and control-system exposure measures up against the activity described in this advisory, or how IOActive can support your OT/ICS resilience programme, we welcome the conversation.

References

[1] CISA, FBI, NSA, EPA, DOE, CNMF, Department of the Treasury. Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure (AA26-097A), updated 22 July 2026. https://www.ic3.gov/CSA/2026/260722.pdf

[2] WaterISAC. CISA Updates Iranian-Affiliated PLC Targeting Advisory (AA26-097A), 22 July 2026. https://www.waterisac.org/tlpclear-cisa-updates-iranian-affiliated-plc-targeting-advisory-aa26-097a

[3] Censys. Iranian-Affiliated APT Targeting of Rockwell/Allen-Bradley PLCs, April 2026. https://censys.com/blog/iranian-affiliated-apt-targeting-rockwell-allen-bradley-plcs/

[4] Cybersecurity Dive. Nearly 4K industrial control devices vulnerable to Iran-linked hacking campaign, 10 April 2026. https://www.cybersecuritydive.com/news/critical-infrastucture-plcs-iran-hacking-censys/817209/

[5] CISA. IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities (AA23-335A). https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-335a

[6] IOActive. Compromising Industrial Facilities from 40 Miles Away (white paper). https://www.ioactive.com/wp-content/uploads/2018/05/IOActive_Compromising_Industrial_Facilities_from_40_Miles_Away.pdf

[7] IOActive (A. Bolshev, I. Yushkevich). SCADA and Mobile Security in the IoT Era. https://www.ioactive.com/scada-and-mobile-security-in-iot-era/

[8] M. Davis, IOActive. Advanced Metering Infrastructure (Smart Grid) Device Security, Black Hat USA 2009. https://blackhat.com/presentations/bh-usa-09/MDAVIS/BHUSA09-Davis-AMI-SLIDES.pdf