🔥 Alert: Evasion via excessive multi-cloud staging 🔗 Report: vmray.com/analyses/evasion-v… We have recently caught a malware delivery chain, which seems to utilize numerous cloud services to host several, staged payloads that reference each other back and forth. This “cloud-hopping” strategy is making use of less-known online code-sharing and file hosting platforms and ultimately tries to evade automated systems. The excessive cloud-hopping is actually why this “manufactured complexity” stands out from standard attacks. The multi-stage attack chain starts with an obfuscated PowerShell payload (arithmetic calculations, Deflate and Base64), then hops across PythonAnywhere, and ends at the service Pastes[.]dev. The latter pulls 4 samples from the image-hosting service image2url (which can host .exe files too), like UnixStealer or FunnyLoader, and downloads a PyInstaller executable. A Python script is then pulled from Pastes[.]dev again, which sets up a localhost tunnel via a free service called Pinggy and deploys the open-source Gost/GoSimpleTunnel for bridging the tunnel. 💡 Takeaways: - PowerShell loader uses arithmetic calculations, Deflate compression and Base64 encoding for obfuscation - Script checks for username ”runneradmin” to avoid running in GitHub Actions Runners environment - Next stage PowerShell code grabbed from PythonAnywhere, followed by another one from Pastes[.]dev - 4 PE files fetched from image2url (UnixStealer, FunnyLoader, XWormLoader, PyInstaller) - Another stage executes Python script from another Pastes[.]dev link, which connects to Discord C2 - Local proxy configured via downloaded Gost (GoSimpleTunnel) client and the tunneling service free.pinggy[.]io - Code is marked with Vietnamese comments with references to: “hello sigma”, ”sigma miner”, “iamsigmaboy” and “sigmatoilet” - Actor uses different usernames like “hai”, “haingng16“ and “haideptrai“ on several cloud platforms - Additional stages are pulled from GitHub, GitLab, Pastefy and Codeberg along the chain to establish persistence

A phishkit rarely looks malicious if you take its behaviors one by one. vmray.com/may-2026-detection… A connection to Microsoft's real authentication infrastructure: legitimate. A reference to the genuine Microsoft password-reset page: legitimate. A block of login-related text: legitimate. Each behavior, on its own, appears in countless trustworthy applications. It's when they appear together, in the same sample, that the pattern emerges. That's the logic behind one of this month's additions from VMRay Labs: a new meta-VTI that correlates several individually-benign behaviors into a single classification, improving detection of EvilProxy-style phishkit activity, the kind built around adversary-in-the-middle credential and token theft. The full breakdown is in the link. 🔗 vmray.com/may-2026-detection…

Something gets blocked. The alert closes. Everyone moves on... That's the moment most SOC teams know the least about what just happened. vmray.com/blocking-a-threat-… Microsoft Defender stops threats at scale. That's what it's built for, and it does it well. But blocking an attack before it executes carries a trade-off: some of what the attacker was trying to achieve never gets observed. The files that would have downloaded. The infrastructure it was set up to communicate with. The next move in the chain. The question is what to do with everything blocked at the perimeter: the alerts that, on closer inspection, would have a lot to teach the team. That's what our latest post explores: where deep, evasion-resistant analysis fits alongside a strong Microsoft Security program, and why the gap between blocking and understanding is worth closing. 🔗 vmray.com/blocking-a-threat-…

There's a quieter kind of phishing that doesn't steal your password at all. vmray.com/april-2026-detecti… In device-code phishing, the victim sees a real Microsoft login page. They enter a short code. They sign in successfully. Nothing looks wrong, because nothing technically is, except the session they just authorized belongs to the attacker. No password stolen. No fake page to spot. Just a legitimate flow, abused. This is the behavior behind EvilTokens, a Phishing-as-a-Service platform built specifically around Microsoft 365 device-code abuse and token theft. It's also one of the focus areas in this month's detection work from VMRay Labs. April's Detection Highlights includes new VTIs for: 🔹 EvilTokens PhishKit behavior, detecting both the device-code retrieval and the polling that waits for the victim to sign in 🔹 Connections to the Microsoft Device Login Endpoint, flagged for context in credential-access investigations 🔹 cmd.exe launched with fake or misleading arguments designed to slow down triage 🔹 Network communication via AFD, a lower-level Windows interface used to reduce visibility, observed in ACRStealer activity 🔹 MIME type and filename extension mismatches, a strong signal of masquerading 🔹 Windows Defender Firewall manipulation via PowerShell Plus AutoUI improvements for multi-stage fake CAPTCHA campaigns, and 20 new YARA rules. The full breakdown, with the behavioral context behind each detection, is in the link. 🔗 vmray.com/april-2026-detecti…

