#detectionengineering

7 posts· Last used 4d

#BSidesLuxembourg2026 recording:“OpenTide: From Raw Intelligence to Structured Threat-Informed Detections” – Remi Seguy Watch 's session, recorded live at the Digital Learning Hub during BSides Luxembourg 2026. Find all the talks from this track/village here: https://archive.org/details/BSidesLuxembourg2026/d1+t2+05+OpenTide%3A+From+Raw+Intelligence+To+Structured+Threat-Informed+Detections+-+Remi+Seguy.mkv #BSidesLuxembourg2026 #ThreatIntelligence #DetectionEngineering #CTI #OpenSource #BlueTeam
0
0
0
0

🎯 AI-run attacks and SOC detection gaps

The article raises a practical question from a post-incident debrief: "There were alerts. They did not rise to the right level. How does the SOC miss this?" The gap isn't in signal generation but in alert severity and escalation logic.

The core problem

AI-driven attacks operate across multiple paths simultaneously, with no single event being critical enough to trigger paging. Traditional alert rules, tuned for single high-severity events, miss the aggregate pattern. Alerts fire but stay below the threshold that would wake someone at 2 AM on a Saturday.

What "ready" looks like

Three concrete detection strategies are proposed:

  1. Alert-severity rules for slow, multi-path attacks: Rules that aggregate low-severity signals across paths, so that no single event needs to be critical for the on-call person to get paged. The trigger is the pattern, not the individual event.

  2. Baseline of your own automation: Establish what your legitimate automation looks like (scheduled scripts, service accounts, API calls) so that hostile automation becomes distinguishable. Without a baseline, an AI agent running reconnaissance at machine speed blends into normal noise.

  3. Deception seeded throughout the environment: Canary files, honeytokens, fake shares. A fast, indiscriminate AI agent trips these because it doesn't have the context to avoid them. A careful human adversary would walk past them.

Relevant SANS courses • SEC555: Detection Engineering and SIEM Analytics (GIAC GCDA) • SEC541: Cloud Security Threat Detection (GIAC GCTD) • SEC599: Defeating Advanced Adversaries: Purple Team Tactics and Kill Chain Defenses (GIAC GDAT)

Analysis

The article doesn't present a specific incident or IoCs. It's a conceptual framework for detection engineering against AI-driven threats. The core insight is that detection logic built for human-speed, single-path attacks won't catch AI agents operating across multiple vectors simultaneously at machine speed.

The deception approach is the most immediately actionable. Canary-based detection doesn't require new analytics pipelines, it just requires seeding artifacts that only a non-human actor would touch.

The automation baseline concept is sound but operationally harder. Most organizations don't have a clean inventory of what their own automation does, making it difficult to establish a useful baseline.

The SANS course references suggest this content is tied to training curriculum rather than independent research. The framework itself is preliminary, no empirical validation is provided.

🔹 AI #DetectionEngineering #SOC #SANS #Deception

🔗 Source: https://www.sans.org/go/readiness-for-ai-automated-attacks?utm_medium=Organic_Social&utm_source=Twitter&utm_content=Rob_T_Lee&utm_campaign=Critical_Advisory_Urgent_Sandbox_Guardrails&utm_rdetail=Global&utm_goal=Community_Awareness&utm_type=Thought_Leadership

0
0
0
0

🚨 Incident Response: Unifying Detection Engineering and Digital Forensics with Velociraptor

A new research paper proposes a unified detection-forensics methodology using Velociraptor, bridging the gap between real-time alerting and traditional forensic analysis. The core concept is that detection logic directly initiates targeted evidence acquisition at the point of detection, rather than operating in parallel.

The paper introduces a four-stage methodology to convert artefact knowledge into reusable and testable detection rules suitable for both post-incident triage and live monitoring:

  1. Baseline establishment
  2. Evidence correlation
  3. Attack chain analysis
  4. Scenario labelling with confidence

The researchers demonstrate this approach using three Velociraptor BaseVQL log sources: forensics/windows/prefetch, forensics/windows/usn, and /windows/wmi. They show that artefact-based detections enable scalable forensic triage without the need for full disk acquisition. Additionally, periodic artefact analysis offers continuous monitoring while substantially reducing data volume compared to conventional endpoint logging.

Two case studies illustrate the practical application:

First, a Prefetch and USN baseline for triage when Windows Event Logs are cleared or unavailable. Attackers routinely disable or clear volatile log sources (MITRE ATT&CK T1070.001). Relying on these logs for SIEM-based detection creates a single point of failure. By establishing baselines with Prefetch and USN Journal data, responders can reconstruct past activity even when standard logging mechanisms are compromised.

Second, a WMI persistence correlation that supports both triage and continuous monitoring through periodic artefact analysis. Windows Management Instrumentation (WMI) is a common technique for maintaining persistence. Correlating WMI artefacts allows defenders to detect these mechanisms without relying solely on real-time event forwarding.

The implications of this methodology are significant for SOCs and IR teams. By shifting some detection logic to endpoint artefacts rather than exclusively forwarding volatile logs to a SIEM, organizations can maintain visibility even when attackers attempt to cover their tracks. This approach also addresses the data volume problem that plagues many SIEM deployments, as periodic artefact collection is more efficient than continuous event logging.

For practitioners, the paper provides deployable BaseVQL queries that can be used immediately. The integration of detection engineering with forensic artefacts provides a more resilient detection strategy.

