Description

The analyzed archive contains a toolkit built to steal VPN credentials from enterprise endpoints. It covers twelve VPN products including Cisco AnyConnect, FortiClient, Palo Alto GlobalProtect, and Sophos. The attacker does not use custom malware - the toolkit is built entirely from legitimate or signed software: an open-source tunneling tool (Xray/XTLS), a Sysinternals utility (AD Explorer), and native Windows binaries. Both standalone executables in the archive are signed with a valid, previously unreported code-signing certificate and are not detected by any antivirus engine on VirusTotal. Network traffic from the tunnel uses REALITY TLS, which makes it look like normal HTTPS traffic to dl.google.com.

Campaign Context

Region / Sector

DACH region, no sector-specific targeting identified. The toolkit targets German-speaking environments, evidenced by German-language UI in the credential harvester. The operator’s initial access method - E-Mail bombing followed by Teams-based social engineering to obtain Quick Assist remote control - matches a documented Storm-1811 access vector. Microsoft Defender blocked the toolkit delivery in this case before deployment. The analysis is a reconstruction based on the archive contents, not an observation of a live incident.

Threat Actor

The initial access method and the use of SSL.com code-signing certificates registered to shell companies are consistent with Storm-1811 / Black Basta operations. However, these techniques are widely shared across the criminal ecosystem, and significant parts of the tooling do not appear in publicly documented Black Basta operations. Activity is assessed with Moderate confidence to be consistent with TTPs of Storm-1811 / Black Basta access broker operations. Initial access method and code-signing procurement match documented patterns, but tooling diverges from public reporting.

Technical Details

Source and Decryption

Origin

The archive (systemchk.zip) was obtained from an attacker-operated Dropbox share link, downloaded on 04.09.2026. The link points to a single file. The initial access vector is known from case context: The attacker uses E-Mail bombing followed by a phone call or Microsoft Teams message impersonating IT support. The victim is convinced to open Quick Assist (quickassist.exe), which gives the attacker remote control of the endpoint. Through this session the attacker delivers and unpacks the toolkit.

Decryption

The archive was encrypted with ZipCrypto. Unlike AES-encrypted ZIPs, ZipCrypto is vulnerable to known-plaintext attacks - if you have the original version of any file in the archive, you can recover the encryption keys without knowing the password. We saved the download locally as attacker.zip and started by listing the archive contents without decrypting:

7z l -slt attacker.zip | grep -E 'Path|Method|CRC'

This showed all filenames, compression methods, and CRC32 checksums. ZipCrypto leaves these in the clear. Among the files were ADExplorer.exe and Eula.txt - the standard contents of the Sysinternals AD Explorer download. We downloaded the official package from Microsoft and compared the CRC32 values:

Figure 1 - CRC32 match between encrypted archive and official Sysinternals download, confirming unmodified binaries and enabling known-plaintext attack.

We packed our copy of Eula.txt into a reference ZIP and ran bkcrack:

Figure 2 - bkcrack recovering the three internal ZipCrypto encryption keys in 12 seconds.

bkcrack recovered three internal encryption keys (d2aa4c9c 31872287 dbec421b). These keys apply to the entire archive because ZipCrypto derives all entry keys from a single password. We used them to produce a decrypted copy and then recovered the original password:

bkcrack -k d2aa4c9c 31872287 dbec421b -r 12 ?p

The password is 2026. Useful as an indicator when encountering other archives from the same or similar campaigns. The choice of ZipCrypto over AES is an operational security mistake by the attacker. It gave us full access to tooling and insights about their TTPs - the top of the Pyramid of Pain.

Toolkit Overview

The archive contains 14 files with three subdirectories. Each serves a role in a six-phase operation that moves from distraction through credential theft to persistent tunneling and exfiltration.

File timestamps range from 17.08.2026 to 02.09.2026. The naming convention mimics Windows updates: Fake KB numbers, process names resembling system services and directory names that look like framework components. SpChost.bat references a directory (WinCore1615) and binary (scvhost.exe) that don’t exist in the archive and are not mentioned by other scripts - likely a leftover from an earlier version of the toolkit.

Attack Sequence

Phase 1 - Initial Access

The victim is flooded with spam E-Mails. Shortly after, the attacker contacts the victim by phone or Microsoft Teams, impersonating IT support. The victim is guided to open Quick Assist (quickassist.exe), giving the attacker remote control. Through this session the attacker downloads the archive, enters the password, and unpacks the toolkit for further actions on objective.

Phase 2 - Distraction

