The problem is that a lot of known detection use cases rely on excluding computer accounts based on their name ending with $ sign (which is not a true indicator if the account is associated to computer or a user), to reduce false positives or because it's not relevant. Some example of use cases where you may find this problem:
- Unusual Logon Activity
- Pass the hash | Over Pass the hash
- Pass the ticket
- Kerberoasting
Sometimes those exclusions are necessary, which open the door for any attacker with enough privileges "Account Operators group, Domain Admins group, or the Enterprise Admins group in Active Directory" to create a fake or real machine account and hide his activity from standard monitoring approaches. If the attacker can obtain valid NTLM hashes for an existing privileged computer account, he can do the same without having to create one.
As you can see below, Logon events 4624 for legit computer account PC01 and the rogue one (user account that mimic the naming convention of computer accounts) a logon activity are similar:
To create a real computer account, one can use AD admin tool or the dsadd command utility (net.exe is limited to user accounts).
Example of 4720 event "a user account was created" after using net.exe utility with HMIDA$ as user account name and fake computer like account name:
In order to reduce the risk of this blind spot we will be looking at ways to flag abnormal logon activity with a computer account. The following are potential indicators to look at:
Detection Use Cases:
Example of 4720 event "a user account was created" after using net.exe utility with HMIDA$ as user account name and fake computer like account name:
In order to reduce the risk of this blind spot we will be looking at ways to flag abnormal logon activity with a computer account. The following are potential indicators to look at:
- User account created with a name that mimic a machine account (i.e. MSSQLDB01$)
- Interactive Logon with a fake computer account (i.e. RDP)
- Two Logons with different computer accounts and from same source IP and within a short period of time
- NTLM Logon with a real computer account and source workstation is different than the computer account
- Logon with a domain controller computer account (usually something like DC01) and the Source IP address is not associated to a domain controller
Detection Use Cases:
- EventID=4720 and "Account Name" contains "$" sign.
- NTLM authentication (EID=4776) and "Logon Account" is like ".*\$" and "Source Workstations" != "Logon Account"
- [EventID=4624 and "Account Name" like ".*\$"] followed by [EventID=4624 and "Account Name" like ".*\$"] and different "Account Name" and same "Source Network Address" within 2min
- EventID=(4624|4625) and "Logon Type" is any of {2, 7, 10} and "Account Name" like ".*\$"
- EventId =(4624|4625) and "Account Name" like ".*DC.*$" and "Logon Type"=3 and ""Source Network Address" != Domain_Controllers_Subnet
AQL Query 1 [Covers Creation of fake computer account]:
select username, "DestinationUserName", "GroupID" from events where "EventID"=4720 and DestinationUserName IMATCHES '.*\$' last 90 DAYS
AQL Query 2 [Covers suspicious real and fake computer account ntlm logons]:
select "SourceUserName", "Source Workstation", "ErrorCode", count(*) as cc from events where "EventID"=4776 and SourceUserName imatches '.*\$' and not (SUBSTRING("SourceUserName", 0, STRLEN("SourceUserName")-1) = "Source Workstation")
GROUP BY SourceUserName, "Source Workstation", "ErrorCode" last 90 DAYS
select "DestinationUserName", "AuthenticationPackage", "LogonType" from events where "EventID"=4624 and DestinationUserName imatches '.+\$' and (LogonType=10 or LogonType=2 or LogonType=7) last 90 days
In Part 2 of hiding in plain sight with a rogue computer account, we will be covering an example of 3 ways to use a fake computer account and what are the possible left artifacts that one can observe on both the client and the server side.
References:
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4720
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4741
https://msdn.microsoft.com/en-us/library/cc246064.aspx
https://msdn.microsoft.com/en-us/windows/desktop/cc781364
https://ss64.com/nt/dsadd-computer.html
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4741
https://msdn.microsoft.com/en-us/library/cc246064.aspx
https://msdn.microsoft.com/en-us/windows/desktop/cc781364
https://ss64.com/nt/dsadd-computer.html
Hello, very nice article. Is there any report that supports this scenario? I mean was this technique happened in the past?
ReplyDelete