Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ghostpack/rubeus/llms.txt

Use this file to discover all available pages before exploring further.

Operational security is not an afterthought when using Rubeus — it is the frame around every decision you make. Any action performed on a domain-joined host carries detectable risk, and Rubeus is no exception. Detection can come from the host (abnormal process behavior, API calls, tickets on disk), from the network (raw Kerberos port 88 traffic originating from a non-LSASS process), or from domain controller event logs (encryption type anomalies, unusual ticket request patterns). Understanding the specific signals each Rubeus operation emits — and the flags that suppress them — is what separates a careful operator from one who lights up a SIEM.
Running Rubeus entirely in-memory (as a loaded .NET assembly or via execute_assembly) avoids on-disk AV signature scanning. However, in-memory execution still carries its own signals: the CLR being loaded into a non-.NET host process is observable, and PowerShell V5 script block logging combined with AMSI will capture the assembly loading sequence if PowerShell is used as the delivery vehicle.

​
Overview

Rubeus is a fully managed .NET tool that implements raw Kerberos protocol operations directly, bypassing the Windows Kerberos SSP for many tasks. The critical design decision — and the biggest opsec distinction from tools like Mimikatz — is that Rubeus contains no code to open, read, or write LSASS memory.Ticket extraction relies entirely on the LsaCallAuthenticationPackage() API. From a non-elevated context, this means session keys for TGTs are not returned (the tgtdeleg command works around this using a Kekeo-style delegation trick). From a high-integrity context, Rubeus performs a GetSystem-equivalent token duplication to elevate to SYSTEM, then registers a fake logon application via LsaRegisterLogonProcess(). This is a more targeted approach than reading arbitrary LSASS memory, but LsaRegisterLogonProcess() is used by a very limited set of processes and is itself an anomalous signal.The key detection surface areas are:
  • Process issuing raw port 88 traffic — Kerberos traffic to TCP/UDP 88 is expected from lsass.exe. Traffic originating from a cmd.exe, powershell.exe, or injected process is anomalous and may be flagged by network monitoring or host-based EDR.
  • LsaCallAuthenticationPackage() from abnormal callers — API-level introspection can detect this call from unexpected processes.
  • RC4 (rc4_hmac) in Kerberos exchanges — Modern Windows domains (functional level 2008+) default to AES. An RC4 exchange in a mixed or AES-enforced environment is a strong “encryption downgrade” signal detectable at the host, network, and DC event log levels.
  • Abnormal tickets on the host — Unusual rc4_hmac ticket encryption types, unexpected SPNs, or tickets for accounts that do not normally authenticate from a given host.
Rubeus does not hook kernel objects, patch LSASS memory, or interact with ETW providers directly. Its footprint is narrower than Mimikatz in the LSASS dimension but still visible through Kerberos protocol behavior.

​
Weaponization

How Rubeus is delivered determines which defensive layers are relevant before any Kerberos operation even begins.
Delivery MethodDetection Exposure
Binary on diskStandard AV signature scanning applies. Compiled releases are not published precisely because static signatures are fragile and easy to generate against a known binary.
PowerShell in-memoryPowerShell V5 deep script block logging and AMSI both fire. The assembly loading sequence is visible in 4104 events. Empire-based delivery falls in this category.
Library referenceInherits whatever execution method the primary tool uses. No additional Rubeus-specific signal beyond the loaded assembly.
Unmanaged assembly (execute_assembly)Cross-process code injection is performed and the CLR is loaded into a potentially non-.NET host process. This injection signal exists for any .NET tool using this method, not just Rubeus.
Additionally, AMSI was extended to cover .NET assemblies starting with .NET Framework 4.8. Assembly load events are scanned before execution, meaning that simply calling [System.Reflection.Assembly]::Load() with a Rubeus byte array is subject to AMSI scanning in patched environments.Raw TCP/UDP vs. Windows API: When Rubeus performs asktgt, asktgs, or most other ticket request operations, it constructs raw Kerberos AS-REQ and TGS-REQ messages and sends them directly to the KDC over port 88 — it does not go through the Windows Kerberos Authentication Package. This means the traffic originates from the Rubeus process (or its host, in the case of injected execution) rather than from lsass.exe. Network-aware EDR and SIEM solutions that monitor which process owns port 88 connections will flag this as anomalous. The exception is asktgs without a /ticket argument: in that mode, Rubeus requests the service ticket via LSASS using the current logon session’s cached TGT, so the network traffic originates from LSASS — a more opsec-friendly path when Credential Guard considerations apply.

​
Credential Extraction

When elevated access is available and credential reuse is the goal, Rubeus and Mimikatz take fundamentally different approaches.Mimikatz opens a read handle to the LSASS process directly, enumerates logon sessions, walks authentication packages, and extracts reversible credential material including plaintext passwords where available. The sekurlsa::tickets /export variant carves tickets out of LSASS memory without the API layer. Because Mimikatz’s popularity has made LSASS handle opening a high-priority EDR target, this approach is actively monitored and blocked in many mature environments.Rubeus never opens a handle to LSASS. Instead, after elevating to SYSTEM via token duplication, it registers a fake logon application (LsaRegisterLogonProcess()) and calls LsaCallAuthenticationPackage() to enumerate and extract all tickets currently registered with LSA. The output is base64-encoded .kirbi blobs for each session.The equivalent Mimikatz commands for the same ticket extraction are:
mimikatz # privilege::debug
mimikatz # token::elevate
mimikatz # standard::base64 /output:true
mimikatz # kerberos::list /export
From an opsec perspective, LSASS memory access is more likely to trigger EDR prevention at the current moment. However, LsaRegisterLogonProcess() from a non-standard process is itself anomalous — it is used by a very limited set of Windows components — and full API-level baselining can catch it. Neither approach is invisible; the question is which detection is more reliably implemented in the target environment.
If you extract tickets and any of them carry rc4_hmac encryption in an environment that has migrated to AES enforcement, those ticket types will stand out clearly in DC event logs and on-host ticket inspection. Always prefer AES-keyed operations when possible.