SecUp.bat runs in the foreground. It shows an ASCII-art “SECURITY UPDATE” banner, prompts for credentials, plays a 34-second spinner (“Applying security patches…”), and pings real Microsoft domains under the label “Connecting to update servers.” The script does not contain any network call or file write for the entered credentials - they appear to be discarded.

Figure 3 - SecUp.bat source: ASCII “SECURITY UPDATE” banner, credential prompt, and fake connection spinner.

Phase 3 - Credential Harvesting

Two tools target different credential sources and may run in parallel or serve as alternatives depending on the target environment: ValidateUPD.exe shows a fake Windows login dialog with German UI text. Based on string fragments in the binary (“\PolicyM”, “policyM”, and a German error message about invalid credentials), it appears to write captured credentials to %APPDATA%\PolicyMgr. This would target the user’s Windows or domain password directly. UpdateReadiness.bat / .ps1 silently scans the disk for VPN configuration files and cached credentials. Output goes to %APPDATA%\PolicyMgr\policyMgr.bkp - the same directory, which serves as the central collection point.

Phase 4 - Persistent Reverse Tunnel

An Xray/V2Ray reverse tunnel with REALITY TLS is installed. Two variants cover different target environments - both connect to the same VPS:

• Variant A (WinFix9802) works offline using files from the archive. It copies wkspbroker.exe from System32 and places the Xray DLL next to it for sideloading.
• Variant B (UpdPkg4681) downloads Xray from the internet when sideloading is not an option, using a cascade of six sources.

ADExplorer.exe (unmodified Sysinternals binary) can create Active Directory snapshots as .dat files for offline analysis. Since the download was blocked we didn’t observe any of this activity. The AD enumeration can just be assumed based on the presence of the ADExplorer.exe application.

Phase 6 - Exfiltration

CheckKB.bat / .ps1 upload the collected files from %APPDATA%\PolicyMgr\ via HTTPS POST to a Microsoft Dev Tunnels endpoint: hxxps://sdj4mqcf-8443.use.devtunnels[.]ms/

Toolkit deep dive

VPN Credential Harvester

The harvester scans the system for VPN configuration files and cached credentials. The batch version covers nine products - the PowerShell version adds Zscaler, Ivanti and Windows built-in VPN.

What it extracts: Hostnames, server addresses, usernames, groups, gateways, and connection strings. Some products store credentials in config or log files (WatchGuard logs, rasphone.pbk, OpenVPN auth-user-pass references), so passwords may be included. The PS1 version also follows OpenVPN auth-user-pass file references and reads usernames from the referenced credential files.

The PS1 version validates extracted strings as real IPs or FQDNs before recording them, deduplicates results, and filters out RFC-1918 addresses unless a username is attached. Output is a sorted four-column table (VPN, Endpoint, Login, Info).

Xray Reverse Tunnel

Both installation variants establish the same tunnel:

IP:           74.0.42.157
Port:         443
Protocol:     VLESS Reverse Bridge
TLS:          REALITY
SNI:          dl.google.com
Fingerprint:  chrome
UUID:         cdf277b5-aae8-415f-b637-1ae3b0aadcdc
Public Key:   l1GkwsaYrZyZat4pvImzq8BI0xxb3s2RxH7imf5mDEo
Short ID:     a1eeb9b9eb

Figure 4 - Xray tunnel installer script: VPS address, UUID, REALITY parameters, sideloading paths, and persistence setup.

REALITY disguises a connection as a TLS connection to a legitimate target such as dl.google.com. Unlike domain fronting, REALITY operates at the TLS layer: It emulates a normal browser ClientHello and reproduces characteristics of the target’s TLS handshake. Passive inspection has limited visibility. However, TLS fingerprints, SNI and the destination IP/ASN can still provide useful indicators. In this case, the strongest indicator is the inconsistency between SNI=dl.google.com and destination 74.0.42.157.

Each victim gets a unique bridge domain passed as a script parameter (e.g. h5.tunnel, h12.tunnel), so the attacker can manage multiple hosts through one VPS.

Variant A - DLL Sideloading (offline):

The 31.5 MB version.dll in the archive is not a real Windows version DLL (~30 KB). It is the Xray client compiled as a Go shared library. Go module strings in the binary confirm xray-core v1.260327.0 with REALITY v0.0.0-20260322, built from the GitHub repository VanyaKrotov/xray_cshare, which has since been deleted. This wrapper was maybe built to make xray-core loadable as a DLL for sideloading.

Persistence: HKCU Run key "RemoteAppConnectionBroker" pointing to the copied wkspbroker.exe. The directory is hidden (attrib +h) and the batch file deletes itself after execution.

