Defender ATP is an EDR solution of Microsoft that provides multiple security features to mitigate threats on endpoints. (e.g. workstations and servers)
What’s cool about Defender ATP is, that it leverages the power of the Cloud, combined with ”machine learning” and ”user behavior analytics” to provide all the necessary protection to (connected) endpoints.
Defender ATP can be connected with Azure Sentinel to collect all the logs from a central dashboard with other data sources that are connected with it. It is currently in preview mode.
In this blog post, I will demonstrate the capabilities of Defender ATP, when it has been integrated with Azure Sentinel.
It often starts with attackers obtaining credentials from memory to escalate further the network, which is by accessing memory to dump credentials.
Since we have our data source connected with Azure Sentinel. It will show all the relevant information in the dashboard that an attacker has accessed LSASS.
union (SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where DisplayName == "Passwords hashes dumped from LSASS memory"
There are different field levels in the event log that is generated to indicate an exposure. As you can see in the following screenshot. Lsass.exe has been accessed.
At the other field levels, there are other additional information with the likes of, on which machine it has happened, and which user has performed this operation.
Another similar event is Sensitive credential read from memory that points out, that it is a part of another incident. This event is a bit more accurate than the above one, because it provides more context.
union (SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "Sensitive credential memory read"
In Azure Sentinel you won’t find this information, but when you go to the Microsoft Defender Portal. It shows the following, which is more accurate. Sensitive credential memory read is part of a possible pass-the-hash operation.
After the credentials have been obtained from memory, there are different ways to move further, which is by performing a classic attack, such as Pass-The-Hash for example.
Defender ATP will indicate that a ”possible” pass-the-hash occurred with the additional information.
union (SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "Possible pass-the-hash operation"
In the description field it says the following: “Memory was read from the LSASS process in a way that is consistent with a pass-the-hash attack. Pass-the-hash works by reading hashed passwords from LSASS process memory and applying one of the hashes in another context to authenticate as the user of that hashed password”
Detecting Pass-The-Hash with Defender ATP is much easier then filtering on specific event ID’s that are generated through Event Viewer. Event Viewer requires things like filtering to reduce false positives, but the chance that a false positive will occur is much higher then detecting it with Defender ATP.
Pass-The-Hash is still a well known attack and forms a danger for most organizations, because it is not something you can easily prevent.
Last, but not least. There is another famous attack vector called ”Pass-The-Ticket, which is a method of authenticating to a system using Kerberos tickets without having access to an account’s password.
The first thing is to export Kerberos TGT’s from memory that we can use later to impersonate a user. In this example, Bob the Domain Admin will be impersonated, because he left his credentials behind on a machine that we’ve just compromised.
After Bob’s TGT has been exported from memory, we can impersonate him and access resources on behalf of Bob.
Defender ATP alerts this attack with a High priority and all the additional information related to it.
union (SecurityAlert | where ProviderName != 'ASI Scheduled Alerts' and ProviderName != 'CustomAlertRule') | where AlertName == "Pass-the-ticket attack"
All the information such as, on which endpoint this attack has occurred and which user performed this attack is exposed in the metadata.
Wait, there is more. In the Microsoft Defender portal, there is more information that can help you triage this alert on a much efficient way, when doing an investigation. At the ExtendedLinks attribute. You can visit the URL that redirects you to the portal.
As you can see in the screenshot. This is the incident graph, that something is happening on a client machine.
In this case, we were exporting Kerberos tickets from memory and that is not a normal behavior.
There is an exact timeline that shows you all the exported Kerberos tickets on a machine.
Both Pass-The-Hash and Pass-The-Ticket are well known techniques and frequently used by attackers to compromise Active Directory, but it has always been difficult to detect it. Thanks to Defender ATP it has been improved, so if you have the chance to use it. Go for it, because it is amazing.
Keep in mind that OverPass-The-Hash has not been covered, because Defender ATP doesn’t alert on it. Azure ATP does has the capabilities to detect it, but I will blog later about that.