When threat actors host C2 infrastructure on a public blockchain, traditional takedown requests fail. The data is immutable. The infrastructure is decentralized. And the API endpoints used to access it are, by themselves, entirely legitimate. vmray.com/threat-intelligenc… That last point is what makes EtherHiding difficult to detect through IOC feeds. The same blockchain API endpoints used by malware to retrieve C2 configurations from smart contracts are also used for legitimate purposes — which means they can't easily be added to blocklists. But they can be used for threat hunting. In a new piece from the VMRay Labs team, we walk through that approach: starting from a list of public blockchain API endpoints, pivoting through sandbox analysis, and identifying both known malware families using EtherHiding and previously unknown samples surfaced through the same method. What's in the post: 🔹 Known families confirmed using EtherHiding: SharkStealer, ArechClient2, ClearFake, and a ClickFix campaign hosting multi-stage JavaScript on smart contracts 🔹 A newer variant of ZigCryptoStealer that moved from BSC Testnet to Mainnet, with a C2 domain previously identified in other smart contracts created by the same author 🔹 Two unknown Polygon-based samples: a Java stealer, and a .NET backdoor called LoaderOnNet that uses Steam user profiles as dead-drop resolvers 🔗 vmray.com/threat-intelligenc…

User-reported phishing is one of the highest-volume tasks a SOC team deals with. The challenge: today's phishing rarely reveals itself in the email. Fake CAPTCHAs, ClickFix prompts, QR codes inside PDFs, redirect chains that only activate three layers deep: the actual threat lives at the end of the chain, not in the inbox. zoom.us/webinar/register/WN_… On May 28th, join us for a joint webinar with @KnowBe4 on how the new VMRay KnowBe4 PhishER integration automates the deep analysis that used to require thirty minutes of manual work per email. What you'll see: 🔹 How attachments and URLs from PhishER-reported emails get recursively analyzed in VMRay's sandbox 🔹 How fake CAPTCHAs, ClickFix attacks, advanced QR codes, and multi-stage chains get followed to the final payload 🔹 How clear verdicts and threat details land directly inside your PhishER console 🔹 Real-world attack scenarios walked through end to end Built for SOC analysts and security engineers handling user-reported phishing at scale. Practical, behavioral, and to the point. 🔗 zoom.us/webinar/register/WN_…

🇺🇸 The most valuable signal in phishing detection often comes from users themselves. The challenge is what happens next: hundreds of reports a day, complex multi-stage delivery chains, and analysts who don't have thirty minutes per email to follow every redirect. From May 11-13, VMRay is at KB4-CON in Orlando, alongside the KnowBe4 community. The VMRay team will be there to talk about how recursive analysis turns user-reported phishing from a queue of work into a source of intelligence. What the latest phishing techniques look like once you follow them all the way to the actual payload. How the VMRay integration with KnowBe4 PhishER automates triage of complex chains. If you're attending, let's have a conversation.

🇺🇸 Risk has changed. The work of managing it has changed with it. From June 1-3, VMRay is at the Gartner Security & Risk Management Summit in National Harbor, MD to talk about where deep malware and phishing analysis fits into that picture: how high-fidelity threat intelligence supports risk-based decisions, why analysis quality matters more than ever, and how data sovereignty and deployment flexibility are becoming central to how security tools get evaluated. If you're attending, come find us. Worth a conversation.

Attackers are working harder than ever to stay invisible. Living off legitimate tools. Quietly probing for credentials and configs in the corners of the system most defenders don't watch. Slipping data out through trusted browser processes that look entirely benign in EDR telemetry. Detecting that kind of activity requires understanding exactly how it behaves, and building detection logic that keeps up. Tomorrow, Thorsten Schreiber will walk through what VMRay Labs shipped this month: 🔹 RMM tool detection: catching legitimate remote management software repurposed for persistent access 🔹 Sandbox evasion via geolocation and directory checks: surfacing malware that goes quiet in analysis environments 🔹 Chromium browser abuse: detecting headless-mode execution and App-Bound Encryption bypass from inside the browser's own trusted process 🔹 Sensitive data discovery: four new threat identifiers targeting infostealer reconnaissance against password managers, RDP configs, developer tools, and VPN clients 🔹 30 new YARA rules and config extractors covering MuddyWater, CamaroDragon, PhantomStealer, ParallaxRAT, SalatStealer, and more Practical, behavioral, and built for the analysts and engineers doing the work. 🔗 zoom.us/webinar/register/WN_…

A few years ago, a phishing email was a phishing email. A sketchy link, a credential page, a verdict. Done. That world is gone. Today's phishing arrives as a clean email. vmray.com/why-simple-phishin… A clean email carrying a password-protected document. The QR code inside redirects through legitimate services. The malicious payload only materializes after a user opens, scans, clicks, or pastes, three or four steps removed from the original message. By design, every individual stage looks benign enough to pass automated checks. The threat lives in the CHAIN, not in the email. In a new piece, Andrey Voitenko, CISSP walks through what this shift means for SOC operations, why traditional gateways struggle, and what effective triage of multi-stage delivery chains actually requires. Worth reading if user-reported phishing is part of your team's daily reality. 🔗 vmray.com/why-simple-phishin…

