The network in which our main source of steam is connected to, got compromised. If they managed to gain full control of this network, it would be a disaster!
Category: forensics
Solver: lmarschk, 3mb0
Flag: HTB{n0th1ng_1s_tru3_3v3ryth1ng_1s_d3crypt3d}
Writeup
We have got a package capture file.
We view this capture by looking over the tcp streams. We notice many attemps of establishing SMB connections. We notice that the suspected attacker (192.168.1.9) is starting to connect to user1 (192.168.1.7), asmith (192.168.1.10) and user2 (192.168.1.11). Although 17 of 26 tcp streams are connection attemps via SMB only 300 of 22,000 packages are transmitted that way. So we dont expect much information in them.
The streams 18 and 19 are only 100 RPC packages. Also note that exiting except we recognize something: Both SMB and RPC communications contain NTLMSSP negotiations. Let’s keep that in mind.
In tcp stream 20 we have an HTTP request. asmith is downloading a power shell script rev.ps1 and an executable n.exe from our attacker. That’s suspicious. When deobfuscating rev.ps1 we see a reverse shell that is connecting to port 4443 of the attacker.
In the next tcp stream (21) we see that connection to the attackers port 4443. The attacker is interacting with the ntdsutil. Ntdsutil.exe is a command-line tool that provides management facilities for Active Directory Domain Services We can see the ntdsutil creating a full snapshot of the ntds.dit database and registry files. After that the attacker is download the executable n.exe, is encoding the ntds.dit and the SYSTEM registry hive in base64 and pipe the data in n.exe. Because n.exe also get the parameters 192.168.1.9 8080 we expect it to send the file to that location.
In tcp stream 23 and 24 we can follow that transmission to the attackers port 8080. From that streams we can extract and base64 decode the data into the database ntds.dit and the SYSTEM hive. When researching for that database we find: The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, and group membership. It includes the password hashes for all users in the domain.
Password hashes sound great. Let’s extract them. We read about the DSInternals PowerShell Module and find a reference to the commands needed to extract the hashes.
# First, we fetch the so-called Boot Key (aka SysKey)
# that is used to encrypt sensitive data in AD:
$key = Get-BootKey -SystemHivePath 'C:\IFM\registry\SYSTEM'
# We then load the DB and decrypt password hashes of all accounts:
Get-ADDBAccount -All -DBPath 'C:\IFM\Active Directory\ntds.dit' -BootKey $key
This way we get a hand on the Accound data and the NTHashes. Let’s try to crack them: hashcat -a 0 -m 1000 tmp /usr/share/wordlists/rockyou.txt -O. (Pay close attention to the difference between hash type 1000 and 6500). With this attempt we get two passwords <3 but only old/replaced ones: b963c57010f218edc2cc3c229b5e4d0f:iloveyou ebe7973885cb068eb2e74321ea913e14:iloveyou1!
Unsuccessful hash-cracking is always a bit of a dead end, so we’ll continue elsewhere for now. Let’s take a look on the next tcp stream (25). It contains many http requests. And, again! We see a NTLMSSP negotiation.
NTLM SSP is a binary messaging protocol used by Microsoft to facilitate NTLM challenge-response authentication. NTLMSSP is used in SMB, HTTP and MSRPC services for authentication. It’s very suspicious that the attacker is always trying to use this protocol. Maybe it is vulnerable… We find two vulnerabilities a man-in-the-middle attack and the NTLM-Pass-the-Hash attack. As we can see only direct traffic we exclude the first attack.*
Pass-the-hash: We find out that the NTLM protocol is basically just responding with the challenge encrypted by the hash of the user and not the real password. Therefore we have everything we need for decrypting the encrypted communication in tcp stream 25.
As reference for cracking the encryption we used two implementations of the ntlm protocol: the ruby library used in Evil-WinRM and the Impacket library. Debugging the ruby workflow and using the python functions we calculated the keys that can RC4 decrypt the communication.
The script main.py that is depending on ntlm.py is calculating the decryption keys.
Decrypting messages from the client: client_seal_key: 433700d8abff86d333d14a7a14ef1d39
Decrypting messages to the client: server_seal_key: 56374788c4e2815cdb3aced2db74f0b6
In order to decrypt the stream we split it into the data from the client and the data to the client. Then we extract the encrypted bytes out of the http communications and decrypt it the ruby way (from-client, to-client). This way we got the decrypted XML-Content. As we already suspected by the http-route /wsman it was SOAP-XML for a remote PowerShell management. The base64-encoded communication from the client to the server got decoded with a custom xml parser and finally there was the flag!
