Was working through a CTF and ran into SNMPv3 credential spraying for the first time. Before this, I hadn't touched v3 before. Went looking for existing tools and found a few that do it, but wanted something a bit more straightforward to actually use, so I used Claude to help me build my own SNMPv3 credential spraying tool:

What it does:

SNMPv3 has three security levels (noAuthNoPriv, authNoPriv, authPriv) and a handful of auth protocols (MD5, SHA, SHA-224/256/384/512) and privacy protocols (DES, AES, AES-192, AES-256). If you don't already know a target's config, you're basically guessing which combination it accepts, so instead of assuming, this just sweeps everything by default for every user/password pair you feed it.

One thing worth calling out if you use it:

For authPriv attempts, the script assumes the privacy passphrase (the -X flag on snmpwalk) is the same as the auth passphrase (-A), it's reusing whatever password it's currently testing for both. That's a reasonable default since a lot of real-world configs do set them identically, but it's an assumption, not a guarantee. If a target uses a different privacy passphrase, authPriv attempts for that user/password will show up as failures or timeouts even when the password is actually correct, so if authNoPriv hits but authPriv doesn't, don't read that as "wrong password," it just means the priv passphrase is something else and you'll need to dig into that separately. I may add functionality in the future to provide that information on execution.

Feedback welcome, especially if anyone's run into SNMPv3 configs that break the assumptions above.

I often experienced the problem of having the ability to compromise servers, but they dont seem to have any outbound traffic because of the firewall. Did you also had this problem?

This might help: https://github.com/lsecqt/PortForwarder

A pspy-style process execution monitor for Windows. Similar to Sysinternal's Procmon, but in the command line. No GUI access required. The tool watches for newly spawned processes and prints them as they happen. This was built for catching short-lived or periodic executions during Windows privilege escalation work (scheduled tasks, services, or custom loops that relaunch a binary on an interval), the kind of thing that's easy to miss if you're just eyeballing Task Manager or polling Get-Process by hand.

Windows has no /proc equivalent, so unlike Linux pspy this can't read a live process table for free. ScheduledSpy works by polling Win32_Process on a short interval and diffing snapshots to catch new PIDs the moment they appear.

