c0ns010

europapokal

[BSidesPorto @bsidesporto]

Diamond Sponsor Announcement 💎

We're SO THRILLED to welcome @vmray as our Diamond Sponsor this year. Thank you for helping with workshops, villages, hiring the space and much more!

📍June 26-27th, at ISEP - Porto.

#bsides #hacking #event #infosec #tickets #sponsor

[VMRay @vmray]

🔥 Alert: Weaponizing Overlord RAT — open-source Golang RAT in DocuSign-themed phishing

🔗 Report: https://t.co/u60FKomOjF

We have recently spotted a phishing campaign, which utilizes a new, open-source malware called OverlordRAT written in Go.

The chain starts with a malicious URL, which points to a domain impersonating the logistics company Global-Merx. The URI resource - utility.php - mimics an official DocuSign page and uses embedded JavaScript to trick victims into downloading a document of ACH Remittance payment, which is a malicious MSI installer, but we’ve seen the payload getting changed recently. The installer embeds a DLL stager and gets called via the CustomAction table of the fake Microsoft DirectX Runtime MSI installer. The DLL finally injects its payload to werfault.exe, decrypts the final stage Overlord RAT payload with XOR (0xA9) and executes it.

The use of Overlord RAT again reinforces our previous findings that actors are always on the lookout for adopting new tools in their attack arsenal.

🔑 Takeaways:

- URL → DocuSign phishing → MSI → DLL → EP injection (werfault.exe) → XOR (0xA9) → Overlord RAT
- MSI and DLL disguised as Microsoft DirectX Runtime files, embedded payload called via CustomAction table
- DLL stager injects to werfault.exe, decrypts Overlord RAT payload with XOR key 0xA9
- The open-source Overlord RAT handles encrypted WebSocket traffic, provides HTTPS, JWT, RBAC and MFA authentication, flexible remote desktop streaming (WebRTC, MediaMTX) and supports Windows, Linux and macOS platforms

[VMRay @vmray]

🧬 IoCs:
URL: hxxps://localgolf[.]globalmerx[.]es/ssa/Windows/utility.php
C2: 64[.]89[.]161[.]167:5173 (Overlord RAT)
SHA256: 3e98101a03ad5606130bf5998799c05c6de7dcd97ad9e79bc776f3b5fb830609 - ACHRemittance.msi
SHA256: 76ee58191bc408e3f1a5283574c61d331d61b9fd0203d7bffc879761e725b3db - hmlinears.vbs

[FIRST.org @FIRSTdotOrg]

🌄 Our Gold Sponsor, @vmray is the treasure of this year’s conference. Thanks for helping us dig into new ideas and build a stronger IR community. ⛏️

🔗https://t.co/3HoUB8fyBq

#FIRSTCON26

[VMRay @vmray]

A phishkit rarely looks malicious if you take its behaviors one by one. https://t.co/oTMEUqP2Qs

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.
🔗 https://t.co/oTMEUqP2Qs

[VMRay @vmray]

🔥 Alert: Evasion via excessive multi-cloud staging
🔗 Report: https://t.co/4kIBpvYVa4

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

[VMRay @vmray]

There's a quieter kind of phishing that doesn't steal your password at all. https://t.co/LOcju7V4x2

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.

🔗 https://t.co/LOcju7V4x2

[VMRay @vmray]

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. https://t.co/D6n7S8R8a2

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

🔗 https://t.co/D6n7S8R8a2

[VMRay @vmray]

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. https://t.co/vmpZAZd8sW

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.
🔗 https://t.co/vmpZAZd8sW

[VMRay @vmray]

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. https://t.co/xIwkcLvjcM

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.
https://t.co/xIwkcLvjcM

[VMRay @vmray]

🇺🇸 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.

[Albert Zsigovits @albertzsigovits]

That's a gripping backdoor function in this custom #dnlibdll (#dnSpy).
PDB: "D:\\New Private Panell Src 3.0\\"
#remcos #agenttesla #nanocore

@executemalware @malwrhunterteam @siri_urz @naumovax @vxunderground @pr0xylife @svch0st @SquiblydooBlog @Hexacorn @dr4k0nia @cocaman

[VMRay @vmray]

If you're using @MISPProject for Threat Intelligence, this one's for you. https://t.co/gswAZlX8gP

