Published: 10 June 2021    Last Updated: 09 November 2022

Password rotation has previously been included within best practice guides as a method of minimising the risk of compromised passwords being valid at the time a threat actor attempts to use them. Recent research has indicated that the enforcing password rotation is linked to increased risk of weak passwords, due to users selecting passwords based on patterns - such as Password1, Password2, Password3, or patterns such as Summer2021, Autumn2021, Winter2021.

Published: 07 June 2021    Last Updated: 04 November 2022

Weak passwords are those which are predictable and can be easily guessed. To ensure that users do not select weak passwords organisations may look to enforce password complexity. Complexity refers to the requirement to use a mixed character set. For example, on Active Directory accounts complexity requires three of the four: uppercase, lowercase, numbers, and symbols. However it is still possible to select weak passwords with complexity enabled, such as Welcome!, Summer2020, or Password123456.

Published: 23 January 2021    Last Updated: 04 November 2022

When performing security tests, we very often come across weak passwords. We often see dictionary words with suffixes such as Welcome1, Password123, or Lockdown2020. We also see "leet" substitutions, such as P@55w0rd, 3l3ph@nt, or L0ckd0wn. We've previously shown how quickly password cracking can be performed. With passwords like the above they would be cracked easily. Simple protections such as "Password complexity" don't solve the problem on their own, for example complexity enforces the requirement for three of the following: uppercase, lowercase, numbers, and symbols - which all of the weak options above meet.

Published: 23 January 2021    Last Updated: 04 November 2022

In a previous article we discussed how bruteforcing Windows accounts is often easier than people expect. In this post - we'll cover some steps to harden these accounts.

The Observation Window

When configuring an account lockout threshold on a Domain another setting is suggested, the observation window. This setting effectively reduces the protection of the account lockout by setting a timer. For example, a lockout threshold of 5 and an observation window of 30 minutes has the impact of meaning that if an attacker attempts 5 incorrect passwords within 30 minutes the account will lock - but four passwords would not cause it to lock.

Therefore, an attacker could attempt 4 passwords every 30 minutes - or 192 per account per day, without locking any accounts.

Published: 19 October 2020    Last Updated: 03 November 2022

We covered extracting domain hashes with Mimikatz previously, but that's not always the best approach - for example where anti-virus is getting in the way. However there are other options for the same goal. This time around we'll take a look at using Vssadmin, a built-in Windows tool. VSSAdmin is the Volume Shadow Copy Administrative command-line tool and it can be used to take a copy of the NTDS.dit file - the file that contains the active directory domain hashes.

Published: 19 October 2020    Last Updated: 03 November 2022

A common configuration on Windows Active Directory accounts is to have an account lockout threshold of say, 5 invalid attempts, and an observation window of 30 minutes. This is likely due to the fact that the “Suggested Setting” after setting a threshold is to enable a short observation window.

When setting an account lockout threshold, Windows “suggests” that you set the observation window at the same time, to 30 minutes. The observation window is often overlooked as a security risk; however it allows an attacker to perform a bruteforce attack without locking an account.

Published: 19 October 2020    Last Updated: 03 November 2022

It is possible to brute-force Windows accounts directly, using tools like Metasploit using modules such as smb_login, which will target port 445 (SMB). However, it’s also possible to brute-force the Active Director authentication protocol Kerberos directly.

This can be beneficial to an attack for two reasons, the first is that it will be logged differently and depending on how the blue team are monitoring for attacks it might fly under the radar. A standard login attempt that fails will result in event 4625, whereas a failed Kerberos login attempt will likely result in event 4771.

Published: 19 October 2020    Last Updated: 03 November 2022

Any domain user within Active Directory can request a service ticket (TGS) for any service that has an SPN (Service Principal Name). A part of the service ticket will be encrypted with the NTLM hash of the target user, allowing for an offline bruteforce attack.

This is true for user accounts and computer accounts, but computer account passwords are randomised by default and rotated frequently (every 30 days). However service user accounts may have weak passwords set which could be cracked. This attack is commonly called Kerberoasting. Although, don’t confuse this attack with the similarly named ASREP Roasting. A common setup where you might find this vulnerability is where a service account has been set up for Microsoft SQL Server.

Published: 19 October 2020    Last Updated: 03 November 2022

If an Active Directory user has pre-authentication disabled, a vulnerability is exposed which can allow an attacker to perform an offline bruteforce attack against that user’s password.

This attack is commonly known as “AS-REP Roasting” in reference to Authentication Service Requests, a part of the process of authentication with Kerberos. An attacker who is able to find a user with pre-authentication disabled can request an AS-REP ticket for that user and this will contain data encrypted with the user’s password.

Published: 19 October 2020    Last Updated: 03 November 2022

We recently published an article on using Incognito for privilege escalation as part of a short series on using Metasploit. In this article we’ll cover an alternative approach for privilege escalation – extracting plaintext credentials. Whilst incognito is generally easier to use, Mimikatz is powerful and flexible.

In this part we’re just going to look at password extraction; but Mimikatz can be used for many other attacks – such as extracting domain hashes from a domain controller. As before, password extraction is really a post-exploitation steps and is very useful for escalating from local administrator access to domain administrator access. As this is a post-exploitation step, we’ll be starting with a SYSTEM shell through PsExec for this demonstration. As an example of when these steps could be deployed, they could be a step taken after successfully performing an attack to gain an initial foothold such as LLMNR and NBT-NS Spoofing, which we covered previously.