2

TL;DR

I'm trying to implement a fake user account that has multiple sets of credentials that can be used. Instead of a specific password, any one password from a list of them could be used to authenticate to the account. By doing so, we can cover breached, common, or easily guessed passwords, and make it more likely that an attacker is detected through these fake user account "tripwires." This would be useful for detecting password sprays in the domain.

FYI

I'm not super experienced with Windows AD and how identities are defined with various Windows authentication methods. I'm also not intimately familiar with system administration, Azure, IAM, or devops.

Background

I set up a Windows AD domain from within Azure using the ARM template from DefensiveOrigins/DO-LAB. The goal was to do some "purple teaming" by setting up a fake tripwire user account with an easy password, do a fake password spray over the domain, then implement detections using KQL in Microsoft Sentinel.

The original lab comes from here (not public though) - AppliedPurpleTeaming/APT-9S22: APT-9S22

In practice, this lab must be able to use the "DomainPasswordSpray" tool (dafthack/DomainPasswordSpray) along with recon such as with BloodHound (BloodHoundAD/BloodHound).

Why a Fake User Account with Multiple Creds?

I wanted to add a twist to the fake user accounts. What if the attacker were to hit a legitimate account that has an easy password like "easypassword1" before it hits my fake account that's using "easypassword2." This would mean that my fake user account never gets tripped. To avoid this I thought I could try to programmatically allow for multiple passwords to get into an account without needing to create more accounts as this would make the deception more noticeable. If possible, I can plug in a list of common passwords and almost always get a hit on that account and cover a large distribution of passwords used with attacks. As a result, that one account would effectively cover password spray detections for the whole domain with little effort.

The step with Fake User Generation can be found at - APT-9S22/APT/1-Labs/L0040-Deception - AppliedPurpleTeaming/APT-9S22

ChatGPT tried to say that Credential Manager could do this, but I'm calling a hallucination on that.

Other Mentions

Lots of people saying it's not possible or not looking at it from other perspectives.

Approaches & Related Problems

These are all approaches that could maybe work for implementing this multi-credential fake user account (even if only logical and not literal).

Multiple entities on one account

There are lots of cases where you may have multiple entities or people accessing one privileged account.

There's a Microsoft article related to this for Entra ID (Sharing accounts and credentials | Microsoft Learn).

I can think of 2 ways this can be done:

  1. Multiple sets of credentials that can be activated or deactivated for that one account
  2. You could manage those credentials in some system like a password manager and disallow access when necessary, which would also then require the password to be reset

I'm unaware of nuanced ways accounts can be used in Windows AD. Maybe there's a type of logical account in Windows AD that can be a sort of account proxy to the main account.

External/Third-Party Identity Provider (Proxy for Authentication)

Maybe there's a way to implement some sort of external identity provider that could use conditional logic with forms of identification (what you know, what you are, what you have.) For example, a password could be attempted in Windows AD, then that password is sent to the 3rd party, then the identity provider would check through its list of password (PW1 OR PW2...) and return true. Is this a thing? Is it possible?

Notes for my project

grad-school-projects/Honey Accounts in Windows AD at main · cybersader/grad-school-projects

6
  • What if the attacker were to hit a legitimate account that has an easy password like "easypassword1" before it hits my fake account that's using "easypassword2." that's an easy problem to prevent though. Filtering out insecure passwords at time of change and searching an AD database for bad/easy passwords, both easy and minimal effort. To the extent it isn't explainable on a modern day audit if those problems exist.
    – Greg Askew
    Commented Nov 27, 2023 at 9:52
  • @GregAskew It's not a bad point. I'm also showing how password policies and MFA are the defenses in this project. However, the multiple password implementation still would have the purpose of detecting malicious users that have a foothold in the system and are trying to escalate privileges. Commented Nov 27, 2023 at 13:39
  • 1
    Frame challenge: does the password for this account even matter? If you create an account with a name that's attractive to attackers (or likely to be found by then) that's never used by any of your systems, then any login attempt against it is a red flag that should be investigated.
    – Gh0stFish
    Commented Nov 27, 2023 at 17:26
  • @Gh0stFish Honestly...not sure. I've seen tons of false positives before in enterprise systems for all sorts of reasons. It's true that such activity on a consistent system could automatically be flagged as malicious. I wonder if there are legitimate reasons, services, or scripts that are ran on AD that result in false positives in such a case. In my environment, surely not, but maybe in others. Such a detection wouldn't target a password spray then, but it's useful nonetheless. Commented Nov 27, 2023 at 18:31
  • 1
    @CyberKnight if you used a couple of these accounts that may reduce false positives. But I'm struggling to see why any legitimate application would be trying to login to multiple accounts like that over the network - and if anything was doing that it's certainly an application that I'd want to know about and look into.
    – Gh0stFish
    Commented Nov 27, 2023 at 21:46

0

You must log in to answer this question.