Malware News GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers (A Gen-D Research)

[Khushal]

Content source

https://www.gendigital.com/blog/insights/research/goflateloader-delivers-multiple-infostealers

GoFlateLoader: A Widespread Golang Loader Delivering Multiple Infostealers

Intentionally Inflated Go Binaries That Use Massive PE Overlays to Bypass Detection

www.gendigital.com

Key Points​

• Gen Threat Labs has been tracking GoFlateLoader, a widespread Golang loader used to deliver multiple infostealers, including Amatera, Remus, Lumma, Vidar and StealC.
• GoFlateLoader appears both in x86 (32-bit) and x86-64 (64-bit) variants, matching the bitness of the payload it is supposed to execute.
• The loader is designed for in-memory payload execution and is deliberately inflated with a massive PE overlay to hinder detection
• The two main delivery paths are via supposedly cracked software and a malicious TDS recently documented by Check Point Research, which may redirect users to dedicated landing pages serving password-protected archives containing GoFlateLoader.

 

[Bot]

GoFlateLoader is a good example of why “cracked” software and password-protected archives remain such effective initial access methods: the loader’s main job is to quietly stage and run an infostealer payload in memory while making static inspection harder.

What stands out technically (and why it matters)

• Golang loader + multiple payload families: a single loader family being reused to deliver different stealers usually means the initial infection chain is being “productized” and shared across multiple actors.
• Bitness-matched builds (x86 and x64): matching the payload architecture helps the malware run reliably and reduces obvious failures that might tip users off.
• In-memory payload execution: this can reduce the number of obvious on-disk artifacts, so relying only on “file found on disk” detections may miss parts of the chain.
• Massive PE overlay (“inflation”): oversized overlays can disrupt or slow down scanning, triage, and automated sandboxing, and may also be used to evade simplistic file-size or signature-based heuristics.
• Two common delivery paths: cracked software and traffic distribution systems (TDS) are consistent with many current infostealer campaigns because they scale well and can be tailored per victim/region/browser.

Practical defensive takeaways for home users

• Avoid cracks/keygens: this is the single most effective control here, because it removes the primary infection vector.
• Be cautious with password-protected ZIP/RAR: security tools often have less visibility inside encrypted archives until extraction; treat them as higher risk, especially if downloaded from ads/redirects.
• Use a reputable AV with cloud protection enabled and keep it updated; many infostealers evolve fast, so cloud/behavioral layers matter.
• Turn on OS protections (where available): SmartScreen/reputation checks, tamper protection, and exploit protection can help disrupt common loader behavior.

Practical defensive takeaways for admins / power users

• Application control (AppLocker/WDAC/SRP): block execution from user-writable locations (Downloads, AppData, Temp), which is where these loaders commonly stage.
• Microsoft Defender ASR rules (if available): rules that block credential stealing, suspicious child processes from Office, and abuse of script interpreters often reduce infostealer success rates.
• Logging/telemetry: endpoint telemetry (process creation, network connections, module loads) is typically more useful than file-based artifacts for in-memory execution chains.
• User education + web filtering: restricting “cracked software” sites, malvertising, and redirect-heavy TDS traffic reduces exposure dramatically.

If someone suspects exposure to this kind of infostealer chain

• Disconnect the device from the network to limit further exfiltration.
• Run full scans with a reputable AV, and consider a second-opinion scanner.
• From a known-clean device, change passwords and rotate any saved browser credentials; prioritize email, financial, and primary identity accounts.
• Enable MFA wherever possible and review recent account sign-in activity for suspicious logins.

Key takeaway: this isn’t “one stealer,” it’s an infection pipeline. Reducing exposure to cracks/TDS redirects and enforcing execution controls (especially from user-writable paths) are the highest-impact mitigations.