devops.worker.htb
Webroot of the devops.worker.htb virtual host / sub-domain
It’s locked behind a basic HTTP authentication
Since no actionable measure can be taken at this point due to the presence of the basic HTTP authentication, I will head back to the Subversion server to further explore the possibility of reversion
Credential Reuse
During the exploration of reversion within the target Subversion server, a CLEARTEXT system credential of the nathen user has been identified. Although it has failed to validate against the target WinRM server, A speculation of credential reuse was made given the history of malpractice from the nathen user.
Initial Fail
It seems to have failed as the HTTP authentication is prompted back
All the traffic was intercepted. I will look into that.
Burp Suite
Looking further into the intercepted requests, there is a total of 3 exchanges were made
1st Exchange
The 1st exchange reveals that the aforementioned HTTP authentication is turned out to be using the NTLM authentication in the backend. It’s indicated by the fact that the WWW-Authenticate header is set to NTLM
This is called NTLM over HTTP
NTLM over HTTP (MS-NTHT)
According to the official Microsoft documentation, NTLM Over HTTP or MS-NTHT as in protocol, is a security protocol that facilitates and extends the NTLM authentication mechanism for secure user validation within the HTTP protocol. In this context, when a client attempts to access a web resource protected by NTLM authentication, the server challenges the client with an NTLM challenge. The client responds with an NTLM authentication message, and this challenge-response interaction continues until the user’s identity is successfully verified. This protocol allows NTLM authentication to be seamlessly integrated into HTTP-based applications and services, ensuring secure user authentication over web connections.
2nd Exchange
┌──(kali㉿kali)-[~/archive/htb/labs/worker]
└─$ echo 'TlRMTVNTUAABAAAAB4IIAAAAAAAgAAAAAAAAACAAAAA=' | base64 -d
NTLMSSP
┌──(kali㉿kali)-[~/archive/htb/labs/worker]
└─$ echo 'TlRMTVNTUAACAAAADAAMADgAAAAFgooCcKRHAmOLLt4AAAAAAAAAAFAAUABEAAAACgBjRQAAAA9XAE8AUgBLAEUAUgACAAwAVwBPAFIASwBFAFIAAQAMAFcATwBSAEsARQBSAAQADABXAG8AcgBrAGUAcgADAAwAVwBvAHIAawBlAHIABwAIAFxMIbMCHtoBAAAAAA==' | base64 -d
NTLMSSP
8��p�Gc�.�PPD
cEWORKER
WORKER
WORKER
Worker
Worke\L!�� The 2nd exchange appears to contain the challenge message block, encoded in the base64 format from the server
3rd Exchange
┌──(kali㉿kali)-[~/archive/htb/labs/worker]
└─$ echo 'TlRMTVNTUAADAAAAGAAYAFgAAADMAMwAcAAAAAAAAAA8AQAADAAMADwBAAAIAAgASAEAAAAAAABYAAAABYIIAAAAAAAAAAAAaKKm4Bx169HgLwf6EdffVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtcOJV/dGg+oPWJebdmwGgBAQAAAAAAAFxMIbMCHtoBj5PIwli4OMcAAAAAAgAMAFcATwBSAEsARQBSAAEADABXAE8AUgBLAEUAUgAEAAwAVwBvAHIAawBlAHIAAwAMAFcAbwByAGsAZQByAAcACABcTCGzAh7aAQYABAACAAAACgAQAAAAAAAAAAAAAAAAAAAAAAAJACwASABUAFQAUAAvAGQAZQB2AG8AcABzAC4AdwBvAHIAawBlAHIALgBoAHQAYgAAAAAAAAAAAG4AYQB0AGgAZQBuAGsAYQBsAGkA' | base64 -d
NTLMSSPX��p<
HXh���u���/���T
\8�th>���y�f�h\L!������X�8�
WORKER
WORKER
Worker
Worke\L!��
,HTTP/devops.worker.htbnathenkali In response, the client, Burp Suite’s Chromium Brower, attempts to encrypt the credential using the received challenge message block, encode it in the base64 format, and sends it back to the server. The server responses with the code 401. It fails.
This fails for a very good reason.
NTLM with Burp Suite
The Burp Suite’s Chromium Brower is specifically designed and pre-configured for Burp Suite, therefore, does not support a proper NTLM negotiation over HTTP under the default setting.
however, configuring burp suite for the ntlm authentication can be done manually.
The Platform authentication setting supports exactly that.
I will add the credential of the nathen user
Given [[#|no version information]] is specified in the header, but only NTLMSSP, the backend is likely using NET-NTLMv1, so I will put NTLMv1 for the Authentication type field
Once complete, Burp Suite will handle the NTLM negotiation in the background upon browsing to the resource
As expected, browsing to webroot of the devops.worker.htb virtual host / sub-domain did not even prompt the basic HTTP authentication since Burp Suite already handled it
Credential reuse confirmed for the nathen user
The application hosted in the devops.worker.htb virtual host / sub-domain is Azure DevOps
Continuing the enumeration in the dedicated page
Firefox
Additionally, other browsers, such as Firefox, can be used for an alternative approach as they are legitimate browsers that can handle the NTLM negotiation out of the box
Credential reuse confirmed for the nathen user
The application hosted in the devops.worker.htb virtual host / sub-domain is Azure DevOps
Continuing the enumeration in the dedicated page
Fuzzing without Auth
┌──(kali㉿kali)-[~/archive/htb/labs/worker]
└─$ ffuf -c -w /usr/share/wordlists/seclists/discovery/web-content/directory-list-2.3-medium.txt -u http://devops.worker.htb/FUZZ -ic -e .html,.txt -fc 401
________________________________________________
:: Method : GET
:: URL : http://devops.worker.htb/FUZZ
:: Wordlist : FUZZ: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
:: Extensions : .html .txt
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200-299,301,302,307,401,403,405,500
:: Filter : Response status: 401
________________________________________________
:: Progress: [661641/661641] :: Job [1/1] :: 410 req/sec :: Duration: [0:43:56] :: Errors: 0 ::No additional endpoint discovered