Successful 4624 Anonymous Logons to Windows Server from External IPs?

If you see successful 4624 event logs that look a little something like this in your Event Viewer showing an ANONYMOUS LOGON, an external IP (usually from Russia, Asia, USA, Ukraine) with an authentication package of NTLM, NTLMSSP, don't be alarmed - this is not an indication of a successful logon+access of your system even though it's logged as a 4624.

If your server has RDP or SMB open publicly to the internet you may see a suite of these logs on your server's event viewer. Although these are showing up as Event ID 4624 (which generally correlates to successful logon events), these are NOT successful access to the system without a correlating Event ID 4624 showing up with an Account Name \\domain\username and a type 10 logon code for RDP or a type 3 for SMB. You can double check this by looking at 4625 events for a failure, within a similar time range to the logon event for confirmation.

The reason for this is because when a user initiates an RDP or SMB connection, the connection via RDP/SMB will be logged as a successful connection, BEFORE the user is prompted to enter their password. This means a successful 4624 will be logged for type 3 as an anonymous logon. When the user enters their credentials, this will either fail (if incorrect with 4625) or succeed showing up as another 4624 with the appropriate logon type and a username.

To simulate this, I set up two virtual machines - one Windows 10, and one Windows Server 2016.

I attempted to connect to SMB via the net use command to the server:

You can see this has been denied. I log into the Server 2016 to check out the event logs and can see it's appearing as a 4624 SUCCESSFUL logon type 3.

To simulate this, I set up two virtual machines - one Windows 10, and one Windows Server 2016.

I attempted to connect to RDP via the desktop client to the server and you can see this failed, but a 4624 event has also been logged under type 3 ANONYMOUS LOGON. This is because even though it's over RDP, I was logging on over 'the internet' aka the network. 


  1. Hello, Thanks for great article.
    I have a question I am not sure if it is related to the article.
    I can see NTLM v1 used in this scenario. Do you think if we disable the NTLM v1 will somehow avoid such attacks?

    1. This is not about the NTLM types or disabling, my friend.
      This is about the open services which cause the vulnerability.


Post a Comment

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I