Written by Liel Alphabet

Exploring a Windows accessibility API led our Cyber Research and Response Unit to a phishing method that never sends an email, never drops a link, and still tricks users into handing over credentials in plain sight.

UIAutomation is Windows’ official way for screen readers and other assistive tools to know which button, link, or textbox has the user’s focus. That benign intent makes security teams overlook it. But in December 2024, Akamai showed how attackers could use the same API to scrape on-screen data without triggering any EDR detections.

That raised a bigger question – could this same framework be abused not just to observe, but to interact, and most importantly, can we detect it and keep our customers protected even from niche techniques like this one?

TL;DR

• The technique: UIAutomation can be used to trigger activities at perfect timings rather than just obtaining information about focused UI elements.
• EDR blind spot: None of the top-tier EDRs flagged this abuse out-of-the-box. it bypassed baseline detection policies.
• Detection workaround: A custom SentinelOne STAR rule targeting UIAutomationCore.dll injections by unsigned processes blocked the behavior successfully.
• Why response matters: Potential persistent way of regaining access to a compromised Microsoft 365 user was never something that was in our minds, Without full root-cause analysis and persistence cleanup, a phishing loop can re-trigger even after password resets.

Briefly about UIAutomation

The Windows UI Automation (UIA) framework is an accessibility interface that allows programs to provide and consume programmatic information about UI elements on the desktop.
It plays a central role in enabling assistive technologies and automated UI testing.

UIA consists of two main components:

• UIA providers: Implemented by UI controls or applications to expose their UI for automation.
• UIA clients: Assistive technologies or automated testers that query or manipulate UI in other applications.

The UIA client API is exposed via COM (Component Object Model) interfaces on Windows. A client creates a CUIAutomation COM object and obtains the main IUIAutomation interface.
Internally, this triggers the loading of the UIAutomationCore.dll library, which implements the core UIA functionality.
UIA uses COM as its inter-process communication (IPC) mechanism, which relies on RPC (Remote Procedure Call) under the hood. When a UIA client subscribes to events or interacts with elements in another process, UIAutomationCore.dll is loaded into the target process.

When an application registers for focus change events, Windows gladly reports every control the user touches.
The control name often includes juicy labels like Sign in, Password, or Confirm Transfer.

Akamai demonstrated sensitive data theft by scraping on-screen text and even spying on Slack messages, we highly recommend checking out their article on the subject.

However, we wanted to probe a different angle: could focus events alone stage a believable phishing prompt and slip past every baseline EDR policy?

From Curiosity to Proof of Concept

Our PoC was built to target Outlook’s webpage login, however, it’s important to mention that it was solely to show how believable and stealthy it could be.
Attackers can reproduce the same technique and implement it in many different ways and login processes. 

Our PoC subscribed to system-wide focus notifications using the UIAutomation API.
When focus shifted to a button whose NameProperty included Sign in, we inferred a login was imminent, no need to inspect password fields.

Upon focus it:

• Obscured the real login experience with sleight-of-hand timing
• Launched a believable login page – in our case, a new browser tab, mimicking the real workflow.

No network lure, macro, or exploit. Just perfect timing.
During tests against five leading EDR products, none raised an alert out-of-the-box.

Unlike traditional phishing, this method doesn’t rely on emails, links, or lures. Instead, it hijacks natural user behavior.
The user initiates a login, and the attacker simply gets there first with a fake prompt, no need for external bait. Even after incident response, the threat can persist. If malware is removed and passwords are reset but persistence mechanisms like scheduled tasks are missed, the phishing prompt can silently return.
The next time the user clicks Sign in, the fake login appears again, and the attacker regains access.

Detection Guidance You Can Deploy Today

SentinelOne STAR rule

event.type = 'Behavioral Indicators' AND indicator.name = 'RemoteLibraryInjection'
AND (
  indicator.metadata contains:anycase 'UIAutomationCore.dll'
  AND
  src.process.signedStatus = 'unsigned'
)

This rule caught our PoC immediately with no false positives in testing, though, like any behavioral rule, tuning may be needed based on your environment.

Sysmon configuration and hunting

• Event ID 7 – Image Load
  POC.exe and chrome.exe both loading UIAutomationCore.dll is your first clue.
  Both the attacker and the target app load UIAutomationCore.dll, a natural side effect of how accessibility events work.
• Event ID 10 – Process Access
  Shows the rogue process reading or writing into the browser. UIAutomationCore.dll surfaces in the call stack.

Collect both events into your SIEM, filter on UIAutomationCore.dll, and enrich with signing status, though tuning may be needed in environments with legitimate UIAutomation usage.

Response Guidance

• Run full root-cause analysis to trace initial compromise
• Remove the implant and every persistence mechanism (registry Run keys, scheduled tasks, startup folders)
• Reboot and verify the DLL is no longer injected after credential resets
• Monitor for any new unsigned binaries loading UIAutomationCore.dll

Detection Gap, and Overcoming It

A single EDR cannot hard-code logic for every environment.
A Centralized Security Operations Platform like CYREBRO adds MDR context and AI anomaly scoring.

This mix lets us spot niche tactics without flooding clients with false positives.

• MDR context – We know which hosts legitimately run screen readers
• AI baselining – Injections involving UIAutomationCore.dll into browsers stand out in our MDR telemetry, with zero false positives to date
• Security Data Lake correlation – Process telemetry aligns with user and network events for high-confidence alerts

Conclusion

UIAutomation is proof that defensive blind spots often hide in plain sight.
By marrying threat research with MDR telemetry, the CYREBRO Cyber Research and Response Unit turned a niche accessibility feature into a reliable detection use case.
Ready to see how our SOC-as-a-Service platform hunts the attacks your EDR misses?

Visit our Managed Detection and Response page or explore the full Centralized Security Operations Platform to learn more.

FAQ

What exactly is being abused in this technique?

The Windows UIAutomation API, originally designed for accessibility, is repurposed to detect user focus on login elements and launch phishing prompts in real time.

Why don’t EDRs catch this by default?

Because UIAutomationCore.dll is a signed Microsoft library used legitimately by assistive software. Most EDRs allow it and don’t monitor who’s injecting it, unless custom rules are in place.

What makes this technique easier to fall victim to?

There’s no bait, no suspicious email or download. The fake login appears as part of the expected workflow, so users don’t question it.

If we reset credentials, is the threat gone?

Not necessarily. If persistence (e.g., scheduled tasks, autoruns) isn’t cleaned, the phishing prompt can reappear the next time the user logs in.