Threat hunting is a powerful method of trying to detect stealthy cyber attacks. Threat hunting is an art form and over time you can become a skilled hunter. However, these days we need to do more to detect breaches in our IT environments. One method of trying to lure the attackers and reveal themselves is to use some kind of bait. This is where honeypots comes into play.

In cybersecurity, a honeypot account is a decoy or a trap designed to lure attackers and potential threats away from the organization’s actual production or sensitive accounts and systems. The primary purpose of a honeypot account is to detect and gather intelligence about attackers, their methods, and the tactics they employ when attempting to breach an organization’s security. Honeypots have the potential to discover attacks at an early stage and prevent them.

Honeypot accounts are not legitimate user accounts and do not belong to real employees or authorized personnel. Instead, they are intentionally created with the appearance of being valuable targets, tempting attackers to interact with them. These accounts typically have little to no privileges, so if an attacker gains access to them, they won’t be able to cause significant harm to the organization.

Microsoft Defender for Identity contains a honeypot feature for on-prem Active Directory called Honeytoken tags. The idea is to mark accounts as honeypots, and whenever Defender for Identity detects any kind of activity on those accounts, alerts are raised. This is an effective way of exposing the threat actor!

Nothing like this currently exists in Entra ID (Azure AD) so I got a simple yet effective idea to manually create honeypot accounts in Entra ID and use Microsoft Sentinel to generate the alerts.

Create Honeypot Accounts in Entra ID

First, we will acquire an access token to access Microsoft Graph. In this case, I will use DCToolbox for this.

# Connect to Azure AD with device code flow.
$ClientID = 'Your_Client_Id'
$ClientSecret = 'Your_Client_Secret'
$TenantID = 'Your_Tenant_Id'

$AccessToken = Invoke-DCAzureADDeviceAuthFlow -ReturnAccessTokenInsteadOfRefreshToken -ClientID $ClientID -TenantID $TenantID

In this script, replace Your_Client_Id, Your_Client_Secret, Your_Tenant_Id, and Your_Domain with the appropriate values for your Entra ID application and tenant. Note that the app registration requires delegated API permissions in Microsoft Graph: User.ReadWriteAll

Now, we will create a user account in Entra ID that will act as our honeypot account.

$graphApiVersion = "v1.0"
$baseUrl = "https://graph.microsoft.com/$graphApiVersion"
$usersEndpoint = "$baseUrl/users"

# Replace these values with the appropriate information for your user
$displayName = "Backup Admin"
$userPrincipalName = "backup.admin@example.com"
$password = "P@ssw0rd123"   # Replace with the desired password

# Create the user object
$userObject = @{
    "accountEnabled" = $true
    "displayName"    = $displayName
    "mailNickname"   = $userPrincipalName.Split('@')[0]
    "userPrincipalName" = $userPrincipalName
    "passwordProfile" = @{
        "password" = $password
        "forceChangePasswordNextSignIn" = $false
    }
}

# Convert the user object to JSON
$userJson = $userObject | ConvertTo-Json

# Send the request to create the user
Invoke-RestMethod -Uri $usersEndpoint -Method Post -Headers @{
    "Authorization" = "Bearer $AccessToken"
    "Content-Type" = "application/json"
} -Body $userJson

Adjust the $displayName, $userPrincipalName, and $password variables to match the user information you want to create.

Microsoft Sentinel Alerts

In Microsoft Sentinel, create analytics rules that will generate alerts whenever there is activity in Entra ID for the honeypot account. Some example KQL queries:

// A honeypot account signed in.
SigninLogs
| where ResultType == 0 and UserPrincipalName == “backup.admin@example.com”

// A honeypot account tried to sign in but failed.
SigninLogs
| where ResultType != 0 and UserPrincipalName == “backup.admin@example.com”

// A sensitive user account was updated.
AuditLogs
| where OperationName == “Update user” and (TargetResources[0].userPrincipalName in (“backup.admin@example.com”)
| project TimeGenerated, InitiatedBy.user.userPrincipalName, TargetResources[0].userPrincipalName, TargetResources[0].modifiedProperties

The honeypot accounts should be hidden or somehow uninteresting to normal users, but attractive and interesting for threat actors, just like a honeypot. The username Backup Admin is used in the examples since backups are something that most threat actors are interested in, especially ransomware groups. Make it irresistible!

Whenever a honeypot alert is triggered you should follow up and see where the activity were initiated from, what was done, and if there is a possibility that there is an ongoing attack, or even a breach. Easy!

To further enhance security around honeypot accounts, keep the passwords long and complex, also block sign-ins overall with Conditional Access. Since Conditional Access is applied after authentication, you will still receive all the relevant data and alerts from your honeypot accounts, but they can’t be used for signing in.

Summary

Honeypot accounts play a crucial role in cybersecurity for several reasons. Their importance lies in their ability to enhance an organization’s overall security posture and provide valuable insights into potential threats and attackers. Here are some reasons why you should implement them:

• Threat Detection and Analysis
• Early Warning System
• Understanding Attackers’ Intentions
• Security Controls Validation
• Threat Intelligence Sharing

The cloud is no exception and Entra ID (Azure AD) is the center of our zero trust architecture so it makes good sense to implement honeypot accounts to detect threats.

I hope that this post can inspire you to play around with honeypot account possibilities in Entra ID. I truly believe that this is a great way of detecting those threats early on!

Please follow me here, on LinkedIn, and on Twitter!

@DanielChronlund