Security Log Event ID 4625 - An account failed to log on every few minutes - random source IP addresses

Question

A fairly new MS Windows Server 2019 VM installation is logging over a hundred Security Log Audit Failures a day with Event ID 4625.

RDP for the server is enabled only for a single trusted WAN source IP through the Draytek Firewall.

The server hosts 2 local applications and an on-premises Exchange Server. The PDC is another VM on the same physical bare metal Hyper-V Core host.

The Account Names, Source IP addresses and Workstation names appear to be quite random, though the workstation name "workstation" appears quite frequently.

An example log entry is:

An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       Hp
    Account Domain:     

Failure Information:
    Failure Reason:     Unknown user name or bad password.
    Status:         0xC000006D
    Sub Status:     0xC0000064

Process Information:
    Caller Process ID:  0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:   workstation
    Source Network Address: 40.117.34.82
    Source Port:        0

Detailed Authentication Information:
    Logon Process:      NtLmSsp 
    Authentication Package: NTLM
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

So my immediate thoughts are:

1. I thought NTLM was disabled by default since Win Server 2008 onwards?
2. Would I be right in thinking it isn't in this case?
3. Should I disable it? If so where?
4. Could disabling it break anything? If the applications break, that's fine if it makes the server more secure. I can get the application developers to beef up the apps. I'm worried about losing remote admin access through TeamViewer and the Exchange mailserver breaking.

I'm kinda shitting myself right now as we've only just installed this server to replace an old Windows Server 2011 that got hit by ransomware.

I've heard about using programs like IPBan, but that would only seem to make sense if the attempts were from the same IP. In this case they seem to be from random addresses.

Would I be right in thinking having the necessary ports open for the Exchange Server (80,443,587) is the only reason these attempts from WAN IPs are even reaching the server? Is there anything I can do to prevent these log-on attempts from reaching the server or is this a level of intrusion to be expected when running an Exchange server?

Answer 1

Would I be right in thinking having the necessary ports open for the Exchange Server (80,443,587) is the only reason these attempts from WAN IPs are even reaching the server?

Well, yes. If you have those ports open from the internet to your Exchange server then this is what I would expect.

Is there anything I can do to prevent these log-on attempts from reaching the server or is this a level of intrusion to be expected when running an Exchange server?

If you don't want these logon attempts to reach the server then don't open those ports from the internet to the server. Of course, that would defeat the ability of legitimate users of reaching their mailbox on the server. If you want the server to be reachable from the internet for legitimate users then you're going to have to live with this. An IDS/IPS might help to block some of the illegitimate attempts, but it probably won't eliminate all of them.

Answer 2

thought NTLM was disabled by default since Win Server 2008 onwards

NTLMV1 protocol and the LM hash were both disabled.

Is there anything I can do to prevent these log-on attempts from reaching the server?

You don't want to disable authentication attempts from reaching the server.

Would I be right in thinking having the necessary ports open for the Exchange Server (80,443,587) is the only reason these attempts from WAN IPs are even reaching the server?

Port 587 is used for this kind of authenticated traffic. (Challenge/Response is not the only kind of Authentication that Exchange Server can handle). If you aren't using POP or IMAP you may be able to close this port, and you will get fewer NTLMSSP authentication requests.

You can also disable the NTLMV2 service if you aren't using it for something else. If you have Kerebos correctly set up for internal authentication, and don't have have any other apps using challenge/response authentication. That won't stop the TCP connections, but will probably stop them being recognized as authentication requests. There are some differences, so you might notice a few things that don't work the same

Disabling SMTP_AUTH is now recommended for Exchange 365 -- other forms of client authentication are used. That means disabling port 587. On Exchange Server, "Turning off SMTP_AUTH" means "allow un-authenticated SMTP traffic" which is not what you want to do until you know what you are doing.

Answer 3

Agree with what joeqwerty has said above, and based on your error messages you provided above, i have found that this issue may be caused by User logon with misspelled or bad user account.For more details: 4625(F): An account failed to log on. and The Security event that has Event ID 4625 does not contain the user account name on a computer that is running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2

In addition, i think you could post your question in windows server forum will be a better choice and you could get more accurate replies.