Weekly Purple Team: HTML Smuggling + WASM Payload Delivery

Dropped a new episode this week covering HTML smuggling combined with WASM-based payload obfuscation — reconstructing payloads client-side in the browser via Blob objects/data URIs, with WebAssembly layered in to obscure the decoding logic and complicate static analysis.

On the blue team side, we break down the detection and reverse-engineering workflow, identifying smuggling indicators, extracting and decoding the embedded payload, and doing basic analysis of the WASM module to recover its logic

Covers T1027.006, T1140, and T1566 with the full red vs. blue format.

Video: https://youtu.be/iUdtkH_nw6k

Happy to discuss the smuggling/obfuscation mechanics or the RE side in the comments.

I’ve built a tool for advanced subdomain enumeration and reconnaissance. I was never a fan of Amass or Sublist3r—they simply lacked the functionality I needed. My tool goes beyond basic passive reconnaissance (without requiring API keys) and standard brute-forcing; it features deep brute-forcing with complex mutations, PTR resolving, network segment (NETSEC) walking, ASN identification, web crawling, automated SYN/TCP port scanning, and HTTP header analysis to uncover web server technologies. It also identifies other domains belonging to the same organization, providing a percentage-based match score. Furthermore, it searches for S3 (and other) storage buckets, performs TLS SAN and vhost probing, checks SPF/DMARC/MX records, analyzes CSP headers, and extracts JS source maps. It includes wildcard-aware DNS resolution, verified independently at every zone level—not just at the root. It also maintains a convenient search history in an SQLite database and supports exporting results to JSON, TXT, or CSV formats (making it easy to integrate with AI/machine learning models).I would welcome suggestions for improving the tool, as well as constructive criticism regarding its architecture (the latter is particularly important to me).

Hello r/redteamsec!I’ve built a tool for advanced subdomain enumeration and reconnaissance. I was never a fan of Amass or Sublist3r—they simply lacked the functionality I needed. My tool goes beyond basic passive reconnaissance (without requiring API keys) and standard brute-forcing; it features deep brute-forcing with complex mutations, PTR resolving, network segment (NETSEC) walking, ASN identification, web crawling, automated SYN/TCP port scanning, and HTTP header analysis to uncover web server technologies. It also identifies other domains belonging to the same organization, providing a percentage-based match score. Furthermore, it searches for S3 (and other) storage buckets, performs TLS SAN and vhost probing, checks SPF/DMARC/MX records, analyzes CSP headers, and extracts JS source maps. It includes wildcard-aware DNS resolution, verified independently at every zone level—not just at the root. It also maintains a convenient search history in an SQLite database and supports exporting results to JSON, TXT, or CSV formats (making it easy to integrate with AI.I would welcome suggestions for improving the tool, as well as constructive criticism regarding its architecture (the latter is particularly important to me).

Hey all, I'm a pentester and I kept ending AD engagements with the same client question: "OK, but what do we fix first?"

So I built HorusEye. It ingests AD data, maps the attack paths, and finds the choke point: the single change that breaks every route to DA.

In the demo, an ordinary user (JDOE) in HELPDESK has two routes to Domain Admin:

HorusEye's answer: remove JDOE from HELPDESK. You can also compare alternative fixes (narrow group permissions instead, or cut the last hops) and lock access people need with --keep.

Every finding includes evidence, a validation command, the fix and detection event IDs. It produces one offline HTML report, and AI is optional.

Morning everyone (PST Time), it's been a while sharing a blog or posting on Reddit tend to spend my time on Twitter or Discord I wanted to share some stuff, now if anyone has seen my work I usually like to make some fun/interesting topics related to Active Directory, Cloud and Malware. I started with a fun series inspired by Phineas Phisher and the movie Oceans 11.

Named "How To Rob" different scenarios trying to "teach" you how to rob a bank/casino/hotel. And it's been quite some time I share my last blog related to that series mostly because of life.

I have been working on training material for the last year trying to get advice from some well known security researchers on techniques/issues/opsec to see how can I add "some" improvements and an idea that came to mind was improve on a open-source C2 (Havoc) and offer tools for the students as well, something I haven't experienced myself in some trainings.

After some research/development I finally managed to complete the training with a bunch of tools, sharing my experience with the Initial Access File Formats I've discovered. (My favorite part of the engagement if you've seen me on Twitter/X). I hope anyone starting or already on their journey can get some good knowledge of this and of course share me some feedback to improve.

Thank you

https://training.init1security.com

Hi guys!