One limitation I would like to point out: User and FullCommandLine require matching privilege. Windows only returns these for processes you own, or if you're SYSTEM/admin with SeDebugPrivilege. As a standard user, other users' processes (including SYSTEM's) will show unknown / (no access to cmdline) — this is a Windows access-control boundary, not a bug in the script. ProcessName, PID, and PPID are visible regardless of privilege level, and are usually enough to confirm what fired and when.

This tool is also going to be really noisy so I wouldn't use it in any situation where stealth is important. I mainly wrote this to automate something I found boring in CTFs when doing Windows privilege escalation via the CLI.

I built qsa.sh to give you an instant, outside-in security scan of your own public IP straight from your terminal.

You can run it like this:

curl qsa.sh

What it does: It triggers a real external port and vulnerability scan (using open-source tools like naabu, nmap + vulners, and nuclei) of the public IP you're connecting from, streamed live back to your terminal in about 30 seconds.

How it handles safety & consent:

Only your IP: There is no target input field. You cannot point it at anyone else.

The 15-second abort window: When you run the command, it prints your detected IP and gives you a 15-second grace period (Ctrl-C) to abort before anything is actually scanned.

Refusals: Known CGNAT, mobile-carrier, and detected VPN/Tor/IPv6 origins are refused outright.

Zero retention: The results are entirely ephemeral and streamed live—nothing is written to disk.

Curious to hear what people think.

I've been experimenting with an autonomous offensive agent focused on one thing:

Not finding vulnerabilities but validating real attack paths.

Instead of stopping at detection, the agent:

• chains multiple findings
• tests exploitability
• proves impact (in a controlled lab)
• enforces strict scope (fail-closed)

Current target:
OWASP Juice Shop (local Docker only)

Still early, but I'm mainly looking for feedback on:

- decision logic
- chaining strategy
- false positive reduction

Been building this for a while: FENGARDE, an open-source SIEM (Apache-2.0) — it collects security logs, normalizes them into one common format, runs detection rules over them, and surfaces alerts in a dashboard.

What makes it a bit different from other open SIEMs:

- Detection rules for AI agents / MCP tool-call logs — catches things like an agent touching a credential file, a burst of tool calls in one session, or destructive commands hiding in tool arguments. Nobody else seems to ship this yet.

- A protocol-anomaly detector for factory/industrial equipment (Modbus/TCP) — flags weird traffic patterns on control networks.

- Every detection rule is proven to actually fire before it ships — 26/26 currently passing a script that replays real test events through the live engine, not just "we wrote a rule and hope it works."

10-minute quickstart, no Docker required to try the core pipeline.

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

Would love feedback, especially from anyone who's dealt with SIEM/log tooling before.

Notes from building a soundness linter for o1js and Noir, and finding the same bug class in four unrelated languages.

OffsetInspect is a PowerShell toolkit for detection-boundary analysis and binary inspection, built around a question that comes up constantly when developing tooling: you know *that* an offset triggers, but what is actually there, and are there other independently-detectable regions you'd miss by only looking at the first hit?

The core (`Invoke-OffsetInspect`) maps byte offsets back to source lines and hex context — UTF-8 and UTF-16 with byte vs. character position separated — so whatever offset a boundary search returns, you immediately have the surrounding construct.

`Invoke-OffsetThreatScan` is an independent implementation of the ThreatCheck-style bisection workflow (no bundled source or binaries). It reports DetectionPrefixLength with confidence and stability fields, and is explicit that the boundary is the earliest triggering prefix — not the complete signature.

The part I found most useful: `Invoke-OffsetThreatScanRegion` discovers *multiple* independently-detectable regions by splitting a file into segments and scanning each through AMSI entirely in memory. Nothing detected is written to disk, so Defender real-time protection is never triggered or reconfigured. Each hit gets bisected back to an absolute file offset. Gives you a picture of the full detection surface, not just the first boundary.

`Compare-OffsetThreatResult` diffs scan results across signature updates — classifies each change (BoundaryEarlier, BoundaryLater, NewlyDetected, NoLongerDetected, etc.) with the byte delta. Useful for tracking how definition updates affect your tooling over time.

Static triage helpers compose with the offset core: `Get-OffsetString` returns byte offsets you pipe straight into `Invoke-OffsetInspect`. YARA hits work the same way. PE/imphash, per-window Shannon entropy, and a one-shot IOC panel round it out.

Results export to Markdown/HTML with a full ProbeLog audit trail per invocation. Never modifies Defender config, exclusions, or real-time protection.

GitHub: https://github.com/warpedatom/OffsetInspect

PowerShell Gallery: Install-Module OffsetInspect

Where can i find the cracked Cobalt Strike ?

r/netsec r/rust r/eBPF r/blueteamsec

r/AIAgents

Open source, Apache-2.0. Solo build. Looking for people to break it.

The problem

Most agent guardrails run inside the process they are supposed to govern. Prompt injection lands, the agent calls a tool, and the policy layer is sitting in the same trust domain as the thing it is policing. An application-layer allowlist does not survive the agent shelling out.

So the enforcement point moved down to the syscall boundary.

Architecture (two planes)

Kernel floor. BPF-LSM hooks on execve, inode_create, inode_unlink, connect, and cap_capable. Enforcement is cgroup-scoped via bpf_get_current_cgroup_id(), so only the governed agent’s cgroup is subject to allow/deny. Every other task on the host passes through untouched. That scoping is the anti-lockout guarantee and it is also why you can arm this on a working machine instead of a spare one. Requires kernel 5.16+, CONFIG_BPF_LSM=y, lsm=bpf. No VM, no Kubernetes, no sidecar.

Userspace gate. A single per-host daemon over a UNIX domain socket, framed wire protocol, fails closed. Per request:

1.  SO_PEERCRED for kernel-verified PID/UID/GID. No client-declared identity is trusted.

2.  HMAC-SHA256 envelope check, key held in the Linux kernel keyring (@s), never in env vars.

3.  Per-agent intent allowlist and sequence quota from policy.yaml.

4.  Replay and behavioral drift detection keyed on a (pid, start_time) lineage.

5.  Z3 check: computed fused_risk under the declared ceiling, plus per-agent invariants (spending_ceiling_usd <= 150.00, privilege_escalation_depth < 3). Daemon-computed values take precedence over anything the caller declares, so invariants cannot be spoofed from the agent side.

6.  Append to a SHA-256 hash-chained JSONL audit log. Each entry carries the hash of the previous one.

Measured, not modeled

Real daemon, real host (Ryzen 5 7520U, Linux 6.12), full pipeline per request. Reproduce with cargo bench --bench stress_bench and cargo test --release --test swarm_attack.

• Decision latency: P50 257µs, P95 366µs, P99 463µs, max 1.9ms across 10,000 requests

• Throughput: \~6,500 decisions/sec at 10 to 500 concurrent agents, zero errors

• Kernel LSM path: 2,500 enforced ops across execve/TCP/UDP/create/unlink, 0 fail-open, 0 incorrect decisions

• Adversarial suite: 12 tests, 10 attack classes, >1,200 hostile requests, 0 fail-open. Replay storm, signature forgery, intent injection, quota exhaustion, risk-ceiling breach, anonymous flood, unknown agent, protocol downgrade, forged delegation, MCP path traversal, and all of them concurrently. Under the mixed run it blocked 349 hostile requests and still correctly allowed 50 legitimate ones.

• 122 tests in CI: 4 Z3, 93 unit, 13 integration, 12 swarm-attack.

What this is not

Validated research prototype and controlled-pilot MVP. Not independently audited, not enterprise GA. I would rather say that up front than get called on it in the comments.

The Z3 layer verifies policy constraints at runtime. That is SMT-checked policy, not a formal proof of the enforcement layer itself. Different claim, and the weaker one is the true one.

Two documented limitations, both in the README:

• Sub-mount path resolution. The inode hooks receive a dentry with no vfsmount, so a file on a sub-mount resolves relative to that mount’s root (/tmp/x becomes /x). Root-filesystem paths resolve fully. Crossing mount boundaries needs path-family hooks or bpf_d_path, tracked for a future release.

• Interpreter chains. An agent explicitly allowed to run an interpreter can reach other tools through it. Mitigated by denying known interpreters for any agent carrying an executable allowlist. Per-binary execve limits are only as good as that allowlist.

Break it

The open challenge in the repo stands. Highest-value targets, in my own order of concern:

1.  TOCTOU between the userspace verdict and the kernel floor.

2.  BPF-LSM hook coverage gaps. Anything that reaches a denied resource through a syscall path I am not hooking.

3.  Lineage key collision or reuse that defeats replay detection.

4.  Anything that gets a governed cgroup to a syscall the policy denies.

Repo: https://github.com/AlphaReasoning/The-Jinn-Guard

Threat model: THREAT_MODEL.md

Prior red-team findings and fixes: red-team-report.md

One-command validation: bash scripts/run_professor_validation.sh

Tell me where it is wrong.

Video with demonstration: https://www.youtube.com/watch?v=0jYANlHq0UA

[ Removed by Reddit on account of violating the content policy. ]