​
Over-Pass-the-Hash

Over-pass-the-hash — turning an NTLM hash or Kerberos key into a fully-fledged TGT — is one of Rubeus’s most common use cases. The opsec tradeoffs differ sharply depending on whether RC4 or AES keys are used, and how the resulting ticket is applied.The RC4 downgrade problem: When an RC4 hash (/rc4) is used with asktgt, the resulting AS-REQ uses rc4_hmac encryption. In a domain with functional level 2008 or higher, this is an encryption downgrade signal. The DC logs event 4768 (TGT request) with an encryption type of 0x17 (RC4) instead of the expected 0x12 (AES256) or 0x11 (AES128). Security tools monitoring for this pattern will alert.Prefer AES256 when available. If you can recover an aes256_cts_hmac_sha1 hash (via sekurlsa::ekeys or lsadump::dcsync in Mimikatz), pass it with /aes256:
Rubeus.exe asktgt /user:jdoe /domain:corp.local /aes256:e27b2e7b39f59c3738813a9ba8c20cd5864946f179c80f60067f5cda59c3bd27 /createnetonly:C:\Windows\System32\cmd.exe
The /opsec flag on asktgt: By default, Rubeus AS-REQs differ in structure from genuine Windows-generated AS-REQs. The /opsec flag instructs Rubeus to first send an AS-REQ without pre-authentication — mirroring how a real Windows client initially probes the KDC — and only include pre-authentication in the follow-up exchange if the first request fails. This makes the traffic pattern more consistent with legitimate Kerberos behavior. The /opsec flag enforces AES256 by default and will refuse other encryption types unless /force is also passed.
Rubeus.exe asktgt /user:jdoe /aes256:e27b2e7b39f59c3738813a9ba8c20cd5864946f179c80f60067f5cda59c3bd27 /opsec /createnetonly:C:\Windows\System32\cmd.exe
The /createnetonly flag: Applying a TGT to the current logon session with /ptt overwrites the existing TGT — a destructive side effect and a potential indicator if the session is under monitoring. The /createnetonly flag creates a sacrificial process (LOGON_TYPE 9) with a new logon session, and the ticket is imported into that isolated session instead. The process is hidden by default; pass /show to make it visible. This mirrors Mimikatz’s sekurlsa::pth approach of creating a sacrificial session, without requiring any LSASS memory writes.
Rubeus.exe asktgt /user:jdoe /aes256:e27b2e7b39f59c3738813a9ba8c20cd5864946f179c80f60067f5cda59c3bd27 /createnetonly:C:\Windows\System32\cmd.exe /show /opsec
Even AES256-keyed TGT requests leave a distinct fingerprint in some environments. A TGT request using aes256_cts_hmac_sha1 from a workstation that does not normally authenticate interactively — particularly if the source process is not lsass.exe — can be correlated to over-pass-the-hash behavior. Baseline comparison is the most reliable detection method, not just encryption type filtering.

​
Windows Event IDs to Monitor

The following Windows Security event IDs are the primary domain controller log signals generated by Rubeus operations. Detection rules targeting these event IDs are the most common way blue teams catch Kerberos abuse.
Event IDTriggerRubeus Context
4768Kerberos TGT request (AS-REQ)Fires on every asktgt call. RC4 (0x17) encryption type in the event indicates a downgrade. When /nopreauth is used with kerberoast, AS-REQs are sent instead of TGS-REQs, generating 4768 events rather than the 4769 events commonly monitored for kerberoasting.
4769Kerberos service ticket request (TGS-REQ)Fires on asktgs, kerberoast, and delegation abuse. RC4 encryption type (0x17) is the primary kerberoasting indicator monitored by defenders.

​
Opsec Flags Quick Reference

These flags directly affect the opsec profile of Rubeus operations. Use them deliberately based on the environment’s detection capabilities.
FlagCommand(s)Effect
/opsecasktgt, asktgs, s4uSends an initial AS-REQ/TGS-REQ without pre-auth first, matching the pattern of genuine Windows clients. Enforces AES256 by default.
/rc4opseckerberoastUses the tgtdeleg trick and filters out AES-enabled accounts, roasting only RC4-only accounts. Avoids requesting RC4 downgrade tickets for accounts where AES is available (which is a strong signal).
/nopacasktgt, s4uRequests a ticket without a PAC (Privileged Attribute Certificate). Can reduce ticket size and may bypass some PAC validation checks, but may break authorization in environments that require PAC.
/createnetonlyasktgt, s4uCreates an isolated sacrificial logon session (LOGON_TYPE 9). Prevents stomping on the current session’s TGT and isolates ticket injection to a hidden process.
Note on /rc4opsec and kerberoasting: Without any flags, kerberoast requests tickets for all SPN-bearing accounts at their highest supported encryption. Requesting an RC4 ticket for an account that supports AES is a clear downgrade signal (event 4769 with 0x17 encryption type). The /rc4opsec flag avoids this by only targeting accounts that are not AES-enabled — those accounts will always produce RC4 tickets, so there is no downgrade to detect.

Build docs developers (and LLMs) love

Get started for freeTalk to us