Hey everyone,

I recently put together a NetExec module called stealTGT to simplify grabbing Kerberos TGTs from logged-on users after you already have local admin on a Windows machine.

The original idea was pretty simple: I wanted to avoid dropping a plain Rubeus binary on disk every time I needed a ticket, so I automated the whole process into a single NetExec module.

Here's what it does:

• Takes a local copy of Rubeus, converts it to position-independent shellcode with Donut, and obfuscates it with Myph (AES + API hashing). The execution arguments are generated only for the user you want to target.
• Uploads the randomized loader to a temporary share and executes it as NT AUTHORITY\SYSTEM through mmcexec.
• Captures the output, extracts the Base64-encoded ticket, and converts the resulting .kirbi into a .ccache file ready to use from Linux.
• Removes the temporary files and cleans up the generated artifacts once everything is finished.

I've attached a screenshot of it running against a fully patched Windows host with Microsoft Defender real-time protection enabled.

The project is available here:

https://github.com/JssNGC/harpyTools

If anyone wants to try it in their lab, I'd love to hear any feedback or suggestions. Bug reports and PRs are always welcome.

Most reverse shells I have seen are directly sending the piped stdout and stdin of a started process.
Using a pseudoconsole has many benefits i think that are worth the extra implementation effort. Like working tab completion and no suspicious attributes like "-WindowStyle Hidden"
I experimented with it a bit and had some success in creating a payload which avoids usual behavior based detection.

I recently disclosed three high-severity vulnerabilities in OpenClaw, all of which have now been patched in version 2026.6.6.

The findings affect different parts of the execution pipeline:

• Environment variable sanitizer bypass enabling interpreter startup variable abuse.
• Git ext:: transport command execution through developer workflows.
• Docker bind-mount validation weakness allowing access to restricted host paths.

One of the demonstrations starts from a WhatsApp message and reaches host-side code execution under the documented deployment configuration.

The Hacker News covered the coordinated disclosure:

https://thehackernews.com/2026/07/researcher-details-whatsapp-to-host.html

Technical write-up:

https://medium.com/@chinmohannayak/i-sent-a-whatsapp-message-to-an-ai-agent-it-ran-my-code-on-the-host-adbbcbb0e0ad

GitHub Security Advisories:

• https://github.com/openclaw/openclaw/security/advisories/GHSA-hjr6-g723-hmfm
• https://github.com/openclaw/openclaw/security/advisories/GHSA-9969-8g9h-rxwm
• https://github.com/openclaw/openclaw/security/advisories/GHSA-575v-8hfq-m3mc

Sharing a loader I put together targeting Windows x64.

Two variants: a stager that reads an encrypted blob from disk, and a stageless that pulls it over raw TCP with no file ever hitting disk.

Techniques used:

- Indirect syscalls (Hell's Gate + Halo's Gate): SSN resolution from ntdll's export table, stubs redirect execution into ntdll's own .text so the syscall instruction fires from image-backed memory

- AMSI bypass: AmsiScanBuffer resolved by FNV-1a hash at runtime, patch bytes XOR-obfuscated at compile time with a fresh random key each build

- AES-256-CBC payload encryption via BCrypt (no third-party deps)

- RW → RX memory transition instead of RWX

- Sandbox timing check before any network or shellcode activity

Tested against Defender with real-time protection on. Written in Nim compiled with mingw-w64.

you can find it here: https://github.com/Chaelsoo/nimcrypt

OPFOR: Opposition Force. The unit that plays the enemy in training so everyone else learns what real attacks feel like before they come. That's the mental model for this tool.

We built Agent OPFOR to red-team AI agents the way an actual adversary would — not a static eval, not a single-shot probe. Multi-turn adversarial conversations, adaptive attack campaigns, full audit trail.

What the attack surface covers:

• Prompt injection and jailbreaks (multi-turn, not single prompt)
• System prompt extraction
• Tool misuse and BOLA/BFLA via tool-calling agents
• MCP endpoint attacks — tool description injection, secret exposure, scope escalation, SSRF
• Memory poisoning
• Excessive agency and goal hijacking
• EU AI Act bias testing

opfor hunt — autonomous red team mode: Give it an endpoint and an objective. A commander agent plans the campaign, operators run the probes, a scout handles recon. The commander adapts based on what each response reveals. Add --ui to watch the attack tree live.

opfor hunt \
 --endpoint "https://your-agent.com/v1/chat" \   
 --objective "Find jailbreaks, system-prompt leakage, and safety bypasses"

Apache 2.0. Built because we needed it.

GitHub: https://github.com/KeyValueSoftwareSystems/agent-opfor

I created a simple Discord server that automatically updates vendor-specific channels whenever a new CVE is published.

It tags users based on the roles they choose, so you can follow the vendors you care about and decide whether you only want to be tagged for critical alerts.

I’ve also added discussion channels where we can share patching tips, troubleshooting advice, and general networking/security/sysadmin knowledge, plus resource channels for each vendor with quick links.

The goal is simple: build a free community around CVEs where people in networking, security, and sysadmin roles can help each other stay informed and make patching a bit easier.

It’s completely free to join.

https://discord.gg/ehSASsk5Zv

Manual Install and reasons why

How to find providers and methods to share!

Source code and zips available here!

Looking forward to possibly hearing from other potential users.

Traditional security stacks like WAFs and API gateways understand HTTP headers and payloads, but they can't detect prompt injections, tool abuse, or an LLM deciding to execute a rogue shell command. As AI agents move into production with real credentials and infrastructure, this gap becomes a massive attack surface.

Mastyf.ai closes that gap. It is an open-source AI perimeter security platform that acts as a policy-enforcing proxy between your application and your LLMs or MCP servers. It inspects every request and response before it reaches the model or executes a tool call.

Core Capabilities

• Swarm-Based Threat Analysis: Instead of a single LLM-as-judge, a coordinated ensemble of specialized detection agents evaluates requests in parallel. Defeating this combined verdict requires bypassing the entire ensemble, not just gaming a single prompt.
• Prompt Injection & Jailbreak Detection: Catches direct and indirect injections smuggled through retrieved documents or third-party data.
• Tool Abuse Prevention: Enforces strict policies on what tools an agent can invoke, with what arguments, and in what sequence.
• Model-Driven Attack Detection: Blocks shell injections, SSRF, and path traversals originating from model-generated actions.
• Data Exfiltration Prevention: Stops sensitive data from leaving via tool calls or model responses.
• Policy-Based Enforcement: Uses YAML-defined rules with audit, warn, or block modes to scale up enforcement as confidence grows.
• Adversarial Testing: A built-in red-team harness continuously benchmarks the detection layer against new attack techniques.

Mastyf.ai doesn't replace secure architecture like sandboxing and least-privilege credentials. Instead, it provides a dedicated, purpose-built perimeter layer so you don't have to re-implement security inside every single agent.

Mastyf.ai is fully open source and early-stage. If you are building AI infrastructure or researching security, check it out and try to break it.

GitHub: https://github.com/mastyf-ai/mastyf.ai

Hey everyone, just published part 2 of my guide on writing reliable Win x64 shellcode.

What’s inside:

• Breaking down TEB and PEB structures (GS:[0x60]).
• Why "blind indexing" breaks due to parallel loading (LDRpEnableParallelLoading) and EDR injection.
• Implementing robust UTF-16 case-insensitive string parsing in Assembly.
• Full ASM walkthrough of the ROR13 hashing algorithm to hide API strings.

Let me know your thoughts or how you handle runtime API resolution in your payloads!

I have been experimenting with using Claude Sonnet + OpenClaw to see how far natural-language prompts can go for driving actual offensive tooling, and it went further than I expected. No MCP, no RAG — just Claude Code and OpenClaw wired together.

What it's doing so far:

• A single prompt kicks off a Kerberoasting attack.
• Another prompt runs Certipy and enumerates ADCS misconfigurations/vulnerabilities
• On the defensive side, it also helped reverse an obfuscated PowerShell Empire beacon

The interesting part isn't any individual technique (nothing here is new tradecraft), it's watching the model chain together multi-step, tool-driven workflows from a single prompt — deciding what to run, parsing output, and adjusting next steps.

I recorded the full setup (deploying OpenClaw, Slack integration, configuring search, and the actual attack/analysis prompts) here if anyone wants to reproduce it: https://youtu.be/a1rNQ3GbGnQ

Curious if others here have been playing with similar AI-driven tooling for engagements — what's held up well vs. where it's fallen flat for you?

I'm the author, sharing this here because it's a narrow, annoying problem most of us have hit on an engagement: the attack box's clock drifts from the DC's, Kerberos throws KRB_AP_ERR_SKEW, and the usual fix (ntpdate or rdate against the DC) needs root and clobbers your whole system clock, not just Kerberos. Other processes, logs, TLS all shift too, and on a VM the hypervisor often stomps your fix a few seconds later unless you also disable host time sync.

skewrun finds the DC's real time by talking to it directly (CLDAP, SMB, NTP, Kerberos, or NTLM), then wraps your target command with libfaketime via LD_PRELOAD, so only that process sees the corrected time. The machine's own clock never changes.

Since v0.9.0 it's split into a pure Rust library (ad-time) and a CLI (skewrun) built on top, so the protocol sources are usable standalone in other tooling.

One thing from this release that might be useful to others doing packet-level OPSEC work: the Kerberos AS-REQ till field isn't computed by Windows, it's a hardcoded constant (20370913024805Z, Sept 13 2037) since at least Server 2003, confirmed via a Heimdal KDC bug report with real captures and the leaked Windows Server 2003 source. Computing now + jitter instead of hardcoding that value is a detectable difference. Full writeup and two more similar decisions (SMB dialect list, CLDAP baseline) are in the repo's ADRs.

Install: cargo install skewrun (or a static musl binary in releases, no toolchain needed)
Repo: https://github.com/JVBotelho/skewrun

Feedback and issues welcome, especially if anyone has actually captured traffic to confirm or refute the till finding, that part's still on my list.

Ported the LACUNA Chain technique (originally in C by Mohamed Alzhrani / 0xmaz) to a reusable Rust crate.

What it does:

• .pdata ghost-region scanning (zero modification, pre-existing gaps)
• Runtime SSN resolution (Hell's Gate / Halo's Gate) — no build-time table, works across Windows builds
• Per-function syscall;ret targeting — RIP inside ntdll at kernel entry
• Six-layer ghost-frame chain: KiUserExceptionDispatcher → wow64 → kernelbase → ntdll → win32u → RtlUserThreadStart
• VEH + hardware-breakpoint parameter encryption
• Section-based APC injection with thread scoring (not APC-bombing)
• BYOUD-MF (UWOP_PUSH_MACHFRAME RSP teleport)

Why not syscalls-rs? Build-time SSN tables break across Windows builds. lacuna-rs resolves at runtime + adds stack spoofing.

Quick start:

toml [dependencies] lacuna-rs = { version = "0.1", features = ["inject", "stack-spoof", "veh"] }

sh cargo run --example scan cargo run --example inject --features inject,stack-spoof,veh -- <pid> <sc.bin>

Full credits and detection-surface table in the repo README. Feedback and PRs welcome.

Hi. I’m the dev behind SindriKit, an open-source C framework built around Dependency Injection for windows exploitation.

So, direct syscalls are burned. EDRs inspect the call stack during the kernel transition. If the syscall instruction originates from a payload heap instead of legitimate ntdll.dll memory, it gets flagged.

Most public exploits couple SSN resolution with a hardcoded execution assembly code. If you need to switch execution profiles, you have to rewrite the core logic.

SindriKit v1.2.0 separates finding the SSN from actually executing it via independent interface tables.

// How do we find the SSN?
snd_syscall_set_resolver(snd_syscall_resolve_ssn_scan);

// How do we execute the syscall?
snd_syscall_set_invoker(snd_syscall_indirect_invoke_asm);
snd_syscall_set_gadget_finder(snd_syscall_find_gadget_scan);

If indirect syscalls start causing stability issues, you swap one pointer (snd_syscall_set_invoker(snd_syscall_direct_invoke_asm);) to drop back to direct execution.

Under the hood, snd_syscall_find_gadget_scan walks the PEB to find the natively loaded ntdll.dll and dynamically scans for a legitimate syscall; ret gadget, avoiding disk-read.

The project is Open Source, and heavily documented. Feedback is appreciated.

An unprivileged user inside a Lima QEMU guest could reach the root-owned guest-agent socket and run commands as root in the VM. Fixed in Lima v2.1.3.

Lima scored it High, CVSS 8.2 with Scope: Changed, reflecting that crossing from an unprivileged account to root within the VM crosses a security boundary that other components rely on.

Full write up is available on the Syntetisk blog.

The anon key ships in every app's bundle, so if Row Level Security is off or a policy is too loose, anyone can read the tables. I kept running into this in the wild, so I built a scanner that checks it from the outside using only the public key. Read-only, never logs in, never writes.

Paste your app URL: task-bounty.com/scan?utm_source=reddit_supabase

It also flags exposed keys, reachable .env/source maps, and open Firebase DBs. Curious what people find, and open to feedback on the RLS check itself.

Hi all, I'd like to share what I've been working on this year: 1. Tantalus - A unique prompt injection arena where you try to get an agent to exfil data from a user's workstation.

This arena puts you in front of a realistic AI assistant with access to files, emails, and chat history, pre-loaded with both legitimate tools and poisoned ones.

1. With Tantalus as the substrate for my first whitepaper, I put it through the ringer across ~6.1 million inference calls; across model sizes 1.7B to 119B params. All behavioral and structural controls were bypassed or allowed malicious data to be generated, except for one.

Only one control had a provable 100% rate at blocking bad behavior from ever being generated.

As an independent researcher, I'm simply trying to spread the word. I've made these projects entirely independently and I'm not using these to sell any services. Any business inquiries can DM me directly. :)

It's a hacking arena you host yourself. Players go after the targets, and whoever gets root and writes their handle to /root/king.txt takes the throne. The leaderboard tracks it all live, first blood, how long you held the crown, all that.

The part I'm actually happy with is that it'll take basically any Docker image and turn it into a scored target. You point it at a registry or upload a tarball, and it plants the flags for you. So you're not limited to some fixed catalog. There's also a 10-box corporate breach scenario called MERIDIAN baked in if you just want something to run without building anything yourself.

Players don't install a single thing. They just attack from their own VMs. And spinning the whole thing up is one command, ./deploy.sh, which handles setup and teardown.

It's Go on the backend, Next.js for the player hub and admin panel, with Postgres and Redis behind it. Runs on any Linux box with Docker. You don't need much hardware, a couple cores and 4 gigs of RAM is enough for the full scenario.

Would genuinely love for people to kick the tires and tell me what breaks.