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.

A small set of flags in Rubeus are not tied to any specific command — they control output formatting, debugging behavior, and console redirection globally and can be appended to any Rubeus invocation. Whether you are running asktgt, kerberoast, dump, or any other action, these flags work the same way across the board. Understanding them saves time when building scripts, piping output to other tools, or diagnosing unexpected encoding behavior.

​
Flag Reference

​
/nowrap
flag
Prevents base64-encoded ticket blobs from being column-wrapped at 80 characters. By default, Rubeus wraps all base64 output to 80-character line widths, which makes console output more readable but breaks ticket blobs when they are copied directly into scripts or other tools that expect a single uninterrupted base64 string.
Rubeus.exe dump /nowrap

Rubeus.exe asktgt /user:jdoe /rc4:HASH /nowrap
The /nowrap flag is especially useful when saving output to a file for later processing. Any downstream tool or script that consumes the base64 ticket string — such as ptt, kerberos::ptt in Mimikatz, or a custom parser — expects a single-line base64 value. Wrapped output will fail to decode correctly unless the newlines are manually stripped first.
​
/debug
flag
Enables ASN.1 debugging output for all encoding and decoding operations performed during the command’s execution. When set, Rubeus prints detailed ASN.1 structure traces alongside the normal output. This is useful for diagnosing malformed tickets, unexpected decoding failures, or confirming that a ticket’s internal structure matches expectations.The Debug static field in Rubeus.Program is set to true when this flag is present, affecting all subsequent encoding/decoding paths in that execution.
Rubeus.exe describe /ticket:BASE64_TICKET /debug

Rubeus.exe asktgt /user:jdoe /aes256:HASH /debug
​
/consoleoutfile
string
Redirects all console output — both stdout and stderr — to the specified file path. The file is opened in append mode, so repeated invocations accumulate output rather than overwriting previous runs. This is implemented directly in Rubeus.Program.FileExecute(), which swaps the standard output and error writers to a StreamWriter before command execution and restores them afterward.
Rubeus.exe kerberoast /consoleoutfile:C:\logs\roast_output.txt

Rubeus.exe dump /nowrap /consoleoutfile:C:\ops\tickets.txt
Combine /consoleoutfile with /nowrap for clean, script-ready output files. Without /nowrap, base64 ticket blobs in the output file will be wrapped at 80 characters and will need post-processing before they can be used programmatically. Together, the two flags produce a file where every ticket blob is a single line, ready to be consumed by ptt or any other tool without modification.

​
Decoding Base64 Ticket Blobs

Rubeus outputs all Kerberos ticket data as base64-encoded .kirbi blobs. This format is the standard KRB-CRED structure and is directly compatible with Mimikatz and the Rubeus ptt command. The base64 encoding makes tickets safe to copy across console sessions, log to files, or embed in scripts. To convert a base64 blob back to a raw .kirbi file, use the following PowerShell one-liner (replace aa... with the full base64 string from Rubeus output): 
[IO.File]::WriteAllBytes("ticket.kirbi", [Convert]::FromBase64String("aa..."))
The resulting ticket.kirbi file can then be used in either of two ways: Import with Mimikatz: 
mimikatz # kerberos::ptt ticket.kirbi
Import back with Rubeus: 
Rubeus.exe ptt /ticket:ticket.kirbi
You can also pass the base64 string directly to Rubeus commands using the /ticket: argument without writing to disk: 
Rubeus.exe describe /ticket:aa...
Rubeus.exe ptt /ticket:aa...

​
Running Rubeus Through PowerShell

Rubeus can be compiled as a Class Library (.dll) and loaded entirely in-memory from PowerShell, avoiding on-disk EXE placement. To build as a library, go to Project → Rubeus Properties and change the Output type to Class Library, then compile. The resulting Rubeus.dll can be loaded and invoked from PowerShell as follows: 
$bytes  = [System.IO.File]::ReadAllBytes("C:\Tools\Rubeus.dll")
$asm    = [System.Reflection.Assembly]::Load($bytes)
$output = [Rubeus.Program]::MainString("triage")
Write-Output $output
The MainString method (defined in Rubeus.Program) accepts a command string, redirects all internal stdout and stderr to a StringWriter, executes the command via the normal MainExecute path, and returns the combined output as a single string. This is the correct method to call from PowerShell — using Main() directly will not return output usably in a remoting or captured-output context. You can pass any command string that Rubeus.exe would accept on the command line: 
$output = [Rubeus.Program]::MainString("asktgt /user:jdoe /rc4:HASH /nowrap")
Write-Output $output

​
Running Rubeus Over PSRemoting

The MainString approach works identically over PSRemoting sessions, where stdout capture is especially important because PSRemoting does not forward raw console output the same way a local session does. 
$result = Invoke-Command -ComputerName DC01 -ScriptBlock {
    $bytes  = [System.IO.File]::ReadAllBytes("C:\Tools\Rubeus.dll")
    $asm    = [System.Reflection.Assembly]::Load($bytes)
    [Rubeus.Program]::MainString("triage")
}
Write-Output $result
Alternatively, you can use a session object for repeated invocations without reloading the assembly each time: 
$s = New-PSSession dc.corp.local
Invoke-Command -Session $s -FilePath C:\Temp\Rubeus.ps1
In this pattern, Rubeus.ps1 contains the assembly loading logic and the MainString call. The /consoleoutfile flag is also available as an alternative: it redirects all output to a file on the remote host, which can then be retrieved via the session.
When using Rubeus through PowerShell V5 or later, standard protections apply: deep script block logging (Event ID 4104) will record the full script content including the base64-encoded assembly string, and AMSI will scan the assembly bytes before they are loaded into the runtime. In .NET Framework 4.8 environments, AMSI coverage extends to managed assembly loads, meaning the Rubeus bytes themselves are subject to scanning at load time.

Build docs developers (and LLMs) love

Get started for freeTalk to us