Insomni'Hack Teaser 2023 - Autopsy


Category: forensic, windows, realistic

Challenge description


A malicious actor has broken our Active Directory server and we suspect an active persistent access in it. Unfortunately, the attacker was able to erase the server logs. Fortunately, we have monitored all malicious actions made on our network. Do you think you can find out how he could have kept access to our server? File: autopsy.pcap

Challenge resolution

PCAP analysis and secrets extraction

By analyzing the PCAP, we can discover two types of communication:

If we take a deeper look to the WEBDAV browsed URL, we can identify that the malicious actor was very interested by the NTDS.dit, SECURITY and SYSTEM files. If the attacker was able to retrieve some files, the Wireshark “Export Objects -> HTTP” feature should allow us to extract them easily.

A simple order-by-size allows us to extract all three files: webdav file extraction

Then, it is possible to use secretsdump from impacket to extract domain secrets:

$ -ntds ntds.dit -security SECURITY -system SYSTEM local
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Target system bootKey: 0x805486c875e5e6992d3d2afeb72c6999
[*] Dumping cached domain logon information (domain/username:hash)
[*] Dumping LSA Secrets
$MACHINE.ACC: aad3b435b51404eeaad3b435b51404ee:c9c59098f8f050ad394b7369b76986f1
[*] NL$KM 
 0000   AE 82 9A 9B 3F 82 34 D5  AE 77 E9 23 FC 42 EF A8   ....?.4..w.#.B..
 0010   D2 63 69 6E E4 08 FB BE  BF CB DC 3A 4D FD 08 0E   .cin.......:M...
 0020   7B F7 C3 EF E0 00 90 AA  04 9A 87 AB 65 BB A8 06   {...........e...
 0030   F4 01 4A 85 4C FE 13 39  A5 23 B9 51 F8 35 42 07   ..J.L..9.#.Q.5B.
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Searching for pekList, be patient
[*] PEK # 0 found and decrypted: d550dd0de3e2e8c1633034fd19049cef
[*] Reading and decrypting hashes from ntds.dit 
[*] Kerberos keys from ntds.dit 
[*] Cleaning up... 

Now we have secrets from the domain, but can we use them to decrypt DCE/RPC communications?

The DCE/RPC decryption problem

One of our teammates, @cnotin, recently wrote a blog post about decrypting Kerberos/NTLM “encrypted stub data” in Wireshark (He also presented a workshop at Sharkfest 22 about it, it’s on Youtube), in which he explains how to decrypt Kerberos-encrypted communications using a keytab file, but here we have NTLMSSP-encrypted communication. He explains that it should be possible, as per the Wireshark NTLMSSP documentation:

The “NT Password” setting can contain a password used to decrypt NTLM exchanges: both the NTLM challenge/response and further protocol payloads (like DCE/RPC that may be encrypted with keys derived from the NTLM authentication. Just input the user’s password in the field. According to the source-code, only ASCII passwords are supported (due to the simple method for Unicode encoding). It doesn’t seem to support NTLM hashes so make sure to use the cleartext password.

Here comes the problem: a clear-text ASCII password is needed, but all we have is an NTLM hash. We tried to crack the hash without success, was it even possible? By taking a look at the wireshark code related to NTLMSSP decrypting, we realize that the hash is calculated by Wireshark itself before decoding the communication. A dirty solution that worked, was to recompile Wireshark by adding the following code, on line 518, and recompile it:

// Copy our hash directly in the variable
memcpy(nt_password_hash, "\x5c\x4d\xbe\x6a\x8a\x44\x44\x6f\x8d\x28\x99\xff\x08\xea\x14\xf2", NTLMSSP_KEY_LEN);

But could it be done properly? The answer is yes! When loading decryption key (aka NTLM hash), Wireshark is also looking at the Kerberos keytab file, eventually provided, using read_keytab_file_from_preferences(), and then iterates over each key to load its keyvalue. Why? Because, if the Kerberos encryption type is 23 (rc4-hmac), then the HT hash is directly equal to the RC4 encryption key, stored within the keytab. If our reading of the code is correct, it is possible to decrypt the DCE/RPC communication using a keytab: let’s give it a try!

The first step is to forge a keytab using the previously retrieved hash. On Linux, ktutil can be used:

$ ktutil
ktutil:  addent -p -k 1 -key -e rc4-hmac
Key for (hex): 5c4dbe6a8a44446f8d2899ff08ea14f2
ktutil:  wkt ins.keytab
ktutil:  q

We can check that our keytab contains the inserted key with etype 23:

$ file ins.keytab 
ins.keytab: Kerberos Keytab file,, principal=adm-drp/, type=91085, date=Wed May 19 11:41:52 2060, kvno=23

Perfect, now the keytab can be loaded in Wireshark under KRB5 options: krb5 load keytab

Finally, just filter on the dcerpc packets, and look for interesting calls, such as SchRpcRegisterTask. The previously encrypted data is now decrypted: decrypted stub

All we have to do is copy the XML of the scheduled task, and get the flag:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="">
    <Principal id="LocalSystem">
  <Actions Context="LocalSystem">
      <Arguments>/C net user Administrator INS{N1c3_j0b_Dud3_y0u_F0und_m3!}</Arguments>

The flag was INS{N1c3_j0b_Dud3_y0u_F0und_m3!}.

Author: Crypt0-M3lon @Crypt0_M3lon

Post date: 2023-01-22