From Prey to Predator: Crafting Intelligent AD & Entra Decoys with PowerShell and BloodHound

In the world of identity security, we spend most of our time in a defensive crouch. We patch, we harden, we configure. We wait for the attacker to make a move. But what if we could turn the tables? What if we could shape the battlefield, poison the well of information, and use an attacker’s own reconnaissance tools against them?

This is the promise of a proactive, intelligence-driven deception strategy. By understanding our environment through the eyes of an adversary, we can lay intelligent traps—decoys so convincing they become irresistible targets. Today, we introduce FakeHound, a methodology and set of powerful, interactive PowerShell scripts designed to operationalize this strategy in both Active Directory and Microsoft Entra ID.

The BloodHound Paradigm: See What the Attacker Sees

The foundation of any effective deception is intelligence. BloodHound, the open-source attack path mapping tool from SpecterOps, provides this intelligence in spades. It doesn’t just show you a list of users and groups; it reveals the intricate web of relationships—permissions (ACLs), Group Policy links (GPOs), session data, and control paths—that define your identity landscape.

This is the “attacker’s-eye view.” An adversary using BloodHound isn’t looking for a single vulnerability; they’re looking for a path of least resistance to a high-value target, like Domain Admin credentials. Our goal is to manipulate the map they see, poisoning it with deceptive lures that lead them into our traps.

Beyond Static Decoys: Why Relationships Are King

A common first step in deception is to create a fake user account, perhaps named admin_backup. This is a Decoy Account (D3-DA) in the MITRE D3FEND framework, and it’s a good start. But a sophisticated attacker using BloodHound will see this account for what it is: an isolated node with no history, no permissions, and no context. It’s suspicious and easily ignored.

True believability comes from relationships. A decoy is far more compelling if it appears integrated into the environment’s graph. Consider these two scenarios:

  1. Weak Decoy: A user named sql_admin_decoy. In BloodHound, it’s a lonely dot.
  2. Strong Decoy: A user named sql_admin_decoy that BloodHound shows is a member of the (decoy) group SQL DBAs Tier0 and has AdminTo rights on a (decoy) computer named MSSQL-PROD-01.

The second scenario tells a story. It presents a plausible, exploitable path. The attacker isn’t just seeing a fake user; they’re seeing a potential stepping-stone to compromising a production SQL server. This is the level of sophistication we need to aim for, creating not just decoy objects, but decoy attack paths.

Automating Intelligence: The Interactive Decoy Scripts

To facilitate this advanced approach, we’ve developed two interactive PowerShell scripts as part of the FakeHound toolkit: one for Active Directory and one for Entra ID. They operate on a simple but powerful philosophy: Analyze -> Suggest -> Approve -> Create.

Instead of blindly creating generic objects, these scripts analyze your own BloodHound data to make specific, context-aware suggestions. They identify patterns in your environment—the naming conventions of your service accounts, the OUs where your admins reside, the groups they belong to—and propose decoys that mimic them, making the fakes nearly indistinguishable from the real thing.

Deep Dive: The Active Directory Script (Create-ADDecoys_Interactive.ps1)

This script uses the output from the SharpHound collector to find the perfect places to lay traps in your on-premises AD.

How It Works: From Analysis to Suggestion

The script ingests your users.json, groups.json, and computers.json files to understand what’s “normal” in your domain. It then generates suggestions based on common attacker tradecraft:

  • Stale Admin User Lure: Attackers love finding old, privileged accounts that seem forgotten. The script looks for real, enabled admin accounts with passwords that haven’t been changed in over a year and suggests creating a decoy that mimics this profile. This is a perfect trap for an attacker looking for an “easy win.”
  • Kerberoastable Lure: This directly targets a common TTP, Kerberoasting (T1558.003). The script finds real service accounts and suggests creating a fake one with an enticing Service Principal Name (SPN), like svc-mssql-prod-02. Any attempt to request a Kerberos ticket for this SPN is an immediate, high-fidelity alert.
  • High-Traffic Computer Lure: Where do attackers go to find credentials? Systems with lots of user sessions. The script identifies real computers that are frequently logged into and suggests creating a decoy computer that mimics them (e.g., APPSRV01-DR). This decoy becomes a prime location to plant further lures, like fake credential files.
  • Privileged Group Lure: Attackers perform Permission Groups Discovery (T1069) to find powerful groups. The script identifies your real admin groups and suggests creating a decoy with a tempting name like CORP_ADMINS_TIER0_BACKUP. Any attempt to enumerate the membership of this group is a red flag.

