New preview detection: Security principal reconnaissance (LDAP)

[Tali Ash]

We are proud to introduce a new alert in preview mode that addresses Security principal reconnaissance (LDAP).  This type of reconnaissance is typically used by attackers to gain critical information about the domain environment. 

Lightweight Directory Access Protocol (LDAP) is one the most popular methods used for both legitimate and malicious purposes to query Active Directory and is commonly used as the first phase of a Kerberoasting attack. Kerberoasting attacks are used to get a target list of Security Principal Names (SPNs), which attackers then attempt to get Ticket Granting Server (TGS) tickets for.

Starting from Version 2.67, Azure ATP now detects when suspicious LDAP enumeration queries are made or when queries targeted to sensitive groups that use methods not previously seen are observed. In order to allow Azure ATP to accurately profile and learn legitimate users, alerts of this type are only triggered first the first time 10 days following Azure ATP 2.67 version deployment.

For more information visit https://aka.ms/ldaprecon

Stay tuned for additional alerts and updates.  As always, your feedback is welcome.

[#2]

Are there any plans to update this alert to include what actor performed the query? It's very unhelpful to say "an actor on server sent a suspicious LDAP query" without specifying the actor. @Tali Ash 

[#3]

We don't have the actor as this is happening using the machine account.
If you have MDE on the machine you might have more data to cross with to find the actor.

[#4]

@EliOfekSource? That would be useful if it was in the documentation of Msft and we don't need to ask on techcommunity. Do you have any suggestions to correlate this alert with factual events on the machine? That would be useful too. Thanks.

[#5]

@mboisvert If you look closely at the alert details, even export it excel you will be able to see that the entity involved in this case is the machine account.

Note that this could happen to other alerts as well if the attacker used the machine account.

If you have specific recommendation of what specific statement you are missing from the docs and where, I am adding  @Deleted  to help with that.

[#6]

@EliOfek Thanks for the quick reply. Yes I remember we could do this in the OLD portal. But I think it is not possible in M365 Defender now. In any way, would it be possible to have it IN the alert and no need to do an extra steps to avoid that confusion? In m365 defender, this is what the alert gives us: Timestamp, Base Object, Search Scope, Search Filter, Enumeration Type, Sensitive Type, Queried Groups. Basically, only what was queried, but no context (process, command line...). There is no correlation at all, so it is difficult to investigate accordingly. I found some documentation online, but either the Schema or the Action type in the queries given as examples doesn't exist. Do you have any documentation to help costumers investigating such alerts?

[#7]

M365 has the option to export to excel as well.
You won't get Process \Command line info from MDI alert as we don't have visibility in the endpoint.
We are not that smart (Yet) to automatically correlate MDE events from the machine (If you have it there).
I think this link might be a good start for alert investigation:
https://learn.microsoft.com/en-us/defender-for-identity/reconnaissance-discovery-alerts

@Deleted Might be able to supply more if there is something.

[#8]

If machine account is performing expected behavio, how would one go about suppressing the alert by employing exclusion for detection logic? Would excluding cause something of concern to slip through? How do we ensure its being addressed with specific detection to given entity while ensuring others continue to report.