GitHub User Attachments Abused to Spread Novel Infostealer Attackers are exploiting GitHub’s user attachment feature to distribute malware, leveraging the platform’s trusted infrastructure to host and spread malicious payloads. This technique allows threat actors to bypass traditional security measures by using legitimate GitHub content delivery network (CDN) links to deliver harmful files. How the Attack Works The campaign involves ZIP archives hosted as GitHub user attachments, which contain a multi-stage infection chain. These archives, often named files like installer.zip or Eclipsyn.zip, include signed modules and executables designed to sideload a malware loader known as “Direct-Sys Loader.” The attack begins when a legitimate Microsoft-signed executable, Launcher_x64.exe, is tricked into loading a malicious DLL called msys-crypto-3.dll. Once activated, Direct-Sys Loader performs three anti-analysis checks before proceeding: – It checks for the presence of a file named 12345.txt and terminates if found. – It decrypts and compares a list of 67 process names linked to sandboxing, debugging, and analysis tools against active processes, halting execution on a match. – It decrypts a list of four display device strings associated with virtual machines and hypervisors, terminating if the system’s display information matches any of them. If all checks pass, the loader decrypts and executes next-stage shellcode in memory using direct syscall stubs for three WIN32 APIs. This method helps evade detection by traditional endpoint defenses that monitor standard API calls. The decryption process uses the ChaCha20 algorithm with a hardcoded key and nonce. Related Threat Campaigns Similar abuse of trusted platforms has been observed in other malware distribution efforts. In early December 2024, a malvertising campaign impacted nearly one million devices globally by redirecting users from illegal streaming sites to intermediary pages that led to GitHub and other platforms hosting infostealers. Another campaign identified in January 2026 used spoofed software installers disguised as MalwareBytes updates. These ZIP files, named malwarebytes-windows-github-io-X.X.X.zip, shared a unique behash (“4acaac53c8340a8c236c91e68244e6cb”) and contained a consistent internal structure, including a DLL payload and a text file (either gitconfig.com.txt or Agreement_About.txt) holding a GitHub URL for infrastructure mapping. Attackers have posed as providers of free VPN services, using GitHub to distribute Lumma infostealer under the guise of legitimate software. These campaigns take advantage of GitHub’s reputation as a safe, open-source platform to avoid raising suspicion. Why GitHub Is Being Targeted GitHub’s widespread use by developers, combined with its reliable CDN and permissive sharing model, makes it an attractive vector for malware distribution. Files hosted on githubusercontent.com benefit from implicit trust, allowing malicious actors to blend in with legitimate software distribution. The platform’s openness enables attackers to create accounts, upload attachments, and share links that appear benign while delivering harmful payloads. Defensive Measures To mitigate risks associated with this threat vector, organizations and individuals should: – Block or restrict access to githubusercontent.com domains unless strictly necessary for business operations. – Implement advanced endpoint detection and response (EDR) solutions capable of identifying sideloading techniques and memory-based execution. – Enforce application control policies to prevent unauthorized executables from running. – Educate users about the dangers of downloading files from unverified sources, even when hosted on trusted platforms. – Monitor network traffic for connections to known malicious GitHub repositories or user attachment links. As threat actors continue to innovate in how they abuse legitimate services, maintaining vigilance and adopting layered security defenses remains critical. The abuse of GitHub user attachments underscores the importance of scrutinizing all software sources, regardless of their apparent trustworthiness.
51
previous post