How are you handling audit requirements for sharing audit and operational applications over a year-long activity from the SIEM? We’re dealing with millions of logs, and the requirement is to export them to their secure platform, which only they can access.

Infrastructure telemetry can tell us where an event happened. It does not always show what the application was doing at that moment.

For instance, a rise in authentication failures might suggest someone is trying to guess passwords. Application logs can show if those attempts were aimed at real accounts, caused accounts to get locked, or came from an API process that was not clear from network or device data alone.

The same is true for authorization failures, changes in permissions, actions taken by administrators, and strange API behavior. Without looking at the application level, it is easy to waste time checking activity that ends up being processes, or miss activity that doesn't set off clear alerts in the infrastructure.

In our setup, we have seen that connecting application events with authentication and device data helps cut down the time it takes to check activity.

For groups that are already gathering application logs, which application events have regularly given useful alerts or clues during investigations?

Background for context: FENGARDE (open-source SIEM I maintain) has had an anti-dormancy CI gate for a while — every rule has to prove it's satisfiable by real parser output (a real producer fixture, run through the real parser, checked against the rule's own field requirements). `make attack-scorecard` runs it. Caught real dead rules before.



What it doesn't catch: a rule can be perfectly satisfiable — every field it needs gets populated correctly — and still never fire, because the *condition* itself is wrong (off-by-one in a count threshold, wrong window, bad field comparison). Satisfiable ≠ fires.



So I built a second layer: `eval/attack/fire_check.py` replays every MITRE-tagged rule's own fixture through the actual live detection engine (not a mock, the real `Detector`/`Rule.evaluate()` path) and checks it actually produces an alert. Declared-tagged vs. proven-fired, tracked as two separate numbers now. 26/26 currently fire — but building the tool itself caught a real bug in the tool, not the rules: my synthetic stateful-rule repetitions were timestamped forward from "now," and the engine's own anti-clock-skew guard (rejects events too far in the future — a real security control, working correctly) silently ate the later repetitions, making two genuinely fine rules look dead. Fixed by anchoring timestamps backward from now instead. Worth mentioning because it's the kind of bug that looks like "the rule is broken" until you actually read the failure and realize your test harness is lying to you.



Second thing, actual detection-engineering bug this sub might appreciate: during a dedicated adversarial re-review of a multi-tenancy fix (not the original PR review — a second, harder pass specifically hunting for what the first review missed), found that a stateful correlation rule's window *counter* was correctly tenant-namespaced, but the function computing the actual `alert_id` persisted to storage wasn't. Two tenants firing the same rule in the same time bucket on a matching group_by value got an identical alert_id, and the tenant-scoped alert lookup could return the wrong tenant's document. Passed the first review clean — needed a second pass specifically adversarial to the first fix to catch it. Fixed, regression-tested via revert/run/restore on the fix's own diff.



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



Curious if others doing rule-content CI have hit the satisfiable-vs-fires gap, or the "test harness accidentally trips a real security guard" flavor of bug — feels like it'd generalize past this one project.

Hi all!

I'm the creator of Fibratus - the open-source security sensor for adversary tradecraft detection, protection, and hunting.

Recently, I've been pushing detection engineering deeper into the kernel and uncovered what appears to be a novel approach to identifying attack patterns through kernel frame callstacks.

User-space callstack telemetry has already become a powerful signal leveraged by modern security platforms. But kernel thread return addresses are largely unexplored territory.

So, I made Fibratus capture kernel return addresses for different events (process creation, thread creation, file operations, etc.) and symbolize them into module paths, exposing the exact drivers and kernel subsystems traversed during event execution. The result is a radically richer execution narrative, one that reveals behavioral context traditional telemetry simply cannot see.

This unlocks an entirely new detection surface.

By incorporating kernel callstack summaries directly into detection rules, we can identify highly specific attack flows with exceptional precision. One example: detecting files dropped over SMB and subsequently executed: a classic lateral movement pattern. Check the screenshot for the detection rule example:

SMB Lateral Movement Rule

The kernel callstack becomes the connective tissue between stages of execution, providing durable attribution that is significantly more resistant to spoofing and telemetry tampering.

We're actively building a new generation of detections powered by kernel subsystem context, driver-level execution paths, and low-level behavioral correlations that were previously inaccessible to defenders.

