This post will be a part of a 4-post series that documents some of the security issues present in Malaysian organizations.

I’ve been meaning to write a post to highlight some of the common issues faced on our engagements with clients in Malaysia. This isn’t a meant to be a blame-and-shame post, but rather to help drive changes within Malaysian organizations.

Cybersecurity is a complex topic and requires a ton of planning, investment and execution to get right. However, while most of these fixes still require a level of planning & execution, they do not require acquisition of expensive enterprise security solutions and are cost-effective fixes that can help tremendously improve your organizations security posture.

Our goal in Cybersecurity is to always look at minimizing the attack surface. However, in order to reduce the attack surface, we must first try to understand the types of threats we face.

The first part of this series will cover Active Directory’s common security issues and how to fix them.

Securing Active Directory

Microsoft’s Active Directory plays a huge part in medium to large enterprise environments to help them manage users, computers and services. However, we tend to find that Malaysian organizations run on a rather loosely configured AD.

This in turn leads to alot of opportunities that attackers can leverage to move laterally and escalate privileges with minimal effort.

Active Directory misconfiguration is a far bigger issue than zero-day malware. Here’s a tweet by John Lambert back in 2015 that is still very much applicable today.

In this post, we’ll take a look at some of the attacks vectors commonly found within environments (based on my own experience) and how we can address them effectively.

I won’t be diving deep into these attacks from a technical perspective but feel free to reach out if you have any questions via these channels listed on the homepage.

Kerberoasting

Kerberoasting is a common technique used by attackers to gain credentials for lateral movement. This attack targets accounts that are assigned with a Service Principal Name (SPN).

MITRE’s definition:

Adversaries possessing a valid Kerberos ticket-granting ticket (TGT) may request one or more Kerberos ticket-granting service (TGS) service tickets for any SPN from a domain controller (DC). Portions of these tickets may be encrypted with the RC4 algorithm, meaning the Kerberos 5 TGS-REP etype 23 hash of the service account associated with the SPN is used as the private key and is thus vulnerable to offline Brute Force attacks that may expose plaintext credentials.

In summary, Kerberoasting allows any domain-joined user to request for a TGS ticket that is encrypted with the SPN account’s hash. With this ticket, an attacker can then bruteforce the ticket to retrieve the target account’s plaintext credentials.

If the target account in question also happens to be an Enterprise Admin with a weak password, an attacker will be able to compromise your entire domain in one move.

Using a tool like PowerView, it’s incredibly easy to retrieve these tickets.

PS C:\> Invoke-Kerberoast -Identity wkstn-admin

SamAccountName       : wkstn-admin
DistinguishedName    : CN=wkstn-admin,CN=Users,DC=******,DC=domain
ServicePrincipalName : MSSQLSvc/SVR03.******.domain:49831
TicketByteHexStream  :
Hash                 : $krb5tgs$23$*wkstn-admin$******.domain$MSSQLSvc/SVR03.******.domain:49831*$6C16135FE7070D9B8D0624BB5D29A9B3$47753B4640079FCF6B8DC3D2AC4137D6693BDFC0
                       DA0DC0D6D80F03AFCEEC98835DB48A2F015DEA4D89F73903ABAAA7241E0DA3D483B6019B8DA73AC7F0BD494E3D20BBD1EBA6C7545A43B6B547F71EB0F4C56EF7CD99B1AEAF72B6080738DD3CA443B92FBF82
                       [snip...]

Unfortunately, there is no real fix for Kerberoasting as it is just how the Kerberos authentication mechanism works.

However, MITRE suggests the following for mitigation:

1. Enable AES Kerberos encryption over RC4

The main reason for this is that bruteforcing RC4 is signicantly quicker than AES. Here are some benchmarks from Hashcat:

kH/s - Kilohashes per second (Thousands of hashes per second)
MH/s - Megahashes per second (Millions of hashes per second)

RC4

Hashmode: 13100 - Kerberos 5, etype 23, TGS-REP

Speed.#1.........:   337.1 MH/s (52.68ms) @ Accel:32 Loops:256 Thr:64 Vec:1
Speed.#2.........: 91019.8 kH/s (68.88ms) @ Accel:256 Loops:64 Thr:64 Vec:1
Speed.#*.........:   428.1 MH/s

AES

Hashmode: 19600 - Kerberos 5, etype 17, TGS-REP (Iterations: 4095)

Speed.#1.........:   927.6 kH/s (74.32ms) @ Accel:16 Loops:512 Thr:1024 Vec:1
Speed.#2.........:   257.7 kH/s (94.48ms) @ Accel:16 Loops:1024 Thr:1024 Vec:1
Speed.#*.........:  1185.4 kH/s

However, while this looks helpful at first sight, an attacker can still specifically request for RC4 tickets. The only way to prevent this is to completely disable RC4 in the environment, which could potentially break alot things that still rely on RC4.

Check out this post on ired.team for more information

2. Ensure strong password length (25+ characters) and complexity, with password expiry.

Having a strong, lengthy and randomly generated password definitely helps as they make password cracking infeasible for attackers. Attackers also have limited resources and making them commit additional resource at every step of the way will severely hamper them.

Avoid using passphrases (even with leetspeak-like formats) as popular password cracking tools like Hashcat and John the Ripper support rules which enables them to combine and mutate dictionaries used for bruteforcing. Stick to truly randomly generated passwords and use a password management solutions as these are service accounts after all.

3. Limit SPN accounts to minimal privileges

While setting strong passwords are a good start, an attacker can always get lucky and having an additional limiting layer is never bad.

In the example earlier, I was able to compromise the entire domain once I cracked the wkstn-admin account in 2 seconds. The unfortunate thing here is that no one knew why that account had an SPN associated with it to begin with as it was only used for domain administrative tasks.

