Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
SOLVED

Account enumeration reconnaissance from an unresolved computer.

Copper Contributor

Hi, we are getting an alert about account enumeration reconnaissance on our network. It says "an actor on MSTSC performed suspicious account enumeration exposing 2 existing account names." This enumeration included 379,129 guess attempts. Because of that being such a high number, I decided to further investigate this. When viewing details of the "MSTSC" computer, it has an unresolved tag: "This user/computer/group was not synced from the domain, and was partially resolved via a global catalog. Some attributes are not available"

 

Because of that, I am not sure how to investigate where this reconnaissance is originating from. There are no IP addresses associated with the "MSTSC" object. We also do not have any DNS entries or AD computers with the name "MSTSC".

 

Any tips on figuring out what the MSTSC object actually is?

6 Replies
best response confirmed by blurn (Copper Contributor)
Solution

It happens if the connection was attempted via RDP.

It's a protocol limitation,  in the NTLM event, this is what the protocol is putting in the machine name field, and there is no IP address in this event.

 

I think this post can give hints on it:

https://techcommunity.microsoft.com/t5/Azure-Advanced-Threat-Protection/Azure-ATP-Unresolved-Entity/...

 

@Eli Ofek understood. Thank you for including that link. I am trying that now.

Hi @blurn, feel free to let us know if you run into issues but that was how we resolved it when I saw something similar last year.

 

In some ways it's a bit disappointing that this hasn't improved in the Azure ATP product in almost a year? The fact is that this should clearly indicate it's an RDP session at the very least - and I'm surprised that they can't at least add the logic to be able to finger the IP/DNS of where the RDP session login is originating from?

 

Regards, Dave C  

@David Caddick thank you! It took a few days for the authentication attempts to reach the DC I enabled debugging on --- we have 5 DCs. Once the attempts were logged, I tracked down the server they were using as an entry point. RDP was being allowed on an external interface on that server. RDP is only allowed on the management adapter now.

 

In some ways it's a bit disappointing that this hasn't improved in the Azure ATP product in almost a year? The fact is that this should clearly indicate it's an RDP session at the very least - and I'm surprised that they can't at least add the logic to be able to finger the IP/DNS of where the RDP session login is originating from? 

 

I agree with everything you said above. That being said, we recently changed our licensing to A5 and gained access to Azure ATP and Windows Defender ATP. Without Azure ATP, I don't think I would have been notified of an issue at all. It might have been something I found when looking through logs.

 

Its a mixed bag for me. I really like the product... but surely there should be a way to find where the attempts are originating from.

 

Something I found humorous was that the most recent attack was labeled like this: "An actor on KIEVSERVER performed suspicious account enumeration without successfully exposing any accounts." Maybe the attackers are naming their servers "MSTSC" and "WORKSTATION"?

@blurn Glad to help + thanks for confirming those steps helped you resolve the issue.

When we resolved this as we did we didn't have Defender ATP to check against, and now that we are getting closer to having Automated responses this is something that I'd look to build out on - although having said that I'm guessing this is not that common a scenario? 

 

Now that we are a year on there is MCAS can tap into Flow, Defender ATP has just announced Vulnerability scanning, and Playbooks are available in Sentinel - so I can see that most of this area is filling out and maturing quite quickly - if you are now on A5 I would push hard to get the three flavours of ATP & MCAS deployed ASAP.

 

I am also assuming that you have Azure MFA + Conditional Access enabled for ALL Staff and Students? - if not let's have a quick chat as I'd be happy to help with some details that we used with a University late last year that can help.

 

Have a great weekend

Dave C


@blurn wrote:

@David Caddick thank you! It took a few days for the authentication attempts to reach the DC I enabled debugging on --- we have 5 DCs. Once the attempts were logged, I tracked down the server they were using as an entry point. RDP was being allowed on an external interface on that server. RDP is only allowed on the management adapter now.

 

In some ways it's a bit disappointing that this hasn't improved in the Azure ATP product in almost a year? The fact is that this should clearly indicate it's an RDP session at the very least - and I'm surprised that they can't at least add the logic to be able to finger the IP/DNS of where the RDP session login is originating from? 

 

I agree with everything you said above. That being said, we recently changed our licensing to A5 and gained access to Azure ATP and Windows Defender ATP. Without Azure ATP, I don't think I would have been notified of an issue at all. It might have been something I found when looking through logs.

 

Its a mixed bag for me. I really like the product... but surely there should be a way to find where the attempts are originating from.

 

Something I found humorous was that the most recent attack was labeled like this: "An actor on KIEVSERVER performed suspicious account enumeration without successfully exposing any accounts." Maybe the attackers are naming their servers "MSTSC" and "WORKSTATION"?



 

Hi @blurn I'm facing similar issues.

How to find unresolved computer ip address / rdp session originating from?
1 best response

Accepted Solutions
best response confirmed by blurn (Copper Contributor)
Solution

It happens if the connection was attempted via RDP.

It's a protocol limitation,  in the NTLM event, this is what the protocol is putting in the machine name field, and there is no IP address in this event.

 

I think this post can give hints on it:

https://techcommunity.microsoft.com/t5/Azure-Advanced-Threat-Protection/Azure-ATP-Unresolved-Entity/...

 

View solution in original post