Impersonated GitHub Brand Repositories Distribute BoryptGrab-Lineage Infostealer via DLL Side-Loading (Fake Arctic Wolf + 290+ Brands) — Threadlinqs Intelligence
As of 2026-07-15, Impersonated GitHub Brand Repositories Distribute BoryptGrab-Lineage Infostealer via DLL Side-Loading (Fake Arctic Wolf + 290+ Brands) is a high-severity malware threat attributed to a Russia-nexus actor, tracked by Threadlinqs Intelligence with 9 detection rules (Splunk SPL, Microsoft KQL, Sigma) and 27 indicators of compromise.
Threat ID: TL-2026-1375 · Severity: HIGH · Status: ACTIVE · Category: MALWARE
Attribution: Russia · FINANCIAL
Since 26 June 2026, a financially motivated, likely Russian-speaking operator has run an ongoing campaign using 292 fake GitHub repositories impersonating security, fintech, crypto, developer, email,
Arctic Wolf Labs and Trend Micro jointly documented a large-scale, brand-impersonation malware distribution campaign that began 26 June 2026. The threat actor published at least 292 GitHub repositories and .github profile pages that mimic legitimate software vendors, including security tooling (a fake Arctic-Wolf-Security/.github repository created 30 June 2026 at 17:33:41 UTC, impersonating the real github.com/rtkwlf), fintech/personal-finance apps, cryptocurrency wallets and exchanges, developer/productivity tools, secure email clients, macOS utilities, and gaming/cheat software. Each repository uses an SEO-optimized, marketing-style README with a concealed 'OFFICIAL PAGE' download button that routes through one of roughly 78 active *.github.io redirector accounts (e.g., bentleyvazquezpvey.github.io) to an actor-controlled distribution domain, primarily targetroyena[.]com, which serves a /download-archive?user_code=...&domain=... endpoint. Roughly 20 distribution/TDS domains and 6 non-Cloudflare bulletproof-hosting servers presenting fake 'Github Download · * · Github' landing pages support the operation.
The served ZIP archive regenerates its filename and payload contents on an approximately 60-second cycle to frustrate static detection and takedown. Each archive bundles a legitimate, Authenticode-signed WinGUP updater binary (renamed to a brand-specific gup.exe) alongside a trojanized libcurl.dll (9.96 MB, compiled 29 June 2026 10:55:33 UTC) and padding DLLs. When the victim runs the renamed gup.exe, Windows' standard DLL search order causes it to load the attacker's libcurl.dll from the same user-writable directory (classic DLL side-loading / T1574.002) instead of the legitimate system library.
The malicious libcurl.dll loader executes a multi-stage in-memory chain: it decodes a wordlist-encoded blob (~0x74bef9 bytes) using a byte substitution table, decrypts the embedded payload, validates the resulting MZ/PE x64 header, allocates memory and applies a transient XOR pass, and then stages the final payload using COM/SafeArray OLE APIs (dynamically resolved CoInitializeEx and SafeArray/Variant routines) rather than the conventional VirtualAlloc+CreateThread pattern -- a reflective PE-loading technique (T1620) designed to evade EDR hooks placed on the standard memory-allocation/thread-creation API sequence.
Once staged, the 11-module infostealer executes sequentially and performs no persistence, drops no secondary payload binary to disk long-term, and performs no dedicated anti-analysis/anti-VM checks in this variant -- a deliberate 'smash-and-grab' design that trades stealth-on-disk for speed. It does, however, leave a recoverable staging folder in %TEMP% (decrypt_browser\, Filegraber\ -- note the operator's consistent typo) containing artifacts such as UserInformation.txt, installed_applications.txt, browser_decryption.log, and screenshot.png, which is high-confidence forensic evidence of successful execution even after the process exits.
The stealer's most notable capability is a Chrome App-Bound Encryption (ABE) bypass achieved via direct code injection into the running browser process rather than the more common IElevator COM-hijack approach: it validates the browser-specific CLSID, creates a named shared-memory region via CreateFileMappingW, writes an encrypted master-key blob into it, launches or attaches to the target browser (chrome.exe, msedge.exe, brave.exe, etc.), allocates ~136,704 bytes in the browser process via VirtualAllocEx, writes an injected DLL into that region, resolves its Bootstrap export, and executes it via CreateRemoteThread; the injected code then decrypts the ABE master key in-process and returns it through shared memory. This defeats Chrome's 2024-introduced App-Bound Encryption cookie/credential protection.
Beyond ABE bypass, the 11 modules collect: system fingerprint and geolocation data (21 host fields plus a wallpaper SHA-1 hash used as a quasi-unique machine ID, and IP geolocation via
Weaknesses (CWE)
CWE-506, CWE-829, CWE-494
Target sectors: technology, developer open-source community, financial services, cryptocurrency, gaming, general consumer individuals
Target regions: Global
Detections & IOCs
As of 2026-07-28, this threat has 9 detection rule(s) across Splunk SPL, Microsoft KQL and Sigma, and 27 indicator(s) of compromise. Detection query text and full IOC values are available to authenticated users and programmatically via the Threadlinqs MCP server (Purple tier). View plans.
Community OSINT corroboration
1 of this threat's indicators have also been reported by the open-source security community, which observed at least one of them before this report was published. Community sightings are unverified and are kept separate from Threadlinqs' curated indicators. Indicator values, reporters and campaign linkage are available to authenticated Red-tier users.
MALWARE, HIGH, threat intelligence, cybersecurity, T1586, T1583, T1608, T1566, T1189, T1204, T1106, T1574, T1140, T1620