If you do have SPN accounts, be sure to review them regularly and ensure rigidness when configuring the privileges required by the service account.Principal of Least Privilege is especially important in Windows and AD environments due to how NTLM & Kerberos authentication works. This leads to my next point on securing your AD.

Exposure of Privileged Accounts

Throughout engagements, it was not uncommon to find a large number of Domain/Enterprise admins within an environment. On one engagement, I actually found a nested OU named Desktop Administrators in the DA group with about 20 odd members.

Having day-to-day Desktop/Helpdesk Administrators inheriting Domain or Enterprise Administrative privileges is not something we should take lightly from a security perspective.

I personally believe this is the one area a majority of our local organizations are weak in and is something that should be addressed sooner, rather than later.

One of the key reasons we should limit the exposure of privileged accounts is due to credential dumping.

Credential Dumping

MITRE’s Definition

Credential dumping is the process of obtaining account login and password information, normally in the form of a hash or a clear text password, from the operating system and software. Credentials can then be used to perform Lateral Movement and access restricted information.

This part is pretty self-explanatory and I won’t go into too much detail. The most popular tool used for Credential Dumping is Mimikatz and while it’s out-of-the-box release is detected by anti-viruses, it mainly serves as a deterrent to script kiddies. AV evasion is a trivial matter to experienced hackers and we should not be relying on our endpoint protection solutions as our only line of defence.

In modern Windows OS, it is rare to be able to retrieve plaintext passwords these days through Credential Dumping. However, an attacker can still obtain a user’s hash and use it for lateral movement, without even cracking it.

Besides hashes, an attacker is also able to steal Kerberos (TGT) tickets of a user to request for valid TGS tickets to a particular resource.

With the user’s hash, an attacker can perform the following techniques for lateral movement:

  1. Pass the Hash

    Pass the hash (PtH) is a method of authenticating as a user without having access to the user’s cleartext password. This method bypasses standard authentication steps that require a cleartext password, moving directly into the portion of the authentication that uses the password hash.

  2. Pass the ticket

    Pass the ticket (PtT) is a method of authenticating to a system using Kerberos tickets without having access to an account’s password. Kerberos authentication can be used as the first step to lateral movement to a remote system.

Now let’s start considering the implications of having our Helpdesk or Desktop administrators inherit Domain/Enterprise Admin privileges. Picture this, a Helpdesk admin is responding to a ticket and he’s required to tend to a workstation. As soon as he enters his credentials to log on that workstation, it’s going to get cached in the operating system.

This means that, if the workstation was already compromised, the attacker now has the capability to perform a Credential Dump to retrieve his hash/ticket and perform the techniques mentioned above.

From an operational security perspective, this is far from ideal and we are dramatically increasing the exposure of our privileged accounts. Especially so when Helpdesk administrators often log in to many different computers on a day-to-day basis.

Please note that these examples are from my own personal experience in engagements. I realize not all companies are set up like this but it’s still important to review your Domain and Enterprise Admins on a regular basis.

Let’s take a look at some of mitigations listed by MITRE:

1. Credential Access Protection

Windows 10 comes with Windows Defender Credential Guard which helps protect credentials. This is not configured by default and has hardware requirements due to the fact that it utilizes Hyper-V virtualization to isolate the LSASS process from credential dumping attacks.

This is generally a must-have on privileged workstations and mitigates a significant number of attacks that mimikatz can perform.

2. Password Policies

Ensure that local administrator accounts have complex, unique passwords across all systems on the network. A good way to enforce this is to adopt a solution like the Microsoft Local Administrator Password Solution, which is completely free. LAPS manages and rotates passwords for local Administrator accounts within your Active Directory. There is minimal overhead for implementation and it is well documented on MSDN.

With LAPS, eligible users can read or request these randomly generated passwords when needed, and not worry about password expiration or reset as that is all handled by LAPS.

3. Privileged Account Management

Ultimately, one of the strongest measures we can take is going to be privileged account management again. A significant majority of the time, Helpdesk/Desktop admins do not require Domain or Enterprise privileges to perform their day-to-day operations.

Hence, by limiting the privileges of your Helpdesk/Desktop adminitrative privileges, you reduce the attack surface significantly and will be able to limit the impact of a compromise.

4. Disabling or Restricting NTLM authentication

While this might sound like a good idea, be sure to audit your environment to see if any services in your environment still require NTLM authentication. In newer environments, this should generally be fine.

However, take note that it does not completely solve the problem. Windows is moving away from NTLM in favor of Kerberos, but Kerberos is still susceptible to credential attacks like Overpass-the-Hash.

In an OptH attack, a user’s NTLM hash can be used to request a Kerberos Ticket Granting Ticket (TGT).

Key Takeaways

As we all know, there is rarely any one size fit all solution to security issues. Ensuring that multiple layers of mitigation is applied is a good strategy in reducing our attack surface.

My personal advice to organizations looking to harden their AD environment is to start with the following:

  • Review all privileged accounts and limit where possible

    The lack of proper Privileged Account Management is a far bigger issue than preventing zero-days. The general rule of thumb is to have no more than 5 Domain and Enterprise Admins per Domain or Forest respectively.

  • Consider using a privileged workstation for any Domain-level administrative activity to limit the footprints of privileged accounts

    These workstations should also be monitored and hardened with policies like strict host-based firewall rules, PowerShell logging, and AppLocker.

  • Identify accounts with an associated SPN to prevent Kerberoasting

    Review if these accounts still require an SPN and ensure they have the appropriate privileges. Consider resetting their password to something secure. General rule of thumb is to keep it 25 characters or more.

In the next part of this series, I’ll be covering offensive PowerShell and why I believe it’s far from dead in Malaysian organizations.