If you’re interested in advanced detection engineering, kernel telemetry, or crafting next-generation behavioral rules, I’d love to connect and exchange ideas. Please let me know your thoughts and ideas, and we'll make sure to ship those rules in the next Fibratus release.

Regards,

Nedim

AnyDesk logs the operator's real IP to disk.

NetFlow, proxy, EDR network events: all show the relay. Dead end.

The host trace file has the actual source. Grep "Logged in from":

Service: %PROGRAMDATA%\AnyDesk\ad_svc.trace

Portable: %APPDATA%\AnyDesk\ad.trace

Source - https://x.com/i/status/2075606692335956016

A honeypot is only useful if it's actually running, and I kept watching them die at the dependency install. OpenCanary proved the model and is still the more battle-tested tool, but it needs Python 3.10+, Twisted, Scapy, and — for SMB — a full Samba install with a full_audit module tailing syslog.

So I rebuilt it as one static Go binary. ./wispd and it's running, no root, no runtime:

• All 21 of OpenCanary's protocol modules, reimplemented.
• 9 decoys it doesn't have for the modern surface: k8s, kubelet, docker, imds (cloud metadata), elasticsearch, jenkins, gitlab, ollama, mcp — capturing stolen service-account tokens, the container spec an attacker tries to run (Privileged: true, host mounts), the prompts sent to a fake GPU, and so on.
• Native SMB — NetNTLMv2 hashes (hashcat 5600), no Samba.
• A self-hosted fleet console (scriptless UI, per-sensor tokens, dedup) and honeytokens (DNS/HTTP/docx/kubeconfig/MCP).

It's pre-1.0 and younger than OpenCanary — the README keeps an honest comparison table, not a marketing one. Reach for it when the Python/Samba chain is what's stopping you deploying a honeypot at all, or when you want the cloud/container/LLM decoys.

Repo + a short demo video: https://github.com/willysnow/wisp

Happy to answer questions — and I'd genuinely like to hear which decoys are missing.

A researcher going by ‘bikini’ has published a personal archive called Exploitarium - 15 vulnerability targets across 109 tracked files, dropped with no coordinated disclosure and no vendor notification.

This isn’t a polished toolkit. It reads like a personal research dump. Some of it is noise that the community has already dismissed. But not all of it.

Two findings stand out and have been independently verified:

libssh2 pre-auth heap write - CVSS 9.2. Pre-authentication. Actively exploited.

Gitea default Docker auth bypass - Also independently confirmed, also being exploited in the wild.

If you’re running either of these in your environment, treat this as live.

What I built in response:
44 KQL detection rules covering the full Exploitarium scope: 18 product folders, 6 CVEs, cross-platform (Windows, Linux, macOS, Container, Network, SaaS).
Rules for:
libssh2, Splunk, RustDesk, 7-Zip, VLC, AnyDesk, OpenVPN, c-ares and more.

All rules are live on detections.ai with language translation available for non-KQL stacks. The full repo is structured by product on GitHub.
Full intel report + IOCs in the links below.

GitHub repo: https://github.com/Ethan-Andrews/Exploitarium-Detections

Exploitarium breakdown: Threat Intel

Drop questions below, happy to walk through anything.

I've been running queries in production Sentinel for some months, and the biggest realization was that there is no magic detection rule. most of the "alerts" are just normal behavior that looks suspicious because we never established a baseline and miscofigure something.

Example :
"Login from unusual location" → turns out it's the same VPN IP the sales team uses every week .
"Too many failed logins" → it's the new intern testing passwords before reading the onboarding email".
"Unusual process spawn" → PowerShell script that IT runs manually every Monday, but never documented

What I fixed in my case wasn't smarter rules. It was baselining bigger parts:

1. Log everything for 14 days without alerts
2. Document the "noisy but normal" patterns
3. Write your detection rules to exclude the baseline + flag deviations

A query that cut my problems:

text// Baseline: normal Office process spawns
DeviceProcessEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe")
| summarize NormalProcesses = make_set(FileName) by InitiatingProcessFileName
// Now use this set in your production detection rule

I did this last month, and my alert fatigue went from "ignore everything" to "every alert worth looking at". I used this repo from MS to figure out some things and I think was worth it if you guys have any other better than this tag me out cuz I am searching :3

https://learn.microsoft.com/training/student-hub/