🚨 Alert: New GaiaTools crypter-and-loader service spotted in stealthy multi-stage attack: vmray.com/analyses/gaiatools… 🔍 This new, multi-stage attack delivery chain pivots from a Batch script to PowerShell, retrieving a staged payload via Pastee[.]dev, de-obfuscating it through layered Base64 and single-byte XOR transformations. The attack culminates in shellcode execution and deployment of an AutoIt-based loader, ultimately injecting an encrypted payload into the legitimate charmap.exe process to evade detection. Final C2 is established through GaiaTools, a seemingly new crypter-and-loader service advertised on Telegram. GaiaTools is promoted as being able to crypt executables at scale, with in-memory shell execution capabilities and syscall-based code execution. They also offer a small, tiny PE loader with the customer’s baked-in gate URL for fetching a final payload, a Golang infostealer this time. 🛠️ Takeaways: ⛓️ Attack chain: Batch → PowerShell → Pastee[.]dev → PowerShell → Base64 → XOR → Shellcode → AutoIt loader → Encrypted payload (XOR) → Inject to charmap.exe → GaiaTools C2 🎭 Obfuscated Batch script using env vars to build commands and strings one character at a time, using substitution / lookup table 📥 PowerShell command to grab staged loader from Pastee[.]dev 🧠  The in-memory shellcode loader is written in heavily obfuscated PowerShell with sleeps, pointless random calculations, Base64 obfuscation, and single-byte XOR-decryption (0xED) 💾 Allocates a block of RWX memory via kernel32!VirtualAlloc, copies the decrypted shellcode to it, then turns the memory address into a .NET delegate and calls it 📂 Drops several files: AutoItv3 interpreter, encrypted AutoIt loader, encrypted payload 📡  Final stage is reaching GaiaTools, a seemingly new crypter-and-loader service to pull a Golang infostealer 🗓️  Domain gaia[.]su registered on 2026-03-11 at registrar REGRU-SU IoCs: abe7e5da48a8a55badb87c6937c19d10561fe6f22024c2a5b3600c97706e96bd (SHA256 - 1st stage) b73fe7ca0fd4e4e0a9e8b8f5fdecb42a95f91f7477e2fecf129f797e2892d21c (SHA256 - 2nd stage) 28ca2c00c4e2e5e9a7a1b469c264358fff209822a9dc0a74443e1eb0eb11b315 (SHA256 - 3rd stage) hxxps://pastee[.]dev/r/6OVBx076 (2nd stage payload) hxxps://gaia[.]su/remote-admin/api/payload/91e70b4f5f92e2f138aa8c612cfbc517[.]exe (3rd stage payload)

A single phishing email rarely represents a single threat. The URL is a doorway. The attachment is a container. The QR code is a redirect. The actual threat almost always lives several steps deeper in the chain. vmray.com/unlocking-the-hidd… This is why phishing triage increasingly has to follow that chain to its end. In this new post, we walk through what recursive analysis actually surfaces in a real SOC environment with three examples from user-reported phishing folders: ClickFix attempt dropping NetSupport, PDF-embedded QR code delivering Vidar, and an HTML application deploying Remcos. Full breakdown, including what the SOC sees happen in Microsoft Defender within minutes. 🔗 vmray.com/unlocking-the-hidd…

A library full of empty bookshelves is still just a library. It looks like knowledge. It has the architecture of knowledge. But if the books are thin, outsourced, or missing, the shelves are just furniture. A lot of modern security platforms have become extraordinarily good at building the shelves. vmray.com/strategic-decision… Orchestration layers. Workflow automation. Dashboard reporting. Threat feed aggregation. All beautifully constructed. But shelves don't stop attacks. The books do. The detection engines. The analytical models. The actual depth of understanding about how threats behave. That's where investigations succeed or fail. That's what either explains an attack, or doesn't. The uncomfortable question every security leader should ask once a year: how good is the actual books on my library? Not the interface. Not the integrations. The analytical engine underneath. vmray.com/strategic-decision…

Security tools have gotten very good at detecting malicious binaries. So attackers stopped relying on them. vmray.com/march-2026-detecti… RMM agents. Chromium browsers in headless mode. The browser's own trusted context, used to decrypt data it was designed to protect. These aren't exotic tools. They're the same software your IT team deploys, your users open every day, and your EDR is trained to treat as benign. The attacker's job has shifted. The goal isn't to smuggle something foreign onto the endpoint anymore. It's to use what's already there, or what looks like what's already there, to stay invisible. That's the pattern running through our latest detection work. New VTIs that flag malware dropping legitimate RMM software for persistent access. Detection for App-Bound Encryption bypass, where malicious code runs from inside the browser process itself rather than attacking it from outside. Headless browser detection for stealer activity that leaves no visible trace. The behavioral signals are still there. They just require looking in different places. Full breakdown of this month's detection logic → 🔗 vmray.com/march-2026-detecti…