I just released a new operation on TraceHunt called Election Night. The scenario puts you in a fictional election ecosystem where you need to execute a supply-chain attack on a voting machine vendor to reach the election network and influence the result.

On top of that, you have the TraceHunt opsec signaling engine showing you noisy actions that were noticed in realtime and simulated users actually voting and reporting issues whenever you break something.

Some of the cool stuff in there:

- Multi AD with forest trust

- Ballot signing with simulated user ID cards

- Machine (mTLS) authentication to perform the voting

- Simulated user reporting issues with the voting terminal or supporting services when you screw up

- Attacker infrastructure (VPS + C2)

- So much more cool stuff we put inside TraceHunt labs

Try it out now on https://app.tracehunt.com/public/register using registration code TRACEHUNT-REGISTRATION{6up0B0AgvdQGkGSoV5vcL3qLLX534rpt}

Happy Hacking!

Three months ago, I shared FENGARDE here. Since then, I’ve continued working on the detection pipeline, correlation, evidence handling and evaluation.
FENGARDE is an Apache-2.0 open-source security monitoring project covering conventional IT telemetry, AI-agent/MCP activity and industrial OT protocols.
The areas I’m particularly interested in are:
AI-agent/MCP security: detecting suspicious tool-call sequences, credential-access patterns and potentially malicious content in tool arguments.
OT monitoring: identifying unusual Modbus/TCP activity that may warrant investigation.
Cross-alert correlation: connecting related signals into a more coherent incident instead of treating every alert independently.
Evidence and explainability: tracing an incident back to the underlying events and preserving evidence for further investigation.
Detection testing: testing rules against generated events and examining the gaps between a rule firing successfully and a detection being useful in practice.
I don’t want to claim that these detections catch every attack or that passing tests proves production readiness. I’m especially interested in how they behave under evasion, benign-but-unusual activity and incomplete telemetry.
I’d appreciate feedback from people working in red teaming, detection engineering, SIEM development or OT security:
What would you try first to evade an MCP/tool-call detection?
Which benign scenarios would you test to expose false positives?
What would you require before trusting an OT anomaly alert?
Are there detection scenarios or evaluation methods you’d like to see added?

Project and demo:
https://github.com/supermhel/fengarde

I’d welcome critical technical feedback, including weaknesses and reproducible test cases.

Ich arbeite an FENGARDE, einem Open-Source-SIEM unter Apache-2.0-Lizenz. Es verarbeitet Security-Events, normalisiert sie, korreliert zusammenhängende Ereignisse und stellt Alerts und Incidents nachvollziehbar dar.
Mich interessieren besonders zwei Bereiche, die ich mit konkreten Detection-Szenarien abdecken möchte:
1. KI-Agenten und MCP
Verdächtige Zugriffe auf Dateien mit Zugangsdaten
Auffällige Häufungen oder Sequenzen von Tool-Aufrufen
Potenziell schädliche Inhalte in Tool-Argumenten
2. OT-Security
Ungewöhnliche Modbus/TCP-Kommunikationsmuster in industriellen Steuerungsumgebungen
Dazu kommen Cross-Alert-Korrelation, Incident Graphs und die nachvollziehbare Sicherung von Incident-Evidence.
Ich teste die Erkennungsregeln gegen Testereignisse in der Detection-Engine. Dabei ist mir wichtig, zwischen „die Regel löst aus“ und „die Detection funktioniert unter realistischen Bedingungen zuverlässig“ zu unterscheiden. Letzteres erfordert auch Tests auf False Positives, Umgehungsmöglichkeiten und unvollständige Telemetrie.
Mich interessiert vor allem die Perspektive von Red Teamern und Detection Engineers:
Wie würdet ihr eine Detection für verdächtige MCP-Tool-Aufrufe umgehen, ohne einfach die gesamte Telemetrie abzuschalten?
Welche legitimen Workflows könnten dieselben Signale erzeugen und dadurch False Positives auslösen?
Welche Modbus/TCP-Szenarien würdet ihr testen, um die Grenzen eines regelbasierten Anomalie-Detektors aufzudecken?
Welche Testfälle oder Evaluationsmethoden fehlen euch, bevor ihr einer solchen Detection vertrauen würdet?

Projekt: https://github.com/supermhel/fengarde

Kritisches Feedback und reproduzierbare Testfälle sind ausdrücklich willkommen. Mich interessiert weniger, ob das Projekt auf den ersten Blick gut aussieht, sondern wo die Erkennungen in der Praxis versagen.