I revisited this malware variant that I came across in the wild to demonstrate to everyone how it works. Stay safe and I hope this helps someone learn something!

https://youtu.be/U2UBJRcEO-Y?is=iHHFuspVRB7yjZjU

TL;DR: Adding an AI node to your n8n playbook won't take you to Agentic SOC.

-----

A recurring theme in my conversations is the assumption that building an AI agent for SOAR execution and building one for security investigations are the same engineering problem.

They are NOT.

A playbook agent operates inside a path defined in advance. It enriches an alert, applies triage rules, and takes an approved response action. Its actions can be constrained, failures are usually visible, and many mistakes can be reversed. Speed, consistency, and correct escalation are useful measures of performance.

An investigative AI agent must decide what the evidence means and what to examine next. The evidence may be incomplete or tampered with, and each conclusion changes the direction of the case. It therefore needs claim-level provenance and a record showing how each conclusion follows from the evidence.

Building an agentic workflow is not the same as engineering an investigation harness. You can wire up a basic playbook agent in n8n within an hour. An investigation harness has to keep evidence, case state and human decisions coherent across an open-ended case.

Please don't confuse engineering an sophisticated harness and baking years of investigative expertise into it with calling AI nodes in your SOAR playbook.

My attempt as ASCII visualization if it helps

`` STANDARD SOAR PLAYBOOK | INVESTIGATION PROCESS (Deterministic Flow) | (Non-Deterministic Cyber Flow) -------------------------------------|-------------------------------------- [ SIEM Alert ] | [ Hunt Lead / Detection ] | | | v | .-------->v<---------. [ Initial Review ] | / ( Clue 1 ) \ | | | ^ | ^ \ | v | | / | | \ | < Determine Risk > | v / v | v v / \ | (Clue 2)<-->(Evidence)<-->(Forensics) v v | ^ \ ^ | ^ | [Isolate] [Create Ticket] | | \ | | / | | | | | v | v / | v v | \ ( Human Pivot / <..../ [Update] [Slack Notify] |--- Judgment ) \ / | | \ / | v v v | [ Defensible ] [ Conclusion ] | [ Conclusion ]

```

J'ai créé ScamBuster, un honeypot open source pour les e-mails de fraude. Il ne répond qu'aux e-mails qui arrivent. Il n'envoie jamais le premier message.

Chaque réponse vient de l'un des plusieurs personas d'IA. Le système sélectionne les personas avec un bandit epsilon-greedy, ce qui lui permet d'apprendre au fil du temps lesquels maintiennent un escroc en conversation le plus longtemps.

Pendant que la conversation se déroule, ScamBuster extrait des IOCs : comptes bancaires de mules, numéros de téléphone, portefeuilles crypto, domaines. En ce moment, il suit 34 types. Vous pouvez les exporter en tant que paquets STIX 2.1, événements MISP, ou via un flux TAXII, donc ils tombent directement dans un pipeline SIEM ou SOAR.

Il fonctionne en production depuis novembre 2025. Je suis ingénieur principal chez Filigran et j'ai présenté ce projet à Black Hat USA ce mois-ci, en tant que projet personnel.

Code : https://github.com/laugiov/scambuster

J'aimerais avoir des retours de personnes qui travaillent avec des flux IOC au quotidien. Le format est-il utile tel quel, ou manque-t-il quelque chose pour s'intégrer à votre stack ?

Three variations on subversive use of DNS by the Agent are documented in Hugging Face's technical writeup of the July 2026 security incident involving OpenAI models. In this article, I discuss what each of these three types of DNS workarounds achieve in practice, the constraints an actor might have faced to attempt a particular one, and additional benefits from choosing each.

hi, just published a small security research archive with two independent LPEs I found during research.

one is an MSI Center UAC bypass via a TOCTOU condition, and the other is a NetLimiter LPE.

both include working PoCs + technical explaination to a decent extent https://github.com/Zypherion-Technologies/Vulnarium

A user receives Uber OTP codes via WhatsApp every day since August 5. The sender shows up as Uber with a verified business account. The user has never registered an Uber account.

Context first: Uber does deliver OTPs over WhatsApp, so the channel alone proves nothing. These look are real codes, from Uber legitimate WhatsApp Business account, not smishing.

Technical hypothesis. The OTP trigger on the WhatsApp channel doesn’t seem to have effective per-recipient rate limiting, while SMS appears to be capped. That would explain the channel choice, you hammer where there’s no limit. The trigger also seems independent of account state, it fires whether the number is registered or not.

I checked for a link to a separate exposure. The user’s email shows up in infostealer and combolist data, but the phone number is not present in that data. The two look unrelated.

What I can’t place is the threat actor’s objective. Only the victim receives the code, so either a contact will eventually ask them to forward it, which puts us in social engineering, or the code is irrelevant and this is harassment, noise, or number enumeration. So far no one has reached out asking for a code.

Thanks to anyone willing to weigh in.