The sideloading pair: wkspbroker.exe (Windows Remote Desktop Connection Broker, copied from System32) loads radcui.dll (the renamed version.dll). The script places the DLL next to wkspbroker.exe, indicating that the binary imports radcui.dll - this has not been verified against the PE import table.

Figure 5 - version.dll file properties showing 31.5 MB PE32+ DLL – several times larger than a legitimate Windows version DLL.

Variant B - Direct Download (online):

When sideloading is not an option, the scripts download Xray from a cascade of six sources. Each is tried with both curl and certutil as a fallback:

1. GitHub - XTLS/Xray-core official release v26.3.27 (tried twice)
2. Dropbox - share link with original filename
3. Dropbox - share link with the file renamed to z.zip
4. Azure Container Apps - file-node-neu (North Europe)
5. Azure Web Apps - file-node-us (US)

After downloading, xray.exe is renamed to a legitimate looking ConnectivityHost.exe and placed in %LocalAppData%\ConnectivityService\Agent. The two Azure instances appear to be attacker-operated: They follow a consistent naming pattern (file-node-*) and share an authentication token. The PS1 version adds string-level obfuscation: path strings are fragmented (‘Connect’ + ‘ivityService’), download URLs are Base64-encoded, and the filename xray.exe is assembled from character codes. Persistence uses a hidden svchost.dat file containing the start script, with the Run key pointing to powershell.exe -W Hidden -EP Bypass loading it.

Credential Harvester - ValidateUPD.exe

A 32-bit Windows GUI application (314 KB). String analysis shows German UI text and references to %APPDATA%\PolicyMgr. It appears to present a fake login dialog and write captured credentials to the PolicyMgr directory. About 250 KB of the binary is padding: generic XML paragraphs about “configuration profiles”, “backup operations” and “logging subsystems” repeated in varying order. This inflates the file size, lowers entropy, and buries the interesting strings in noise. The binary is signed with a valid code-signing certificate (see below) and has a few detections on VirusTotal.

Figure 6 - Embedded German UI strings in ValidateUPD.exe: login dialog labels, PolicyMgr output path, and invalid-credentials error message.

Code-Signing Certificate

Both binaries (ValidateUPD.exe and version.dll) are signed with the same certificate. SSL.com code-signing certificates registered to shell companies are a documented path in the criminal ecosystem. Code-signing certificates come in two validation tiers: OV verifies that the applying organization exists, EV adds stricter identity checks and requires a hardware token.

Subject:    YOUR CHANCE j.d.o.o (Zagreb, Croatia)
Issuer:     SSL.com Code Signing Intermediate CA RSA R1
Serial:     66096FE6AAB808036B840F230F5606A5
Signed:     2026-08-31 17:06 UTC
Status:     Valid, not revoked (as of 2026-09-05)

Figure 7 - Valid code signature on ValidateUPD.exe, issued to YOUR CHANCE j.d.o.o (Zagreb) via SSL.com.

Indicator of Compromise

Malware / Tools

Network

Host

MITRE ATT&CK Mapping

Recommendation / Learning

• If artifacts from this toolkit are found in an environment, rotate VPN credentials for all affected users - not just local passwords. The attacker’s goal is not the compromised endpoint but the VPN gateway into the corporate network.
• Block or alert on connections to 74.0.42.157 (the Xray VPS) and the Dev Tunnels endpoint (sdj4mqcf-8443.use.devtunnels.ms). The two Azure staging domains (file-node-neu...azurecontainerapps.io and file-node-us.azurewebsites.net) can be blocked at the domain level.
• For broader REALITY TLS detection beyond this specific campaign, alert on any TLS connection where the SNI is dl.google.com but the destination IP is not in Google’s published ranges.
• If *.devtunnels.ms is not used by development teams, consider blocking it entirely. Dev Tunnels as an exfiltration channel is not unique to this operator.
• The code-signing certificate (66096FE6AAB808036B840F230F5606A5, issued to YOUR CHANCE j.d.o.o via SSL.com) is assessed with Moderate confidence to be the strongest cross-campaign correlation indicator available.
• Both standalone executables in the archive are validly signed and undetected by any antivirus engine. Signature-based detection alone does not cover this toolkit.

Conclusion

Overall, the findings show a specialized toolkit that combines credential theft, persistent tunneling, and reconnaissance while blending into normal enterprise activity. The focus on VPN credentials and AD reconnaissance suggests that the compromised endpoint is primarily used to enable initial access into the broader corporate environment. This provides a foundation for follow-on activity, whether conducted by the same operator or handed off to another actor. The case highlights the importance of detecting suspicious behavior across otherwise legitimate tools, signed binaries, and trusted services rather than relying on individual artifacts alone.

This report was produced with AI assistance.