To help CTI teams operationalize their data, we are launching a new technical series by Koen Van Impe @cudeso focused on getting the most out of VMRay within MISP, starting with a step-by-step guide to setting up the VMRay UniqueSignal feed.

Not just a config walkthrough. It covers the kind of detail that saves you an afternoon of trial and error:

- feed types,
- authentication,
- distribution settings,
- tagging with the Admiralty Scale,
- scheduling ingestion, and
- building dashboard widgets to monitor feed activity

Next up in the series: operationalising UniqueSignal with Microsoft Defender, Sentinel, and custom MISP workflows.

🔗 https://t.co/gswAZlX8gP

[VMRay @vmray]

🚨Alert: Evolution of EtherHiding in ArechClient2
🔬Report: https://t.co/6YAc3dIb12

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: https://t.co/xLNE4kvT4d

🧬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

[VMRay @vmray]

One of Europe's biggest cybersecurity gatherings is just around the corner. And we'll be there. 🇫🇷

VMRay is heading to InCyber Forum in Lille (31 March – 2 April).

Come talk to us about what it actually takes to detect evasive malware and phishing threats, and build Threat Intelligence you can trust, not just collect.

Find us at Lille Grand Palais.

Let's connect. 🤝

[VMRay @vmray]

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.

🔗 https://t.co/6RRF85XcF4

[VMRay @vmray]

🚨 Alert: Covert payload delivery through alternative object storage platforms
🔬Report:
https://t.co/YHStziqXfH

📦 In a newly observed attack chain, threat actors have started exploiting lesser known object storage platforms like cubbit[.]io or ufs[.]sh as disposable payload safehouses.

🥷 The chain starts off with an obfuscated VBScript, unfolding into an obfuscated PowerShell downloader. The PS1 script downloads a seemingly harmless image file, pulled from one of these object storage platform providers. Using simple steganography, a Base64 .NET Injector payload is concealed as appended bytes at the end of the image file.

The smuggled .NET Injector is then reflectively loaded into RegAsm.exe and a final Agent Tesla payload is downloaded. This attack chain shows how modern delivery chains are constantly looking for alternative platforms to host and conceal their payload.

🔎 Key takeaways:
- VBS → PS1 → GuLoader / Image (steganography) → .NET Assembly → Payload on cubbit[.]eu → RegAsm.exe → Agent Tesla
-  Initial VBScript utilized junk code, Base64 obfuscation, word slicing, reverse string, and character substitution
- Dropped PowerShell script (Base64 encoded), uses character replacement to thwart static analysis
- Downloads a payload (usually GuLoader) from hosting site ufs[.]sh
- Pulls an image file from firebasestorage.googleapis[.]com, which has a - Base64 blob at the end (steganography)
- PowerShell parses the Base64 blob, decodes it and uses Reflection.Assembly to load the revealed executable (protected with SmartAssembly)
- Dynamically locates a method named 'runss' on a type called 'Homees', invokes it with a remote payload hosted on cubbit[.]io
- Injects the remote payload (Agent Tesla) into RegAsm.exe

🧬 IoCs:
1c216dc51330c5f56cc37f7e37b3516e57b172bd83f787788f80dcdb88b5545b

hxxps://firebasestorage.googleapis[.]com/v0/b/remasd-6c702.firebasestorage.app/o/image.jpg?alt=media&token=b9d8bf3e-b1eb-4c56-9434-d4af570d4a91

hxxps://au72nuxzv2.ufs[.]sh/f/4LhV5B1sDCwIrgzpCwYKXE4gwWVSzU8Dck1rs5tJYqhnmpx6

hxxps://zip1.s3.cubbit[.]eu/SCANNED%20COPIES%20OF%20FINAL%20CONTRACT%20PDFupload.txt

[VMRay @vmray]

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. https://t.co/LfhZOnTrAj

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. 🔗 https://t.co/LfhZOnTrAj

[VMRay @vmray]

🚨 Alert: New GaiaTools crypter-and-loader service spotted in stealthy multi-stage attack: https://t.co/THeTX0lh4a

🔍 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)

[VMRay @vmray]

Security tools have gotten very good at detecting malicious binaries. So attackers stopped relying on them. https://t.co/Ymkjwp8uPR

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 → 🔗 https://t.co/Ymkjwp8uPR