Advanced Threat Analytics (atauser) leaks NTLMv2 hashes, captured by SpiderLabs\Responder red teaming tool.

Question

Hello,

We have Advanced Threat Analytics (ATA) 1.9 on-premise. The lightweight agents are deployed to domain controllers.

Directory services data source is configured with a domain account.

When running a red teaming assessment, if we run Responder (tool used to capture NTLMv2 hashes) in the background while assessing the domain controllers with an vulnerability reporting tool such as Nessus, Responder captures NTLMv2 hashes of the atauser domain account from the domain controllers.

This is a serious concern within a security product such as ATA, is there a fix/workaround for this?

This issue is very easy to reproduce, the NTLMv2 hashes can be used for pass-the-hash (PtH) type of cyber attacks.

Answer 1

Hi,
This is happening because of the Lateral movement path calculation.
The logic in ATA uses a SAMR call to port 445 on the endpoints, while impersonated to the configured user.
While the authentication is negotiate , due to connection directly to the IP address and not the machine name, it will fallback to NTLM.

For MDI, the logic is different, and while we still use negotiate (no real other choice) we do a best effort to use the resolved DNS name for the connection.
Still, In some environments, this will still fallback to NTLM, depending on their configuration and which endpoint we are trying to connect to...

Since ATA is in extended support, porting of the MDI logic to ATA is not possible.
I would suggest to make sure (as documentation states) that the configured user is a low privileged /read only account, to minimize the risk in case of a NTLM hash leak.

Another possibility is to disable this feature completely, (requires assistance from support) , but it means you lose the lateral movement path functionality.

The best advise is to move to MDI if possible, to get the latest detections and features.

Eli.

Answer 2

Hi c3rberus,

Thanks for your posting on this forum.

According to the Official Document from Microsoft, ATA identify theft using Pass-the-Hash attack through the following two steps:

1. Attackers steal a user's NTLM hash from one computer
2. Attackers use the NTLM hash to gain access to another computer

In my opinion, the reason the ATA didn't alert is that we just stolen NTLM hash from DC but didn't use the NTLM hash to access the computer. Please refer to the below link for details:
https://learn.microsoft.com/en-us/advanced-threat-analytics/suspicious-activity-guide

It seems that the final release of ATA is ATA 1.9.3. And ATA will end Mainstream Support on January 12, 2021. In order to get new features and updates, we could move to the Microsoft Defender for Identity service.

In addition, we could refer to the below link to learn more about the differences between ATA and Defender for Identity:
https://learn.microsoft.com/en-us/defender-for-identity/technical-faq#what-is-azure-atp

Thanks for your time and have a nice day.

Regards,
Rita

---

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 3

Hi Rita,

I think you missed the point here.

The issue here is not that ATA did not alert about a NTLM hash, what happened is that we were able to capture the NTLMv2 hash of the account configured under Configuration > Data Sources > Directory Services inside ATA. This account hash was leaked when we were running vuln. assessments against the domain controller where the lightweight ATA agents are installed.

This is a security issue with the product leaking NTLM hash of the account configured in Directory Services screen.

While I appreciate there are now alternatives to ATA, the focus of this post is for the on-premise 1.9.3 that as of posting is still in mainstream support.