Deception 101 — Part 2: Honeytoken account in Active Directory
Increasing the chance of catching criminal hackers is essential in both furthering the reduction of cybercrime and for identifying hackers in your network. In this series of articles, Chapter8 gives you various tips to set digital tripwires in your network. We’re going to trap hackers using deception. Are you in?
Introduction
Active Directory. Almost every organization that works with Microsoft products uses Active Directory to manage the rights of users, groups, computers… in fact, almost the entire digital organization. Partly for this reason, Active Directory is an absolute crown jewel in any organization that uses it. The highest rights within Active Directory are granted to the Domain Administrators group, but within Active Directory, administrative and user rights can be delegated and granted in many, many ways. Active Directory can become a confusing monster. A fact that attackers happily use. And we’ll use that fact against them.
Our model organization
For the examples in this series of articles we use a small, fictitious organization: Chapter7. Chapter7 specializes in innovative solutions for the healthcare sector and is a typical SME company — but with a system administrator who is very interested in logging and monitoring. That is why Chapter7 does have pay as you go Sentinel Tier, which costs them less than 50 euros per month due to the small infrastructure.
Caveat: The examples in this series of blogs were developed in a very small Active Directory, which may make the attack scenarios seem exaggerated. We realize that! The ideas behind the examples can however — because we keep it small and simple — easily be extrapolated to much larger environments.
The attack scenario
Tripwires in the network are intended to alert you to an attacker who already has some level of access to your digital infrastructure. Chapter8 works under the assume breach principle: assume that an attacker will gain access to your network at some point. Either via an access broker, or via a new zero-day, or via configuration errors — the possibilities are unfortunately endless. The attack scenarios in this series are also written with this principle in mind.
An attacker with some access to Chapter7’s infrastructure will want to map the Active Directory and look for accounts that are easy to exploit. For example, to further explore the network, establish backup access or hide himself. Why? Because every access counts and over time even “temporary” accounts may have been given many rights to access data. Now there are at least three conditions to be met before an attacker can query Active Directory:
- The attacker has a valid Active Directory account; or
- The attacker has access to domain-joined computer (that one demo PC in the lobby for example…); or
- LDAP is available and requires no further authentication.
Setting up the honeytoken
In the overview above you see part of Chapter7’s (tiny) Active Directory, which consists of five users and two administrator accounts, a domain controller and a few workstations. This is of course for demo purposes: at Chapter8 we have seen Active Directories of over 50,000 entities.
It is also a Best Practice not to make Administrator accounts so easily recognizable. Yes, a smart attacker can distinguish them anyway based on the SID structure and there is Red Team software available to map it all out. But as an acquaintance of mine once said: “Small cattle also makes manure” every little bit helps.
The crux of a honeytoken is that it blends in with the crowd and looks like a regular part of the infrastructure. Now this is a little easier with 50,000 accounts than with 7 accounts, but please follow us on this train of thought. What is striking is that the Description field in this Active Directory is empty. We are going to change that, because that is exactly where we are going to place our honeytoken. So step 1 is to start using the Description field:
It is credible that a small company like Chapter7 uses graduate students or interns. And it is also common for them to get their own account for the duration they work at Chapter7. In the Active Directory we create a user that resembles the standard account for a temporary employee. With the password in the Description field, because that is easy to manage for Alice and Steward and easy to remember for the temporary employees!
First we create a new user and enter a number of values:
Then we give this account a STRONG, RANDOM password. 0qaNJpEn000wzvYW5eC is a great candidate. We ensure that this password does not expire and that the user cannot change the password. Note: this is completely in line with the bait: a default password for every intern.
Finally, we fill the Description field with our honeytoken. pw = Temp2023! seems super valid - to be honest, most passwords we find look something like this, but more about that in another blog - and can be requested by anyone who knows where to look.
The user overview in Active Directory now looks like this:
The result: we created an account with a strong password, which never expires, and with misleading information in the Description field.
Time for a test: log in to one of the monitored workstations as user tmpand for completeness as CHPTR7\tmp.
This looks good! Now on to logging, monitoring and alerting!
Setting up logging, monitoring and alerting
Within Microsoft Sentinel, it is trivial to look up logs of the failed login attempt. The EventID of a failed logon is 4625 - and we know that the attempt always fails because the real password of the tmp account is not the same as what is in the Description field. This EventID is a SecurityEvent and will always contain the string \\tmp. The manual query is therefore as follows:
Note: Sentinel returns UTC as the time zone by default. Please take this into account when interpreting the message!
Look at that. We have a report of failed login attempts! That’s right, because this was the manual test. It is possible to save this query and execute it manually, but it is more than desirable to run this query every so often and set an alarm to it. This can be done in Sentinel Analytics.
Creating a new analysis rule is done as follows: click + Create at the top of the overview and choose Scheduled query rule.
Enter the generic properties of the rule. For some extra juice you can add a MITRE ATT&CK category.
In the next screen we can add some more details to the possible alarm. For example, it is useful to immediately display the IP address from which the login attempt was made.
You want to quickly recognize such an attempt. For this example we set the scheduling to once per hour.
The only action you need to take as soon as possible on this alarm is if you want to receive a notification. This is possible in Automated Response. In the introductory article from this series we created a Logic App based on our Playbook, which sends an email when a Sentinel incident is created. We now activate it:
In the end the whole thing looks like this:
Testing the design
We have now set up a complete honeytoken, including logging, monitoring and alerting:
- account created in Active Directory,
- repeating query rule in sentinel,
- linked to the alerting app.
Now we’ll force an alert: log in to the workstation again with the tmpaccount. If everything works, you will automatically receive an email with the incident information.
Please note: the time at which you receive the email depends on the time period you have in your account query rule you have set. If you don’t want to wait, adjust the query scheduling or adjust the query itself. That forces a run.
Triage
The entire setup works. What if an actual notification arrives?
First of all, don’t panic. You should have read in the first part of this series that preparation is half the battle. Let’s say you have taken care of the first few steps: the email arrives at a central point and your department has the mandate to collect data surrounding the incident.
We use appendix 9.3 of the ABDO as a reference.
Step 1: identification
This step consists of four smaller steps: collect the logs, report, assemble a research team and determine impact.
From the initial email we have a direct link to the incident in Sentinel. Here we can analyze the audit logs, which we find under Evidence.
If we click through, we arrive at the three log lines that triggered the incident.
This is how the log lines were collected. Reporting to BIV/MIVD is not applicable, so we can skip that step from ABDO.
When putting together the research team, we adhere to at least the four-eyes principle. So make sure you have a buddy with whom you can go through the possible incident together and divide the tasks: who will ensure the completeness of the incident report? Who initially conducts the technical research?
Step 2: incident recording
A central register of cybersecurity incidents is essential, as is a standard way of recording incidents. We do not yet know whether this is a false positive or a true positive and the more incidents we record, the more reliable our detection can ultimately become through analysis of these incidents. The ABDO has a nice template for the notification in appendix 9.2, which we can make a little more workable for non-defense order companies (sorry, Dutch example!) :
Step 3: first response
Now that the initial administration has been completed, we can look at the logs behind the incident itself to determine whether we are dealing with a real incident or a false positive. The captured event ID has a number of characteristics that give some more context to the message. First of all, however, we determine the research questions. Consider the 5W+H model: who, what, where, why, when and how.
When was the log created? TimeGenerated gives you this value. Please note: UTC by default, so correct for your own time zone.
On which (virtual) machine was an attempt to log in? Computer gives you this value. This is the potential stepping stone that the attacker has tried to use.
How did the attempt originate? Two fields are interesting here: LogonType and LogonProcessName.
The value 3 as LogonType is self-explanatory: the attempt occurred over the network. The LogonProcessName is more cryptic, but judging by the overview below from this presentation of CyberSafe, the value NtlmSsp represents an indication for use of the NTMLv2 protocol. This doesn't say much about the actual method - it could indicate a manual attempt or a tool - but at least it's not one of the other methods.
Where did the attempt come from? You will find this in the IpAdress value:
As brief as this may seem, it is enough for this phase. Due to the design of the honeytoken it is possible that this is a true positive, but we cannot be sure yet — this is an incident, where the who, what, where, how and why still need to be investigated further. The most important “hook” for further investigation in this incident is of course the IP address 10.6.0.5 from which the attempted login was made.
Now that the first response has been done, it is time for a quick pause. What expertise is needed to further investigate this incident? Can we secure the necessary information relating to that IP address? Does the team need to be expanded? Probably not, based on this report, but it is good to ask yourself these questions. On to the next step.
Step 4: communication
In this phase of incident handling, the question is whether and what needs to be communicated to any stakeholders at this time. Our assessment: no, further research is required first. It is useful to inform the SOC lead and certainly the CISO, because the research requires resources. We may need other (external) system administrators.
Step 5, 6, 7: containment, response strategy, classification
We can also be brief about these steps — in this case. There is no question of containment yet. The appropriate response does not (yet) have any difficult legal or political components and the classification can be made according to Appendix 9.4 of the ABDO: Cat 5: attempt(s) to gain access.
Step 8.9: incident investigation, data collection, forensic analysis
Finally! On with the research! We cannot attribute anything yet, so we will collect data related to the IP address. Because this is a blog series about deception and not about incident handling, here are a few pointers to the following investigation options surrounding IP address 10.6.0.5:
- Is it a VDI, a BYOD or a regular workplace?
- What is (or was) the physical location of the computer?
- What is the function of the computer?
- Who was logged in at the time of the alarm?
- Are there more (erroneous) login attempts from that computer?
- Have there been any previous alerts surrounding this computer? Think of network connections, proxy logs, DNS, login attempts at strange times?
- If an EDR is running as Defender, what suspicious events does it have?
- Can you have a forensic package made by, for example, Microsoft Defender for Endpoint?
Put on your detective suit and go investigate!
Closing remarks
In this edition of Deception 101 we have set up a fairly simple but effective honeytoken, set up the logging and monitoring and wrote down some questions for handling a report. We hope that this blog has given you inspiration to get started with this yourself. Do you need help or would you like other offensive or defensive advice? You will find us at https://chapter8.com and behind questions@chapter8.com!
In the next edition of Deception 101, we’re going to leave a few breadcrumbs so our poor attackers can find their way back home.
