CybserSecurity News

Tag: Windows Security

  • PATCH NOW: Microsoft Fixes 57 Flaws, Including Three Zero-Days Actively Exploited

    Microsoft has released its December security updates: Patch Tuesday brings fixes for 57 vulnerabilities, including three zero-days (one of which is already being actively exploited) and three critical remote-code-execution flaws. Administrators and Windows users are strongly urged to install the patches without delay.

    This month’s bundle includes 28 elevation-of-privilege flaws, 19 remote-code-execution issues, 4 information-disclosure vulnerabilities, 3 denial-of-service bugs, and 2 spoofing weaknesses. The report does not cover 15 Microsoft Edge vulnerabilities or the Mariner bugs addressed in separate early-December updates. For those following feature updates, Microsoft has also released independent bulletins for the latest Windows 11 cumulative updates (KB5072033 and KB5071417).

    The most serious issue of the month is the actively exploited elevation-of-privilege flaw CVE-2025-62221 in the Windows Cloud Files Mini Filter driver. This use-after-free bug enables a local attacker with a valid account to escalate privileges to SYSTEM. It is precisely the sort of vulnerability attackers routinely chain with other bugs: initial access comes first, followed by exploitation of an EoP flaw like this one to seize full control of the host. Microsoft credits MSTIC and MSRC with the discovery but discloses no details regarding attacks already observed in the wild.

    Two additional zero-days fixed in this release had been publicly disclosed prior to patching, significantly increasing the risk of attempted exploitation.

    The first, CVE-2025-64671 in GitHub Copilot for JetBrains IDEs, is a remote-code-execution vulnerability arising from improper filtering of special characters in commands — a classic case of command injection. In essence, an attacker can achieve arbitrary code execution locally if they can induce Copilot to generate or complete a terminal command. Microsoft highlights an especially risky scenario: Cross Prompt Injection, where malicious prompts are embedded in untrusted files or MCP servers. With automatic command confirmation enabled, harmful trailing commands may be silently appended to ostensibly legitimate ones. Researcher Ari Marzuk detailed this flaw in his work “IDEsaster: A Novel Vulnerability Class in AI IDEs,” demonstrating how AI-assisted IDE tooling itself becomes an attack surface.

    The second publicly disclosed zero-day, CVE-2025-54100 in Windows PowerShell, is likewise a command-injection flaw. When using Invoke-WebRequest, scripts embedded in a fetched web page could be executed during parsing. Simply retrieving a page’s contents through PowerShell could therefore trigger arbitrary code execution if the page were malicious.

    As mitigation, Microsoft has changed PowerShell’s behavior: Invoke-WebRequest now displays a warning about the risk of executing scripts from web content and recommends adding the -UseBasicParsing switch to disable advanced parsing and eliminate the execution vector. This is a significant change for administrators and developers who rely heavily on web requests in automation. Legacy scripts should be reviewed and updated to explicitly specify the intended mode of operation.

    Among the critical vulnerabilities, three stand out in Microsoft Office: two RCE flaws in Office (CVE-2025-62554 and CVE-2025-62557) and one in Outlook (CVE-2025-62562). As is typical for this class of bugs, merely opening a specially crafted document or email could permit arbitrary code execution with the user’s privileges. In corporate environments, this remains one of the most reliable vectors for phishing and targeted intrusion campaigns.

    Beyond Office, the update addresses a wide range of vulnerabilities across Windows system components: Windows Storage VSP and ReFS drivers, the Windows Projected File System, Win32k, and Windows Shell. Additional flaws affect Remote Access Connection Manager, Routing and Remote Access Service (RRAS), DirectX, and Hyper-V. Many are classified as Important and may facilitate persistence, isolation bypass, or lateral movement once an attacker has gained a foothold.

    Server products are also impacted: the release fixes privilege-escalation and spoofing flaws in Microsoft Exchange Server, as well as issues in SharePoint Server — making December’s patches particularly critical for administrators of enterprise environments where these services are commonly exposed to the internet.

    Several other vendors have issued December bulletins to accompany Microsoft’s release. Adobe has patched vulnerabilities in ColdFusion, Experience Manager, DNG SDK, Acrobat Reader, and the Creative Cloud client. Fortinet has updated a number of products, including a fix for a critical authentication-bypass flaw in FortiCloud SSO. Google has published the Android December security bulletin, addressing two already exploited vulnerabilities. Ivanti has shipped updates including a CVSS 9.6 XSS fix in Ivanti Endpoint Manager. React has patched the critical React2Shell RCE flaw in React Server Components, already under active exploitation. SAP has corrected numerous issues, including a CVSS 9.9 code-injection vulnerability in SAP Solution Manager.

    Administrators should prioritize installing updates that remediate the actively exploited CVE-2025-62221, the PowerShell issue CVE-2025-54100, and the GitHub Copilot flaw CVE-2025-64671, along with the critical Office and Outlook RCEs and updates for internet-facing servers (Exchange, SharePoint, RRAS). Once these are addressed, remaining Microsoft updates — as well as companion patches from other vendors — should be deployed in a structured rollout. The complete list of vulnerabilities and affected products is available in the official advisory.

  • ChimeraWire: The Click-Fraud Trojan Disguised as a Human User

    Experts at Doctor Web have identified a new click-fraud trojan, Trojan.ChimeraWire, which disguises itself as the activity of a real user and artificially boosts website engagement metrics in search results. Infected Windows machines automatically query Google and Bing for specified resources, follow links, and click through pages as though operated by a human, enabling fraudsters to elevate the search ranking of their promoted domains.

    At its core, ChimeraWire relies on the open-source projects zlsgo and Rod, typically used for automating interactions with websites and web applications. Once inside a system, the trojan downloads from a remote site an archive containing a portable Windows build of Google Chrome — with Linux and macOS builds stored on the same server. It then silently installs two legitimate Chrome extensions, NopeCHA and Buster, both designed for automated CAPTCHA solving. The browser is launched in a hidden debugging mode, and all control is routed through a WebSocket connection, enabling the malware to execute arbitrary scripts in the background without alerting the user.

    ChimeraWire subsequently retrieves commands from its command-and-control server, which transmits an AES-GCM–encrypted configuration encoded as a base64 string. This configuration defines every operational parameter: which search engine to use (Google or Bing), target keywords, domains to promote, click depth, page-load delays, click-distribution patterns, and the timing of pauses to avoid the appearance of perpetual bot traffic. Essentially, it prescribes a highly adaptable behavior profile for an “ideal user” optimized for manipulation.

    The trojan’s workflow is as follows: it enters the assigned keywords into the search bar, discovers the designated sites, and opens them — sometimes in background tabs. On each loaded page, ChimeraWire extracts all HTML elements containing hyperlinks, stores them in an array, and shuffles their order so that the click sequence does not mimic the natural link order — a tactic designed to evade anti-bot heuristics. It then compares anchor text with template phrases from the configuration and counts matches.

    If enough relevant links are found, it sorts them by their “relevance” to the keywords and clicks one or several. If matches are scarce or absent, ChimeraWire resorts to a probabilistic model: for example, a configuration might specify a distribution of “1:90, 2:10,” meaning that in 90% of cases it should click one link, and in 10% — two. The trojan randomly chooses from the shuffled list and proceeds. After each transition, it either returns to the search-results tab or proceeds to the next target until it exhausts its action quota for that site.

    To infiltrate a system and acquire the necessary privileges, the attackers built several intricate infection chains.
    In the first chain, execution begins with the loader Trojan.DownLoader48.54600, which terminates immediately if it detects virtualization or debugging. If the environment passes these checks, it downloads a python3.zip archive containing the malicious script Python.Downloader.208 and the library ISCSIEXE.dll (Trojan.Starter.8377). The attackers exploit DLL Search Order Hijacking, causing iscsicpl.exe to load the trojanized DLL and thus grant administrator-level execution for the next stage.

    With elevated privileges, Python.Downloader.208 retrieves onedrive.zip, which includes UpdateRingSettings.dll (Trojan.DownLoader48.54318) and the legitimately signed OneDrivePatcher.exe. This executable, too, suffers from a DLL-hijacking weakness and loads the malicious library. A new loader then scans for virtualization, downloads an encrypted ZLIB container with shellcode and an executable, decrypts and unpacks it, and finally launches the main payload — Trojan.ChimeraWire.

    The second chain employs a separate loader, Trojan.DownLoader48.61444, which masquerades as explorer.exe (via Masquerade PEB), escalates privileges through legacy COM interfaces (CMSTPLUA), and again abuses DLL Search Order Hijacking — this time by substituting ATL.dll and triggering the WMI console (mmc.exe). After gaining administrator rights, it downloads two archives: one.zip (containing OneDrivePatcher.exe and UpdateRingSettings.dll) and two.zip (containing Python.Downloader.208 as update.py and the auxiliary files required to execute it, including Guardian.exe, a renamed pythonw.exe). Tasks are created in the Windows Task Scheduler to ensure persistence across reboots, effectively duplicating parts of the first chain and increasing the likelihood of successful delivery.

    The trojan’s name is no accident: “Chimera” evokes the hybridized nature of the attack chain — loaders in multiple languages, an assortment of anti-analysis techniques, several privilege-escalation methods, and a fusion of off-the-shelf frameworks, plugins, and legitimate software for covert manipulation of web traffic. “Wire” underscores its invisible yet constant network activity, from module retrieval to persistent C2 communication.

    For now, ChimeraWire’s primary mission is relatively simple: artificially inflating site popularity by simulating genuine user behavior in search engines and on webpages. Yet the components on which it is built enable far more. In theory, attackers could automate web-form submissions (including in advertising and survey platforms), read page content, capture screenshots, or harvest vast quantities of data — such as email addresses and phone numbers for spam or phishing campaigns.

    Doctor Web specialists expect future variants of ChimeraWire to feature expanded capabilities and continue to monitor its evolution. For users and administrators, the conclusion is a familiar one: signature-based detection is no longer sufficient. Sophisticated infection chains leveraging DLL hijacking, administrator-level privilege escalation, and anti-debugging techniques can persist for long periods unless complemented by behavioral and proactive defensive measures.

  • DumpGuard Tool Bypasses Credential Guard to Steal NTLMv1 Hashes

    DumpGuard is a credential dumping tool that can extract the NTLMv1 hashes of users on modern Windows systems.

    The tool relies on the Remote Credential Guard protocol, and allows credential dumping even when Credential Guard is enabled on the local host. You may download prebuilt copies from the release section of this repository.

    Usage Overview

    The following table depicts the different techniques supported by the program as well as their requirements and their ability to dump credentials protected by Credential Guard.

    Technique Requires
    SYSTEM    		 Requires
    SPN Account    		 Can Dump
    Credential Guard
    Extract own credentials via Remote Credential Guard protocol ❌ ✅ ✅
    Extract all credentials via Remote Credential Guard protocol ✅ ✅ ✅
    Extract all credentials via Microsoft v1 authentication package ✅ ❌ ❌

    Dumping Own Session (using Remote Credential Guard)

    To dump an NTLMv1 response for the current user from an unprivileged context, we can authenticate towards an SPN-enabled account using Remote Credential Guard, and leverage the established security context to request an NTLMv1 hash from the NtlmCredIsoRemote interface.

    This works regardless of the state of Credential Guard, but requires credentials for an SPN-enabled account.

    Privilege Requirement: None.

    [pastacode lang=”markup” manual=”DumpGuard.exe%20%2Fmode%3Aself%20%2Fdomain%3A%3CDOMAIN%3E%20%2Fusername%3A%3CSAMACCOUNTNAME%3E%20%2Fpassword%3A%3CPASSWORD%3E%20%5B%2Fspn%3A%3CSPN%3E%5D” message=”” highlight=”” provider=”manual”/]

    Dumping All Sessions (using Remote Credential Guard)

    To dump NTLMv1 responses for all currently authenticated users from a privileged SYSTEM context, we can impersonate tokens from running processes, then authenticate towards an SPN-enabled account using Remote Credential Guard, and leverage the established security context to request an NTLMv1 hash from the NtlmCredIsoRemote interface.

    This works regardless of the state of Credential Guard, but requires credentials for an SPN-enabled account.

    Privilege Requirement: SYSTEM.

    [pastacode lang=”markup” manual=”DumpGuard.exe%20%2Fmode%3Aall%20%2Fdomain%3A%3CDOMAIN%3E%20%2Fusername%3A%3CSAMACCOUNTNAME%3E%20%2Fpassword%3A%3CPASSWORD%3E%20%5B%2Fspn%3A%3CSPN%3E%5D” message=”” highlight=”” provider=”manual”/]

    Dumping All Sessions (using Microsoft v1 authentication package)

    To dump NTLMv1 responses for all currently authenticated users from a privileged SYSTEM context, we can interact with the NTLM SSP and request responses for each individual logon session ID.

    This works only under the following conditions:

    • Credential Guard is disabled on the local system (we can extract from all local sessions).
    • Remote users are authenticated to the local system from a remote host over Remote Credential Guard.

    Privilege Requirement: SYSTEM.

    [pastacode lang=”markup” manual=”DumpGuard.exe%20%2Fmode%3Aall” message=”” highlight=”” provider=”manual”/]

    This attack can also be carried out using LSA Whisperer with the following command:

    [pastacode lang=”markup” manual=”lsa-whisperer.exe%20msv1_0%20Lm20GetChallengeResponse%20–luid%20%7Bsession%20id%7D%20–challenge%20%7Bchallenge%20to%20clients%7D%20%5Bflags…%5D” message=”” highlight=”” provider=”manual”/]

    Download

  • FusterCluck PoC: Script Exploits RPC to Achieve Lateral Movement in Failover Clusters

    FusterCluck is a POC script for attacking failover clusters via the cluster API over RPC. The tool allows enumeration of cluster nodes and the state of cluster roles. If an attacker has control of a cluster admin or a cluster virtual account, they can migrate cluster groups to every node of the cluster and target the cluster namespaces as a method of lateral movement.

    Attacking WSFC

    Introduction

    Windows Server Failover Cluster (WSFC) is a Microsoft Windows feature that grants high availibility to resources or applications. Examples of clustered services include distributed file servers or MSSQL databases. Always-On Availability Groups (AG) are built on-top of WSFC services and provide alternate methods of high availability depending on the admin’s needs. Standard deployments of WSFC create Active Directory machine accounts to represent cluster resources. These are known as the cluster name object (CNO) and virtual computer objects (VCO) and are commonly referred to as “cluster virtual accounts”.

    Cluster Virtual Accounts

    The CNO is created when the cluster is deployed and represents the cluster itself while the VCO represents a clustered service or application and is created when the role is deployed on the cluster. A cluster may only have one CNO but may have one or more VCOs depending on the number of roles installed. For clarity, not all roles require use of a VCO and admins may choose to forego deployment such as for a MSSQL AG. When each account is created, an IP address is reserved in DHCP and a DNS entry is created that represents an access point.

    Cluster Nodes

    A cluster will have two or member servers known as nodes. Nodes work collaboritiavely to ensure availability and own or host the CNO and VCO resources. Only one node may own the resource at a time and is considered the active node. When a client requests access to a clustered resource the active client facilitates the request. In the event of a failure, the cluster automatically moves the role’s group of dependent resources to the next healthy node. When the cluster service starts on a node, the service validates the credentials for the VCO and CNO accounts and maintains a persistent logon session for each to facilitate failover and minimize downtime.

    Cluster Database

    Cluster configuration settings are stored in registry and replicated to each node in the cluster at HKLM\Cluster. When a setting is updated in the cluster, each node updates their own database to ensure settings are synchronized and passive nodes are able to assume an active state in the event of a failover.

    To facilitate Kerberos authentication, each node must be able to decrypt service tickets provided by clients for the cluster namespaces. The cluster stores and replicates encrypted credentials for the CNO and VCO AD machine accounts in the ResourceData key for each resource in the cluster database.

    An administrative user may decrypt and recover the hashed credentials for these accounts using the POC code provided here.

    Download

  • DCOMRunAs: Covert Technique for Remote Code Execution in a Logged-on Session

    DCOMRunAs instantiates COM objects in the session of a logged-on user on a remote machine. By targeting a COM object subject to DLL hijacking and dropping a custom DLL at that path, the payload DLL will be loaded in the context of the logged-on remote user.

    Context & theory

    Initially an internal PoC developped last year, it is released following the publication of BitlockMove by @S3cur3Th1sSh1t, his TROOPERS 2025 slides are a good overview of the general idea (looking forward to the recording and blogpost !).

    Since the technique is now public, we decided to publish the tool as-is, even though it’s not as thouroughly tested as we’d like, so obviously use at your own risk, and feel free to flag any issue in the repository tracker.

    The original idea (on our side) came from playing with James Forshaw’s oleviewdotnet and noticing the “Create In Session” button for objects running as Interactive User. The moniker code was taken and adapted to C from here and the CoGetObject code from there.

    Main differences with BitlockMove:

    • DCOMRunAs is not battle-tested 🙂
    • Works on both Windows Server and client systems
    • Does not require registry modification (for COM hijacking purposes)
    • Difference in OPSEC considerations (registry modification aside):
      • loading a “well-known” DLL (version.dll and such, specifically not a KnownDLL) from an unexpected path
      • cross-session activation with CoGetObject and a session moniker
    • Common OPSEC considerations (for completeness)
      • remote instantiation of a specific CLSID
      • signed process loading an unexpected unsigned DLL

    Practice

    Compile a hijacking DLL that will perform the actions wanted. Name it and forward exports accordingly. Then, from a runas /netonly shell as a local administrator of the target machine:

    1. Drop it at the correct path on the target machine.

    2. Grab the target session identifier. It can be done remotely by running one of these commands:

    qwinsta /server:<remote_host>
