We have a 2008 R2 virtual server that is only used for logon via rdp or from local console. No VPN traffic is required.

The server was under attack for a couple of days, viruses where installed etc. Most of it is cleaned up now but i still see many failed logon attempts mostly for user administrator. Logon type of the failed attempts is logon type 3.

From what i understand this (logon type 3) is a logon attempt from the local network. Now i'm trying to disable all logons of type 3 but with no success.

What i have done so far:

  • disabeled file and printer sharing in the network adapter settings

  • disabeled windows networking in the network adapter settings

  • in the advanced sharing settings i disabeled everything (network discovery, file and printer sharing, public folder sharing and password protected sharing)

Also i tried to close some ports that i didn't need, but the login attempts keep coming.

My question:

What can i do to block all login attempts of type 3?

Are there ports i can close?

Other settings that prevent local logons?

Is it possible that these attempts originate from a running program in windows? And if so how can i identify this program?

Other debugging tips?

below an entry from the event log:

An account failed to log on.

    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:       ADMINISTRATOR
    Account Domain:     

Failure Information:
    Failure Reason:     Unknown user name or bad password.
    Status:         0xc000006d
    Sub Status:     0xc000006a

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

Network Information:
    Workstation Name:   
    Source Network Address: -
    Source Port:        -

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.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested


1 Answer 1


Logon type 3 are "3: Network logon—This logon occurs when you access remote file shares or printers. Also, most logons to Internet Information Services (IIS) are classified as network logons, other than IIS logons that use the basic authentication protocol (those are logged as logon type 8)."

Source: http://windowsitpro.com/systems-management/q-what-are-different-windows-logon-types-can-show-windows-event-log

What you really need to do is take a step back and think if you can block these logins and squelch these events, do you still trust that the server is not compromised in some other way? Then it becomes fixing that, then the next. And even still, you might get sucked up into an endless loop because the next compromise you don't know about is re-compromising the thing you just fixed.

The best path is to stand up a new uncompromised VM, and move the services this server was providing, and of course ensure that is done in a way that doesn't move compromises as well. This will seem to be a pain, and it is.

What I cannot get from the post is whether this Windows server was exposed to the public Internet. I presume it was. You really need to put Windows servers behind a firewall and only expose the ports that must be exposed to the public Internet.

  • Thanks, But how can these logins on file shares occur when i have file sharing disabeled? And starting over on a new server will mean that its only a matter of time before exactly the same thing will happen to me again. Also I wonder why it seems to be so hard just to determine which process or network address initiated the login attempt I would think it must be possible to get some sort of trace on that process.. Sep 1, 2017 at 17:53
  • It won't likely happen again if you follow best practices for securing windows servers that must be exposed to the public Internet: social.technet.microsoft.com/wiki/contents/articles/… NtLmSsp is part of the windows authentication stack, and will not be disabled with file & print sharing turned off. Sep 2, 2017 at 13:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .