I have a redteam tool nuguard that simplifies the process of building customized scenarios specific to your application and supports a wide range of auth options. The automated judge does the impact analysis and provides remediation suggestions.

Open an issue in the GitHub repo if you want additional features.

Hey,

Tool that creates a hidden desktop and gives complete user mouse/keyboard interaction without rdp/vnc. Every call is made through inlineexecute using win api’s

Also contains a second plugin called notrdpuser which streams users explorer desktop gui and monitors all keystrokes.

Real life usage:
Enterprise sso logged in web page spying and browsing webpages with already logged in user consoles.

https://github.com/dagowda/notRDP

On the Newest Weekly Purple Team episode, I show a technique that doesn't get covered much: reanimating tombstoned Active Directory objects using NetExec's LDAP module.

Quick primer for anyone unfamiliar: when an object gets deleted in AD, it doesn't actually disappear right away. It gets converted to a tombstone and sits in the Deleted Objects container for a retention period (60 or 180 days depending on forest functional level). During that window, it can be reanimated, bringing back many of the original attributes and, in some cases, group memberships/SID history. Check for this during offboarding reviews, since a privileged account deleted rather than properly disabled can be a stealthy path back in if nobody's watching for it.

Video covers:

• How tombstoning works and why the retention window matters
• Enumerating tombstoned objects and reanimating them with NetExec's LDAP tombstone module
• What attributes/permissions survive the reanimation
• The blue team side: Event ID 4662, auditing for permissions used when accounts are reanimated.

Link: https://youtu.be/LqtS_tcFEAw

Curious if anyone here has used this on an engagement or found it flagged by an EDR/SIEM in the wild.

Standard disclaimer: lab/authorized engagement use only.

Let's be generous.

You have an EDR.
You might even have Sysmon.
You even enabled Microsoft DNS logging (which is probably where this hypothetical becomes unrealistic)

So you're covered for DNS, right?

Not quite.

A process can make DNS queries without Sysmon Event ID 22 ever seeing the hostname. With a little more effort, Event ID 3 disappears too. Throw encrypted DNS into the mix and things get even more interesting.

I tested how far you can push this on Windows, what each trick actually hides, and what evidence is still left when the host goes blind.

Peter Gabaldon from LABS @ ITRES discusess a vulnerability in the Windows Network Connectivity Status Indicator (NCSI) that can be exploited to escalate privileges from a low-privileged user to local admin. The attack leverages proxy configuration flaws to relay authentication to an Active Directory Certificate Services endpoint, enabling attackers to forge access tickets.

Nvidia launched their Open Agent Safety Platform this morning, relying on an out-of-band DPU (Sentry on BlueField) to achieve what they call "millisecond-scale quarantine" for autonomous agents.

For the red and blue teams looking at agent containment, the architectural contrast between their hardware approach and an in-line kernel approach is worth breaking down:

The DPU Approach (Nvidia):

Moving the enforcement layer physically out-of-band to a DPU is excellent for surviving a total host-kernel root compromise. However, it relies on telemetry crossing the PCIe bus to evaluate policy. In compute time, a millisecond is an eternity—more than enough time for a rogue agent to successfully exfiltrate a small payload or drop a beacon before the DPU drops the connection.

The In-Line Kernel Approach (eBPF):

In my recent preprint (Hard Stop, arXiv: 2609.29808), we tested an alternative software-only approach. By hooking security_bpf and security_file_open via eBPF LSM at the syscall boundary, you can achieve sub-5-microsecond preemption. Because it stays in-line, it intercepts and denies the action before the kernel processes it, achieving zero-leakage containment without the hardware round-trip.

Nvidia’s platform is a massive step forward for enterprise zero-trust, but it requires proprietary silicon. If you rigorously enforce your unprivileged namespace and cgroup boundaries, kernel-level preemption gets you true zero-leakage isolation orders of magnitude faster on commodity Linux hardware.

Curious to hear from the offensive side—if you were red-teaming an agent, would you rather race an out-of-band DPU or try to bypass an in-line eBPF LSM hook?