A year. Real samples. Real threats. Real comparison. vmray.com/customer-success-s… This North American bank didn't return to VMRay because of a sales conversation. They returned because twelve months of operational data left no other conclusion. "Ultimately, our journey led us back to VMRay for one simple reason: unmatched accuracy and reliability in detecting and analyzing malicious activities. VMRay isn't just a solution; it's an essential component of our cybersecurity strategy, providing us with the peace of mind we need to defend against sophisticated threats." - SOC Analyst, North American Bank The gap they discovered wasn't visible in a demo. It wasn't apparent in the first weeks. It emerged in the accumulation of samples the alternative passed and VMRay caught. Read their full story → 🔗 vmray.com/customer-success-s…

Data sovereignty isn't a compliance checkbox anymore. For a growing number of organizations, it's the architectural requirement that decides which vendors stay on the shortlist. vmray.com/release-highlights… With the VMRay Platform release 2026.2.0, we're introducing VMRay Cloud hosted in the AWS European Sovereign Cloud, located in Germany. Data hosted and processed entirely within the EU. Operations within EU sovereignty boundaries. Access limited to EU-resident personnel. Full analytical capability, no trade-off. Alongside that, the release brings several meaningful updates for security teams: 🔹 Recursive threat visibility — threat names and classifications from deep analysis now surface automatically in the parent sample view. Full context at a glance, without digging through the analysis tree. 🔹 Enhanced tag support — broader special character support means alert IDs and identifiers from SIEMs, EDRs, and connectors like Microsoft Defender for Endpoint map cleanly into VMRay submissions. Fewer workarounds, smoother correlation. 🔹 IP allowlisting for Cloud login — account managers can now restrict login access to approved networks. A simple control that meaningfully reduces the attack surface. 🔹 Faster PDF report generation — rebuilt from the ground up. Reports that previously took tens of seconds now generate in seconds. Full release highlights → vmray.com/release-highlights…

🚨Alert: Evolution of EtherHiding in ArechClient2 🔬Report: vmray.com/analyses/etherhidi… ArechClient2 has been using the Binance Smart Chain (BSC) to fetch C2 servers (a technique known as EtherHiding) since at least June 2025, but we observed a change in the technique in a more recent sample. In the past, a single API endpoint hxxps[:]//bsc-dataseed1[.]binance[.]org was used for this, but in this new sample we see requests to 10 different API (sub)domains. While it is currently unclear why the sample queries the same smart contract on 10 different API endpoints, it is likely an attempt to circumvent blocking, or a first step into diversification of API endpoints used to access the smart contracts. Either way, due a limited number of possible API endpoints, this still is a great detection opportunity to detect malware (for example ArechClient2, SharkStealer) that uses EtherHiding. 🔎In a nutshell: - ArechClient2 contains one hardcoded C2, fetches second C2 server from Binance Smart Chain via RPC call (eth_call) - Smart contract returns base64 encoded tuple (with “START” and “FINISH” markers) consisting of IV and encrypted C2 IP - Executable uses embedded hardcoded key plus IV to decrypt C2 channel (AES) - We identified samples communicating with three different smart contracts, one of them being updated very frequently - 10 different BSC API endpoints queried in recent sample 🔐Find the full decryption procedure here: gchq.github.io/CyberChef/#re… 🧬IoCs: - 79326544757d48a9f0fc0cfd9628df712a92271fa85e1194c5132fa465896e72 - Contract: 0xbd75e2f339d4aebf72ff13f3af4c27096f709a4d - AES Key: VOqkXCYMgproaIQIj50Z2tsBru1ULFzXeKKKg19WMTs= - C2:138[.]226[.]238[.]96:443 🌐BSC API endpoints - hxxps[:]//bsc-dataseed1[.]binance[.]org - hxxps[:]//bsc-dataseed2[.]binance[.]org - hxxps[:]//bsc-dataseed3[.]binance[.]org - hxxps[:]//bsc-dataseed4[.]binance[.]org - hxxps[:]//bsc-dataseed1[.]ninicoin[.]io - hxxps[:]//bsc-dataseed2[.]ninicoin[.]io - hxxps[:]//bsc-dataseed1[.]defibit[.]io - hxxps[:]//bsc-dataseed2[.]defibit[.]io - hxxps[:]//bsc-dataseed3[.]defibit[.]io - hxxps[:]//bsc-dataseed4[.]defibit[.]io