🔹 DFIR #Velociraptor #DetectionEngineering #DigitalForensics #IncidentResponse

🔗 Source: https://arxiv.org/html/2606.28812v1

0
0
0
0
📢 Come join us in Atlanta, GA November 13-14 at Monday Night Brewing - The Grove, for #DEATHCon 2026 on-site! 📢 We'll have a ton of excellent workshops and interesting environments to explore, focusing on #threathunting and #detectionengineering! 🔍 🏹 Meet fellow practitioners, learn something new, and enjoy some great food and beverages in a relaxed, friendly setting! 🤝 🥪 https://www.simpletix.com/e/deathcon-atlanta-2026-tickets-280161
0
0
1
0

🛠️ Tool: SigmaLineage MCP

Sigma hits without context are noise. SigmaLineage MCP is a FastMCP server that wraps three capabilities into a single AI-callable interface, designed to solve the false-positive problem that plagues detection engineering.

What it does

  1. Sigma Hunt (run_sigma) — runs Chainsaw against an EVTX folder with the full SigmaHQ rule set.
  2. Process Lineage Tracing (run_sigma_lineage) — for every Sigma hit, automatically traces the parent→child execution tree up to 5+ generations, building a full kill-chain view.
  3. Rarity Baseline Engine (rare_events_baseline) — statistically surfaces anomalous process-to-port connections, suspicious user-log event combinations, and unusual URL lookups that don't fit the baseline.

The false positive problem

regsvr32.exe spawning a child process matches 40 Sigma rules and also matches every legitimate COM registration. wmic.exe executing a command could be lateral movement or your asset management tool. cmd.exe spawned by mmc.exe looks terrifying until you realize it is normal DCOM-based remote management. The alert alone tells you nothing. The parent chain tells you everything.

How lineage tracing works

SigmaLineage uses the Rust-backed evtx Python parser to build an in-memory process graph from Sysmon Event ID 1 (process creation) and Security Event ID 4688 in your EVTX corpus. It resolves ancestry using ProcessGuid strings for Sysmon events, and uses a PID + timestamp closest-fit algorithm for Security events that lack GUIDs. The result: for every Sigma hit, you get the full execution tree rendered in markdown.

Real example from EVTX-Attack-Samples — impacket wmiexec:

[WmiPrvSE.exe (PID: 836)] └─ [cmd.exe (PID: 2828)] (HIT) cmd.exe /Q /c whoami /all 1> \127.0.0.1\ADMIN$__1556656369.7 2>&1 └─ [whoami.exe (PID: 3328)] (HIT) whoami /all

One look and you know: cmd.exe spawned by WmiPrvSE.exe, writing output to the ADMIN$ share via a UNC path. Textbook WMI exec pattern. Not a false positive.

Compare to a surface-identical alert where lineage shows [services.exe] → [PSEXESVC.exe]. Same alert, different root cause (PsExec), instantly disambiguated.

The rarity engine solves anomaly discovery rather than false positive reduction. It statistically surfaces unusual process-to-port connections, suspicious user-log event combinations, and URL lookups without needing a predefined rule.

Plug into any MCP-compatible AI client (Cursor, Claude Desktop, Antigravity, OpenCode). Describe what you want to investigate in plain English, get structured analysis back.

Note: haven't tested personally.

🔹 SigmaLineage #tool #DetectionEngineering #Sigma #MCP

🔗 Source: https://mohitdabas.in/blog/sigmalineage-mcp-evtx-hunting-lineage-first-triage/

0
0
0
0
Friendly reminder that the first round of DEATHCon tickets go on sale July 7th. I recommend setting a reminder and logging on earlier in the day (like, early morning) to purchase as they will sell out quick. DEATHCon is easily the best bang for your conference buck when it comes to the amount of presentations and available logs to cut your teeth on detection engineering and threat hunting. https://deathcon.io/tickets.html #deathcon #threathunting #detectionengineering #conference
0
0
0
0
Network defenders should take a look at and hunt for Overlord RAT, a publicly-available and open-source Go-based RAT. Proofpoint recently published a blog post highlighting its adoption by UNK_DeadDrop, a DPRK-nexus threat group which appears to have used a lightly modified version but can still be detected via Shodan, Censys, or FOFA queries. Proofpoint notes minor operational overlaps with Contagious Interview, but UNK_DeadDrop appears to prefer Overlord while Contagious Interview sticks with OtterCookie/InvisibleFerret. Regardless, extraction of TTPs is super easy when the source code is available and great for folks who want an introduction into detection engineering and/or threat hunting. For example, Overlord RAT ships with default self-signed certificates/port configurations. While advanced adversaries will obviously alter these settings, many groups won’t, including UNK_DeadDrop. This makes developing a baseline detection within Censys/Shodan/FOFA trivial for monitoring. The Censys query in the screenshot is rudimentary, but you get the idea. Start with low-hanging fruit and tune your queries to hunt for advanced adversaries who might be using more bespoke Overlord configurations. Once found, ingest and retro-hunt the IOCs in your environment. Overlord clients will establish C2 communications with these servers. https://www.proofpoint.com/us/blog/threat-insight/dont-fear-repo-unkdeaddrop-phishing-campaign-targets-developers-steal https://github.com/vxaboveground/Overlord #overlord #unk_deaddrop #RAT #detectionengineering #threathunting #cti #threatintel
0
0
0
0
You've seen all posts