query user /server:<remote_host>
    1. Run the tool with the correct session ID and CLSID:
    C:\> DCOMRunAs.exe <sess_id> <CLSID> [remote_host_if_remote]

    Download

  • BitlockMove: New PoC for Covert Lateral Movement via BitLocker DCOM Hijacking

    BitlockMove

    Lateral Movement via Bitlocker DCOM & COM Hijacking.

    This Proof of Concept (PoC) for Lateral Movement abuses the fact, that some COM Classes configured as INTERACTIVE USER will spawn a process in the context of the currently logged on users session.

    If those processes are also vulnerable to COM Hijacking, we can configure a COM Hijack via the remote registry, drop a malicious DLL via SMB and trigger loading/execution of this DLL via DCOM.

    This technique removes the need to takeover the system plus afterward:

    1. Impersonate the target user
    2. Steal the target users credentials from LSASS or somewhere else
    3. or use alternative techniques to take over the account

    Because our code is already getting executed in the context of the logged in user, we can do whatever we want in that context and create less IoCs for alternative techniques.

    In this PoC, the CLSID ab93b6f1-be76-4185-a488-a9001b105b94 – BDEUILauncher Class is used with the IID IBDEUILauncher. This function allows us to spawn four different processes, whereas the BaaUpdate.exe process is vulnerable to COM Hijacking when being started with any input parameters:

    The CLSID A7A63E5C-3877-4840-8727-C1EA9D7A4D50 is trying to be loaded, which we can hijack from remote:

    As this CLSID is related to Bitlocker, it can mainly be found on Client systems. Therefore, this PoC mainly allows Lateral Movement on Client systems, not on Servers (because by default Bitlocker is disabled there).

    OpSec considerations / Detection

    The PoC uses a hardcoded DLL, which will always look the same and which will get dropped on the target. It’s super easy to build detections on this DLL, so using a self written DLL will less likely get you detected. With a custom DLL you will also live in a trusted signed process instead of spawning a new one, that’s usually what attackers prefer.

    Behavior based detection of this technique can be done by checking for

    1. Remote COM Hijack of the mentioned CLSID followed by
    2. BaaUpdate.exe loading a newly dropped DLL from the hijack location
    3. BaaUpdate.exe spawning suspicious sub-processes

    Download

  • Microsoft Warns: ClickFix Phishing Attacks Are Bypassing EDR

    Microsoft has issued a warning over the growing surge of large-scale ClickFix phishing attacks and has recommended that system administrators restrict the use of command-line tools and disable the Run dialog in Windows. This guidance is tied to the rapid spread of schemes in which attackers trick users into executing malicious commands themselves, disguising the process as CAPTCHA verification, identity confirmation, or the resolution of minor “technical issues.”

    The ClickFix technique has been actively employed since last year. Victims are shown a page with simple instructions, urging them to copy and execute code in Windows Run, PowerShell, or Windows Terminal. Once launched, the command downloads trojans, information stealers, or loaders, granting attackers full access to the system. Microsoft reports that these campaigns target thousands of devices globally every day, with tens of thousands of users compromised each month. Alarmingly, the attacks succeed even when security defenses, including EDR solutions, are enabled—making the method particularly dangerous.

    According to Microsoft Threat Intelligence, adversaries use a variety of delivery vectors. Most often, malicious links are distributed through ads on questionable websites, mass spam campaigns, phishing emails, or compromised domains. A user might, for instance, encounter the attack when attempting to stream a free movie on a pirated site—clicking “Play” redirects them to a counterfeit page with instructions. In other cases, the attackers mimic system errors or impersonate notifications from services like Discord, falsely claiming that identity verification is required.

    The attackers’ primary goal is to persuade the victim to execute the malicious code themselves. To conceal their activity, the commands are obfuscated and encrypted, while components are fetched from multiple servers. Through ClickFix, some of the most dangerous tools are distributed, including LummaStealer, Xworm, AsyncRAT, NetSupport, SectopRAT, as well as loaders like Latrodectus and MintsLoader, and rootkits such as r77. Many of these threats operate directly in memory without leaving files behind, injecting malicious code into legitimate Windows processes such as msbuild.exe, regasm.exe, and powershell.exe.

    Microsoft has also observed the active sale of turnkey ClickFix builders on underground forums. Prices for these kits range from $200 to $1,500 per month, with sellers promising antivirus evasion and persistence within compromised systems. Experts caution that because this method relies on user interaction, such attacks can bypass many traditional security mechanisms.

    In its published recommendations, Microsoft advises administrators to restrict command-line tools for untrained users as much as possible. Suggested measures include disabling the Run dialog, blocking the execution of PowerShell and other executables via it, limiting access to Windows Terminal, and enabling alerts when multi-line code is pasted.

    Additional guidance includes the use of Group Policies to harden Windows configurations, strict script execution rules, and application control policies to prevent the launch of built-in system utilities from untrusted sources.

    The company further emphasizes the importance of strengthening digital literacy and training employees to recognize social engineering tactics, thereby reducing the likelihood of inadvertently executing malicious commands. The report also publishes IP addresses, domains, and other indicators of compromise to help administrators detect suspicious activity across their networks in a timely manner.

  • EByte-AMSI-ProxyInjector: A New Tool Exposes a Critical Bypass Technique

    EByte-AMSI-ProxyInjector

    A lightweight tool that injects a custom assembly proxy into a target process to silently bypass AMSI scanning by redirecting AmsiScanBuffer calls. It suspends the target’s threads, patches the function to always return AMSI_RESULT_CLEAN without altering original bytes directly, ensuring stealthy AMSI bypass.

    AMSI bypass

    Features

    • Thread-safe implementation with proper thread suspension/resumption
    • Verbose debugging mode for detailed operation analysis
    • Minimal dependencies – uses only core Windows APIs

    How It works

    The tool employs a function redirection approach instead of direct byte patching:

    1. Targeting: Accepts a process ID (PID) as input to target a specific process

    2. Thread Management:

      • Suspends all threads in the target process to prevent race conditions
      • Uses NtSuspendThread and NtResumeThread for atomic operations

    3. AMSI Detection:

      • Locates amsi.dll in the target process
      • Calculates the offset of AmsiScanBuffer from the module base
      • Maps this offset to find the function in the target process

    4. Redirection Implementation:

      • Allocates memory in the target process for a proxy function
      • Writes a minimal assembly function that preserves register state but always returns 0 (clean)
      • Creates a jump instruction at the start of the original AmsiScanBuffer function
      • Redirects execution to the clean proxy function

    5. Cleanup:

      • Resumes all previously suspended threads
      • Properly closes all handles to prevent resource leaks

    Technical Details

    Memory Manipulation

    The tool uses the following NT API calls for memory operations:

    • NtAllocateVirtualMemory: Allocates memory for the proxy function
    • NtProtectVirtualMemory: Changes memory protection to allow writing/execution
    • NtWriteVirtualMemory: Writes the proxy function and jump instruction

    Proxy Function Implementation

    The proxy function is a small assembly routine that:

    1. Preserves register state by saving registers to the stack
    2. Sets EAX to 0 (representing AMSI_RESULT_CLEAN)
    3. Restores register state
    4. Returns to the caller

    Download & Use

  • Total Takeover: The Attack That Seizes Your Active Directory With Default Settings

    Researchers at Resecurity have drawn attention to an exceptionally dangerous attack that enables adversaries to seize full control over an organization’s Active Directory domain infrastructure—all while exploiting default Windows configurations. The technique combines MITM6, which injects a rogue IPv6 configuration, with NTLM Relay, where intercepted credentials are relayed to targeted services. This synergy effectively transforms an enterprise network into a fertile ground for compromise, even in environments where administrators do not actively use IPv6.

    The weakness lies in the fact that Windows systems automatically query DHCPv6 upon startup, allowing attackers to masquerade as a fake IPv6 server. By manipulating DNS queries and the WPAD protocol, adversaries can redirect traffic, intercept authentication attempts, and launch ntlmrelayx from the Impacket toolkit to funnel captured data into LDAP. This process enables the creation of fraudulent computer accounts that can impersonate privileged users.

    The situation is further exacerbated by three built-in characteristics of Active Directory:

    1. At system startup, DHCPv6 traffic takes precedence, instantly exposing the attack vector.
    2. By default, any domain account can register up to ten computers, courtesy of the ms-DS-MachineAccountQuota parameter.
    3. Newly created computer objects can modify their own msDS-AllowedToActOnBehalfOfOtherIdentity attribute, making Resource-Based Constrained Delegation (RBCD) exploitation possible.

    Together, these traits allow attackers to escalate privileges all the way to Domain Admin.

    Once credentials are captured, attackers typically deploy secretsdump.py to extract password hashes and CrackMapExec to test stolen combinations across multiple systems. The final phase involves remote administration via WMIExec or PsExec, granting persistence within the infrastructure, lateral movement between hosts, and long-term access. Attackers may also employ DNS poisoning to disrupt critical services, amplifying the destructive impact.

    Experts warn that the consequences of such attacks are catastrophic—ranging from credential theft and lateral spread to the deployment of ransomware. Recovering from a full domain compromise demands immense effort and time, and even then, intruders may linger in the environment long after the original vector has been closed.

    To mitigate risk, specialists recommend disabling IPv6 in environments where it is unnecessary, enforcing LDAP signing and Channel Binding, restricting machine account creation, and closely monitoring anomalous DHCP events. Network segmentation offers an additional defensive layer, limiting adversarial movement across systems. Above all, this case underscores the grave danger of relying on default Windows settings and neglecting rigorous domain security hardening.

  • Coyote Banking Trojan Exploits Microsoft UI Automation for Stealthy Credential Theft

    A newly evolved strain of the Coyote banking trojan has adopted an unconventional method of user surveillance on Windows systems. Malicious actors have learned to exploit Microsoft’s UI Automation (UIA) framework—originally designed to aid users with disabilities—to monitor visits to banking websites and cryptocurrency exchanges. This technique enables the malware to harvest sensitive data, including login credentials, while bypassing modern security mechanisms.

    The UIA platform was developed to facilitate interaction between assistive technologies—such as screen readers—and user interface elements in Windows applications. UIA-compatible software constructs what is known as an automation tree, wherein each element (button, window, tab) can be detected, analyzed, and even manipulated externally via a specialized API. While this architecture has empowered the creation of accessible computing experiences, its versatility and power have also attracted the interest of cybercriminals.

    Experts at Akamai first warned of the potential for such abuse in December 2024, hypothesizing that UIA could be leveraged to evade Endpoint Detection and Response (EDR) solutions, since the framework is deemed “safe” and does not typically trigger antivirus alerts. As of February 2025, this theoretical risk has materialized into active exploitation. It marks the first documented case in which a trojan has harnessed UIA capabilities to steal data directly from a victim’s system.

    Originally discovered in February 2024, the Coyote trojan has since undergone significant evolution. It primarily targets users in Brazil and is capable of stealing credentials from 75 financial institutions and cryptocurrency platforms. Its previous arsenal included traditional methods such as keylogging, fake login windows, and click interception. However, with the incorporation of UIA, Coyote has become far more sophisticated and insidious.

    When a user opens a browser and navigates to a banking or exchange website, Coyote first attempts to identify the destination by examining the window title. If no match is found, it connects to the UIA automation tree, extracts URLs from tabs and the address bar, and compares them against a hardcoded list of 75 targeted services. These include Banco do Brasil, CaixaBank, Santander, Bradesco, as well as cryptocurrency services such as Binance, Electrum, Bitcoin, and Foxbit. If a match is detected, the surveillance module is activated.

    The current phase of the attack appears to be limited to reconnaissance—monitoring the user interface to determine if a target site is open. However, Akamai researchers have demonstrated that the same mechanism can be used to intercept user input, including usernames and passwords. They published a technical proof-of-concept illustrating how UIA can be used to capture the contents of input fields, enabling full credential theft.

    As of this writing, Microsoft has not issued any statements regarding potential restrictions or security enhancements to mitigate such misuse. The situation draws parallels with an enduring issue in the Android ecosystem, where accessibility services have long been exploited by malicious apps. In response, Google has steadily tightened its security policies for apps accessing Accessibility features.

    Frameworks like UIA are created with benevolent intent—to empower individuals with special needs to interact with computers on equal footing. Yet as threat actors continue to explore increasingly unorthodox attack vectors, these powerful system mechanisms are becoming tools of choice in the arsenal of cybercrime.