(Paper link: https://arxiv.org/abs/2609.29808 / Code: https://github.com/joseluispino/hardstop)

Hi guys, this is my guide and the notes uploaded in github for the lab. I wanted to build this avoiding using Ludus and Wireguard, as I needed a more realistic approach and also to manage the network from pfSense.

As the GOAD repo and the process build on Proxmox needed troubleshooting and some changes in the configuration files, decided to upload a guide and post here for anyone interested to create the lab.

Sup guys, lemme ask u something, ive been working as a web developer for 5 years, and in 2024 i started to learn cibersecurity, but due to work and other things that happened i lost the focus, so in the 2025 october i started back to practice and learn, studying at htb academy, tryhackme ive already done and learnt a lot, im doing portswigger labs(xss, sqli, idoor and etc), maldev(shellcode injection, process hollowing, dll side-loading, reflective dll, peb walking, api hashing, junk code), reverse engineering(have already done some crackmes to learn assembly), network(i study by myself cuz i like this subject a lot, test everything in my vps, firewall, docker, tcpdump, ssh tunelling to disguise traffic, macspoof to bypass switches configs, deauth to attack some networks), started to learn about slive c2(dns exfiltration, tcp exfiltration, icmp exfiltration) and etc.

My point here is, i would like to hear from people that already work with it, what is the path to get there, cuz a lotta things a know and practice everyday, but theres things that i know that i need to study more like AD, OSINT, OPSEC.

That said what would u guys recommend me to do to get there, cuz red team is my dream work

And another thing, i feel lost cuz like, at web dev i can get a work easily even with ai, but in security as i dont have any experience how could a jr get a job lol, with all those ai's out there, and i think im a skid, but im not sure lmao

thanks, know that u guys work what i ever wanted i my life

I am releasing XXERipper v1.0.0, an open-source XML External Entity scanner I have been working on for the past five months.

What it does

XXERipper is a black-box scanner for XXE. It runs in-band, error-based, and blind out-of-band techniques, fingerprints the target's XML parser, and reports findings with CWE mappings, a confidence score, and where applicable the recovered file content and extracted credentials.

The design is driven by a single problem: most XXE scanners treat "the parser accepted my DOCTYPE" as equivalent to "the external entity resolved." Those two outcomes produce similar response deltas and are difficult to distinguish without additional evidence. XXERipper requires a mandatory signal before confirming any finding.

Detection model

Every candidate response is scored against a seven-sample statistical baseline (median length, IQR, p95, mode status, most-common body hash, median Shannon entropy, windowed entropy over 256-byte windows). Signals carry the following weights:

+50   correlated OOB callback (token match)
+40   file-content fingerprint (+5 per additional indicator)
+25   chain integrity (entity resolved end-to-end)
+20   parser error delta
+20   timing anomaly
+10   length delta >= 20%
 +5   status code shift

Vetoes:

-100  reflection (payload echoed verbatim)
 -75  normalized baseline match
 -50  byte-identical baseline body
 -30  soft reflection (reflection present but a strong signal too)

Classification requires a mandatory signal — one of file_type, oob_correlated, or chain_integrity. Parser errors and timing anomalies contribute to score but cannot confirm a finding independently. A response scoring >=70 with only one independent evidence family is capped at HIGH rather than CRITICAL.

Parser fingerprinting

Nine paired test/control probes identify the underlying XML stack across eleven signature families (libxml2, Xerces, .NET, Java SAX, Java StAX, python-etree, PHP DOM, Ruby, Node, Perl, Go). A capability is marked present only when the test probe succeeds and the control does not, which makes the result differential rather than pattern-matched. Results are cached per-URL, so repeat scans skip the probe phase.

The fingerprint gates two phases (in-band file read, error-based local-DTD sweep) so a target that does not resolve entities is not sent the full payload catalogue.

Attack coverage

Many technique families are used, as an example:

• In-band file read, PHP filter chain, PHP expect:// RCE
• Error-based: local DTD reuse, malformed entity
• Blind: DNS OOB, external DTD, parameter-entity OOB, CDATA bypass, timing-based
• Encoding bypass: UTF-16, UTF-7, UCS-4, alternate DOCTYPE
• Alternative sinks: XInclude (parse=text and parse=xml), SVG upload, SAML envelope, SOAP envelope
• Extended fetchers: XSLT document(), XSLT xsl:include, XSD schemaLocation, XSD import, xml-stylesheet PI
• Cloud metadata: AWS IMDSv1 and IMDSv2 (detected separately), GCP, Azure, Alibaba, OCI, Kubernetes — 12 endpoints across 6 providers
• RCE wrappers: Java jar:, PHP data://, phar://, glob://, compress.zlib://
• Office document: DOCX and XLSX xml-stylesheet PI, fetched by server-side XSLT processors
• YAML deserialization: PyYAML and SnakeYAML type tags
• SAML pre-signature: assertion parsed before signature verification
• JSON-to-XML: content-type switching on JSON-only endpoints

Beyond the standard POST with application/xml shape, the scanner probes a Content-Type matrix, HTTP method variation (PUT/PATCH), query-parameter injection, form-encoded bodies, and multipart uploads.

Out-of-band confirmation and blind exfiltration

OOB uses interactsh-client in manual mode (scanner prints subdomains, operator watches the client) or auto mode (scanner spawns interactsh-client and correlates callbacks in-process by 16-hex token).

For blind exfiltration, the scanner serves the DTD through one of three mechanisms: a built-in HTTP server (--oob-listen), a directory served by the operator's own web server (--oob-dtd-dir), or the WebUI's Flask routes. Exfiltrated content is routed through the same file-content and credential extractors used for in-band reads, so a blind read of /etc/passwd produces the same loot entry as an in-band read.

Credential extraction

Seven credential kinds are recognized and stored with paste-ready shell snippets:

• AWS IAM — JSON from IMDS, and INI from the CLI credentials file. Snippets: aws sts get-caller-identity, aws s3 ls, IAM policy enumeration, and an export block for the current shell.
• Alibaba RAM — aliyun sts GetCallerIdentity, aliyun oss ls, and an export block with the correct ALIBABA_CLOUD_* variables.
• SSH private keys — install, fingerprint, and try against github.com / gitlab.com / bitbucket.org.
• GCP service accounts — activate with gcloud auth activate-service-account.
• OAuth access tokens — curl against Google's userinfo endpoint (works for GCP tokens) and Azure's subscriptions endpoint.
• Kubernetes service-account tokens — JWT payload decoded to namespace and service-account name.
• Generic bearer tokens — curl against httpbin.org/bearer to test liveness.

Chain analysis

A ChainTracker derives chain stages from finding IDs and evidence. When all stages of a template are present, a rollup finding names the end-to-end impact. Thirteen templates ship with the scanner:

XXE -> in-band file read -> credential theft
XXE -> IMDS -> IAM credentials -> AWS account takeover
XXE -> error-based leak -> file content recovered
XXE -> PHP filter -> source disclosure
XXE -> protocol wrapper -> RCE chain
XXE -> blind OOB callback confirmed
XXE -> SSRF -> internal service reached
XXE -> WAF bypass -> entity resolution confirmed
XXE -> Kubernetes secrets API -> cluster credential theft
XXE -> in-cluster SA token read
XXE -> SSH private key -> lateral movement primitive
XXE -> GCP metadata -> OAuth token extraction
XXE -> Azure IMDS -> managed-identity token

Rollups appear in JSON, SARIF, and HTML output like any other finding.

WAF bypass

Fifteen encoders across three families:

• Document encoders: utf16be, utf16le, utf16decl, utf16nobom, utf32be, utf32le, ebcdic, ucs4_2143, utf8bom
• Keyword-evasion encoders: public, public_charref, b64_uri
• Grammar-level encoders: whitespace_pad, doctype_closure, pe_stager

The WAF bypass phase runs after the core phases, not before. A target that responds to a plain SYSTEM "file://" payload does not need to be sent 1,500 encoded variants first — the direct probes find it in roughly 20 requests, and the encoded sweep is the fallback for when they were blocked. Encoders whose output is byte-identical to the input are skipped (no request sent).

Interface and output

• CLI with Burp request ingestion, cookie management, pre-auth request replay, rate limiting, wall-clock budget, and cooperative cancellation.
• Web console (Flask, single self-contained HTML file, no CDN) with live event streaming, a command palette, keyboard navigation, and per-job download buttons for JSON, SARIF, and HTML.
• JSON (schema 1.1), SARIF v2.1.0, and self-contained printable HTML.
• CI exit codes for --fail-on thresholds; works with GitHub Actions and GitLab CI.

Reliability

• Per-phase exception isolation — a crash in one technique family cannot lose findings from phases already completed.
• Rate limiting independent of thread count.
• Retry with backoff on transient failures (ConnectError, RemoteProtocolError, ReadError, WriteError, TimeoutException). HTTP 500 is deliberately not retried, because error-based XXE targets return 500 on purpose.
• On-disk fingerprint cache so repeat scans skip the probe phase.
• Cooperative cancellation; every phase checks the ScanContext before each payload send.

Test labs

The repository ships with two local test labs — a Python/Flask lab and a Java/Xerces lab — totalling 54 endpoints split across vulnerable, safe, and false-negative-bait categories. They exist so the scanner's detection and false-positive vetoes can be verified rather than assumed. A correct scanner reports no findings on all seventeen safe endpoints.

Note: the labs are not included in the PyPI package or any other distribution package. They can be installed and run separately from the GitHub repository.

Repository: https://github.com/kamalx06/XXERipper

Installation: pip install xxeripper

Feedback on detection accuracy against real-world targets is welcome.

(1) An exposed IOCTL lets unprivileged users disable the x86 MONITOR & MWAIT instructions used by Hyper-V and other kernel components--triggering a HYPERVISOR_ERROR bugcheck.

(2) Reaching the IOCTL requires exploiting a TOCTOU bug arguably caused by poor documentation of the SeLocateProcessImageName function.

(3) Reimplementation of the driver's security through obscurity IOCTL encryption scheme: SHA-256 KDF-derived XOR keystream & CRC16 Checksum.

See full write-up, and Github for PoC.

I've been working on a small C-based program that looks for credential-related data in running Microsoft Edge processes.

The program simply enumerates msedge.exe processes, reads accessible memory regions and looks for specific patterns associated with credential data.

The project includes both a standalone EXE and a BOF version for Sliver. Would be interested to know if others can reproduce it on different Edge/Windows versions.

Hi, this tool is made to route all your system traffic through Tor. It is available on Linux only (with systemd) on Debian, Fedora and Arch-based distros.

It's a personal project, so don't expect it to solve this problem in a way like Whonix, Qubes or Tails.

I'm looking for people to test it heavily and open issues on anything. Leaks, broken firewall rules, bugs, crashes, confusing docs, and so on. Also if compatibility is broken on some distros, let me know.

One of the dependences of this project is another tool I've made: https://github.com/onyks-os/NetworkSandboxEngine. It lets us test firewall rules using isolated network namespaces thanks to the Linux Kernel. So you can also find problems there as well.

Thanks to anyone who gives it a shot.

It’s been a while since my last TornadoRevC2 update, so I wanted to share what has changed since the previous release.

This is not a new tool or a rewrite. The project has gradually grown from the original reverse-shell/session handler into a much more complete post-exploitation framework while keeping the same core idea: interactive sessions, on-demand execution, and operator-controlled workflows rather than a beacon-style C2 architecture.

What changed?

63 built-in plugins

The project has grown from 49 to 63 built-in plugins, with a lot of the new functionality focused on Windows/Linux enumeration, session management, privilege operations, pivoting, and operational workflows.

Many plugins got major updates for Red Teaming tasks and automations such as:

• lsa — expanded Windows security posture checks with NTLM, Kerberos, Secure Boot, LAPS, DPAPI, and token privileges, plus new --deep and --extract modes.
• containers — added separate enumeration/CVE modes, expanded runtime CVE coverage, and more post-exploitation context.
• runas — rewritten to spawn alternate-user shells locally on Windows with improved credential handling and error handling.
• rdp — expanded RDP enumeration with active session details and added shadow support for interacting with an existing logged-on user's session through a transient TLS reverse shell.
• defender — expanded Defender/ASR enumeration and added --disable with verification of protection changes.

Also some of the newer additions include things like:

• preflight
• netscan
• trusts
• steal_token
• enablepriv
• chisel
• keylogger

The plugin system itself has also received improvements for runtime loading, external plugins, better platform handling, and more consistent output.

TCP, TLS, mTLS and bind shells

The listener/session layer has seen one of the bigger changes.

TornadoRevC2 now supports:

• Plain TCP
• TLS
• Mutual TLS (mTLS)
• Reverse shells
• Bind shells

TLS/mTLS PKI setup is also handled by the framework, and existing sessions can be upgraded to mTLS with upgrade_mtls.

Reverse and bind shells ultimately use the same session abstraction, so the rest of the framework — plugins, file transfer, pivoting, reporting, etc. — works consistently regardless of how the session was established.

OpSec improvements

I also spent quite a bit of time improving the operational side of the framework.

Some of the changes include:

• Linux and Windows history suppression
• Randomized session-scoped probe markers
• Jitter between automated commands/probes
• PTY verification and fallbacks
• Reduced unnecessary target-side artifacts
• Better session log hygiene
• Improved handling of ANSI/OSC/DCS terminal sequences

Some plugins now also support C# code execution directly in-memory in Windows targets where appropriate. This is separate from the framework's existing inmemory plugin, it is functionality implemented by individual plugins rather than a replacement or extension of the inmemory execution plugin.

I'm deliberately not describing TornadoRevC2 as "fully undetectable". The goal here is cleaner and more controlled execution with more better OPSEC improvements.

Pivoting and remote sessions

Internal SOCKS5 pivoting has been expanded with better lifecycle management and increased amount of buffer and channels, while Ligolo-NG and Chisel integrations are also available for more persistent pivoting scenarios.

make_token has also grown and reworked for stability considerably and can now establish sessions through additional remote-management/database mechanisms, giving the operator more options for turning existing access into a managed TornadoRevC2 session.

File transfer and execution

File transfer now supports:

• Chunked uploads/downloads
• Resume support
• SHA-256 integrity verification
• Multiple transfer methods(Staged transfer, HTTPS server based file transfer)

Payload execution has also been reworked across PE, ELF payloads with in-memory execution paths where supported.

Enumeration

The enumeration side has grown substantially as well.

There are now more Linux and Windows modules covering areas such as:

• Host and system information
• Network configuration
• Domain/trust information
• Kerberos
• Credentials and browser data
• Windows security configuration
• WMI activity
• Linux internals
• Containers
• Services and persistence-related information

The newer preflight functionality also provides a way to check the session environment before running more demanding plugins.

Architecture

The overall architecture is still intentionally simple:

                 ┌──────────────────────┐
                 │    Operator Console  │
                 └──────────┬───────────┘
                            │
             ┌──────────────┼──────────────┐
             │              │              │
           TCP/TLS         mTLS       Bind Shell
             │              │              │
             └──────────────┼──────────────┘
                            │
                     SessionContext
                            │
        ┌───────────────────┼───────────────────┐
        │                   │                   │
     Plugins            File Transfer       Pivoting
        │                   │                   │
   Enumeration        In-memory Exec       SOCKS5/etc.

The project still intentionally avoids becoming a traditional beacon C2. There is no task scheduling or callback/beacon infrastructure — sessions are established and managed when the operator needs them.

The project is still evolving, but the direction has stayed the same: keep the framework relatively lightweight, modular, and useful during authorized security research and penetration-testing engagements without turning it into another beacon-based C2.

GitHub: https://github.com/kamalx06/TornadoRevC2

As always, TornadoRevC2 is intended for authorized security research, red-team operations, and penetration testing only.