Don't Be Tricked Into The Click!

Don't Be Tricked Into The Click

The early to mid-2000s saw the early versions of what we know as the ‘modern’ internet. Broadband was becoming more widespread, there was increasing global acceptance that this technology was to underpin the next major revolution in society, uptake amongst wider demographics than the ‘tech-savvy’ was increasing, and connected smartphones were beginning to roll off the production lines. This period, for the many that lived through it, was the closest thing they have to understanding the world before hyperconnectivity; where communication with almost anyone, let alone strangers halfway across the world, was vastly limited.

Fast forward 20 years and it’s all very different. The average individual is using a multitude of communication platforms including Email, SMS, WhatsApp, iMessage, Telegram, Slack, Discord, Signal, and Teams to name a few. Email and some forms of mobile messaging are seen as almost a bare minimum for the developed world; in 2020, 99Firms estimated there were 5.59 billion active email accounts globally. That, in the world of phishing and cybercrime, is 5.59 billion targets. And the kicker? They’re reachable in an instant.

Phishing isn’t new. Most people know about it, and many will have been unfortunate enough to have fallen victim to it at least once. The consequences vary; some will attempt to trick you into giving up login credentials on a phoney website, and others will have you download ransomware that can imprison the data and systems of an entire organisation. Regardless, phishing is ubiquitous and frankly, annoying. So, how do we spot it?

1. Are you expecting this email? Do you have an account with the company or individual the sender is identifying as? If you do, have you requested the communication you’re receiving?
2. Are there typographical and grammatical errors? One of the most common indicators of a phishing attempt is simply bad writing. Bad spelling, spaces before punctuation marks, unprofessional formatting, informal language, and improper use of capital letters.
3. Are there mistakes in the domain names within the sender's email address and the links provided? Major red flags here are subtle character switches (e.g., ‘0’ for ‘o’) and shortened links (e.g., bit.ly).
4. Is the sender asking for personal details or credentials through a direct reply? This is also a major red flag. Never send any kind of login credentials or bank card details to anyone via email. If they are asking for personal data, e.g., home address for a delivery, ensure the sender is legitimate and you’re expecting this request per an order you’ve placed.

Despite all the things above you can look out for, there is one almost sure-fire method to avoid falling victim to a phishing attempt. Avoid clicking links as a rule. Instead navigate directly to the company’s website via your web browser / search engine. Bonus tip: the same rule applies to avoiding bogus phone calls. Provide no personal information, request the caller’s name, and then call the company directly and ask to be put through to the original caller.

Phishing attempts are becoming more sophisticated; would-be hackers and scammers are using better software to avoid grammatical errors, and utilising imagery instead of text to avoid junk filters. If you remain vigilant against every email that arrives, including from email addresses you know (they may have been breached, too!), then your risk is already significantly reduced.

Don’t be complacent, learn to spot the signs, and where possible, avoid clicking links altogether.

Author: Oliver Kersh – Managed Services Consultant at ZeroDayLab

Additional - sAMAccountName Impersonation

Since my previous post I have subsequently discovered another attack path that may be useful. For these examples I used the internal.user account in the internal.zeroday.lab domain, as shown below:

This is a generic low privileged user.

 

Trusts

I updated my original tweet, but I wanted to explain in greater depth that this works across trusts.

As mentioned in a previous post, creating machine accounts across trusts is not only possible but can be incredibly useful. This is another example of that.

A forest trust is configured between the internal.zeroday.lab and external.zeroday.lab forests:

A new machine account (named NewComputer) is created across this trust on the external.zeroday.lab domain:

The SPNs can be cleared from this newly created account:

It is best to use the distinguished name of the machine account for changing the name:

Lastly, the name can be changed to the same name as the domain controller minus the '$':

At this point the attack is exactly the same as the initial example I gave in the original post, i.e., request a TGT for EDC1, rename the machine account back, perform S4U2self.

 

User Account

Another example of exploitation involved user account control. Two more prerequisites are required to perform the attack using a user account, the GenericAll privilege over the user account and access to the account credential. Any user account can be used to perform the attack.

There are several potential ways of obtaining the user account password when you have GenericAll over it, including Targeted Kerberoasting from Will Schroeder, Shadow Credentials by Elad Shamir and resetting the user password to name a few. At this point the assumption is the password has been obtained.

The user I'm running as (internal.user) has GenericAll over the target user (new.user):

Changing the samaccountname to that of the DC minus the '$' is also possible using PowerView:

The attack from this point mirrors the original post, which can be found here. Interestingly on patched servers you can rename a user account this way with GenericAll over it, but the S4U2self part fails with a KDC_ERR_TGT_REVOKED error due to the new Requestor PAC_INFO_BUFFER being included within the TGT's PAC.

EDIT: Charlie BROMBERG suggested GenericAll is not required and this works with GenericWrite or even WriteProperty on sAMAccountName for changing the samaccountname, but it is important to remember that the ability to request a TGT for this account is required too, so the higher the privileges, the more likely you are to be able to do this.

 

Conclusion

It is very important that all domain controllers throughout the whole enterprise are patched against these issues due to the impact of exploitation and the ease with which it can be performed.

While more limited, it may still be possible in situations where a machine account cannot be created / controlled or the renaming of machine account fails.