New Python MaaS Toolkit Lets Attackers Build Custom Windows Infostealers On Demand

Researchers have documented a Python-based malware-builder service that lets low-skilled operators assemble their own Windows infostealer without writing a line of code. Feed the builder a webhook address and it hands back a ready-to-run stealer packaged as either a compiled executable or a raw script.

What happened

The builder installs its own Python dependencies — packages like requests, pywin32, Pillow, browser-history and pycryptodome — before stitching the stealer payload into a Nullsoft or PyInstaller executable, or leaving it as an editable script for operators who want to tweak it further.

Once running, the payload sweeps the saved-data folders of 17 Chromium-based browsers for stored passwords, autofill and payment-card entries, browsing history, and — critically — session cookies, which can hand an attacker an already-authenticated account even if the real password is never recovered. It reaches into browsers' encrypted credential stores using Windows' own data-protection APIs, so it doesn't need to exploit the browser itself. Firefox gets separate treatment for history and cookies. The stealer also grabs Discord authentication tokens (checking that they still work) and Roblox session cookies, and it lifts saved Wi-Fi network passwords from the machine, along with the victim's public IP, approximate location, timezone, username and hostname.

Everything is packed into a single archive in memory — never written to disk — and pushed out through a webhook the operator configured at build time, with the destination obfuscated using XOR and Base64 encoding inside the payload.

Why it matters

The builder is engineered to dodge quick inspection: it checks for debuggers and virtual-machine indicators, watches available disk space, varies its own sleep timing, and delays loading some of its libraries until the moment they're needed — all of which can let it slip past short automated sandbox runs. For persistence, it plants itself twice — a Windows "Run" registry key and a logon-triggered scheduled task — so removing one copy isn't enough to evict it. Because each build can be reconfigured with a different webhook, dependency set and evasion timing, no two samples necessarily look alike, which undercuts detection based on static signatures or fixed indicators alone.

What to do

Organizations should watch for unexpected Python package installs, browser credential-store access by non-browser processes, new scheduled tasks or "Run" key entries tied to unfamiliar binaries, and outbound traffic to unrecognized webhook or paste-style endpoints. Because stolen session cookies can bypass a password change, any suspected infection should trigger a full session/token revocation across the affected accounts, not just a password reset. Keep endpoint protection current, avoid running unsolicited executables, and correlate these behaviors as a set — relying on any single indicator, like a hash or a URL, is unlikely to catch every build this toolkit produces.