The Interactive Workflow

After its analysis, the script presents you with a numbered list of these suggestions. It will not create anything yet. You then run the script again with the -Execute switch. It presents the same list and prompts you to enter the IDs of the decoys you want to create. You can pick and choose (1,3), create all of them (all), or simply press Enter to cancel. This interactive approval step ensures you are always in full control.

Deep Dive: The Entra ID Script (Create-EntraDecoys_Interactive.ps1)

The battle for identity has moved to the cloud. This script applies the same intelligent, interactive logic to your Microsoft Entra ID tenant using data from AzureHound.

Cloud-Native Deception Opportunities

The script focuses on attack vectors unique to Entra ID:

  • Dormant Global Admin Lure: Just like in on-premises AD, dormant accounts are gold for attackers. The script finds real Global Admins who haven’t logged in for months and suggests creating a decoy that mimics them. Any sign-in attempt against this account is an alert for Valid Accounts: Cloud Accounts (T1078.004).
  • Privileged Service Principal Lure: Compromising application identities is a primary goal for cloud attackers. The script finds real Service Principals with numerous roles and suggests a fake one that appears similarly powerful (e.g., GraphDataSync-PROD). To make this lure even more effective, you can “leak” fake credentials for this SP in a developer’s repository or configuration file, targeting the Additional Cloud Credentials (T1098.001) technique.
  • Privileged Group Lure: The script identifies real administrative groups in Entra ID and suggests creating decoys with similarly enticing names, such as Azure_Subscription_Owners_DR.

The workflow is identical to the AD script: Analyze, Suggest, and create only what you Approve.

Building the Web: Creating Decoy Relationships

Creating the decoy objects is the first step. The real magic happens when you connect them. After the scripts create your approved users, groups, and computers, you need to build the relationships between them so they appear as a legitimate attack path in the next BloodHound run.

Imagine you approved creating a decoy user (decoy_admin_1), a decoy group (Decoy_Tier0_Admins), and a decoy computer (DECOY-SRV-01). The next steps are:

  1. Add Membership: Use Add-ADGroupMember -Identity 'Decoy_Tier0_Admins' -Members 'decoy_admin_1'.
  2. Grant Admin Rights: Make the decoy group a local administrator on the decoy computer. You can do this via Group Policy by linking a new GPO to an OU containing your decoy computer.
  3. Create Session Data: To make it look like decoy_admin_1 has been active, you can plant lures. While you can’t easily fake the HasSession edge in BloodHound directly, you can create lures that imply it, such as creating a folder named C:\Users\decoy_admin_1 on the decoy server.

After taking these steps and re-running SharpHound, your next BloodHound graph will show a compelling path: decoy_admin_1 -> MemberOf -> Decoy_Tier0_Admins -> AdminTo -> DECOY-SRV-01. This is the kind of breadcrumb trail that leads an attacker exactly where you want them.

The Final, Critical Step: Operationalizing with Monitoring

Creating these decoys sets the stage. The final act is monitoring. A decoy that isn’t monitored is just digital noise.

Your primary goal now is Detection (TA0007). Every object these scripts create is tagged with [DECOY_ASSET] in its description field. This is your hook for monitoring.

  1. Configure Your SIEM: In your SIEM (Microsoft Sentinel, Splunk, etc.), create high-priority alert rules that trigger on ANY event log or audit log where the target object’s description contains [DECOY_ASSET].
  2. Set Tripwires:
    • For AD, monitor Event IDs 4624/4625 (logon attempts), 4769 (Kerberoasting), and 4728 (group membership changes).
    • For Entra ID, monitor Sign-in logs and Audit logs for any interaction with the decoy users, groups, or service principals.
  3. Engage the Attacker: When an alert fires, you have achieved the goal of the MITRE Engage framework: to Elicit Adversary TTPs (GO0006). You have forced the attacker to reveal their presence and their methods on your terms, in a controlled part of your environment.

By combining the deep environmental analysis of BloodHound with the automated, intelligent creation power of these PowerShell scripts, you can fundamentally shift your security posture. You move from being the hunted to the hunter, shaping the battlefield and turning an attacker’s greatest strength—their ability to find a path—into their greatest weakness.

Leave a Reply