1

TLDR: Windows Server logs shows successful login with a disabled Guest account. Can someone explain this activity?

In our SIEM, I saw the following event below from our Windows 2016 Server (not a DC).

{
    "TimeCreated":"2023-05-19T16:09:24.690239100Z",
    "EventID":"4624",
    "Task":12544,
    "Correlation":
        {
            "ActivityID":"{35d37f4c-fa11-4b8b-a9f3-b622a0c3206f}"
        },
    "Keywords":"Audit Success",
    "Channel":"Security",
    "Opcode":"Info",
    "Security":"",
    "Provider":
        {
            "Guid":"{54849625-5478-4994-a5ba-3e3b0328c30d}",
            "Name":"Microsoft-Windows-Security-Auditing"
        },
    "EventRecordID":1047382761,
    "Execution":
        {
            "ThreadID":3388,
            "ProcessID":712
        },
    "Version":2,
    "Computer":"Win Server 2016",
    "Level":"Information",
    "EventData":
        {   
            "WorkstationName":"workstation 1",
            "TargetDomainName":"NT AUTHORITY",
            "VirtualAccount":"%%1843",
            "SubjectUserSid":"S-1-0-0",
            "TargetOutboundDomainName":"-",
            "LogonProcessName":"NtLmSsp",
            "TargetLinkedLogonId":"0x0",
            "ImpersonationLevel":"%%1833",
            "TargetUserName":"ANONYMOUS LOGON",
            "TargetUserSid":"S-1-5-7",
            "IpAddress":"10.5.5.5",
            "ProcessId":"0x0",
            "KeyLength":"128",
            "ProcessName":"-",
            "SubjectUserName":"-",
            "LogonType":"3",
            "TargetOutboundUserName":"-",
            "TransmittedServices":"-",
            "LogonGuid":"{00000000-0000-0000-0000-000000000000}",
            "SubjectLogonId":"0x0",
            "ElevatedToken":"%%1843",
            "RestrictedAdminMode":"-",
            "TargetLogonId":"0x230fd0bae",
            "IpPort":"57627",
            "AuthenticationPackageName":"NTLM",
            "LmPackageName":"NTLM V1",
            "SubjectDomainName":"-"
        },
    "Message":"An account was successfully logged on."
}

From the image above here is what I'm observing:

  1. Successful login noted via eventid 4624
  2. Username used to login was Anonymous logon as indicated by SID S-1-5-7
  3. The redacted Ip address in this case is internal (not an external address)
  4. Logon type is 3 indicating a network type of logon
  5. The redacted "Computer" in this case is the server that produced this event. This is the server that's being logged into. This isn't an AD server.
  6. The redacted WorkstationName, from my digging, is a laptop.

From there, I did some additional research as to why I'm seeing "successful" anonymous logins and ran into this article. The article states that an anonymous logon from an external address to a server that has RDP or SMB open publicly could potentially be benign.

Liste below are some differences from the article and some findings I've had post review:

  • The server is not open to the public and the source address is internal
  • I was not able to find corresponding event id 4625s
  • I was able to find some corresponding 4624s with \domain\username but the numbers don't match. For example, I have 10 event id 4624 with anonymous logon but only 5 eventid 4624 with actual \domain\username that line up with the date/time. This means that there are 5 other eventid 4624s that don't have \domain\username.

The question is, does anyone have an explanation of this activity?

1
  • “The article states that an anonymous logon from an external address to a server that has RDP or SMB open publicly could potentially be benign.” - The first example in the article used an example of an client on the intranet.
    – Ramhound
    Commented May 19, 2023 at 16:54

1 Answer 1

0

This is fully explained in the article Successful 4624 Anonymous Logons to Windows Server from External IPs?

Here is an excerpt from the article:

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.

If this explanation fits your case, these are unsuccessful login attempts from the internet. I hope that your passwords are strong, in case this is a brute-force attack.

If the login was however successful, it will be logged again as described above.

5
  • That's the same article I have in my hyperlink within the post. I mentioned previously as well that the server is not open to the public. I'm not all too sure how much of this applies since it's not publicly reachable.
    – Nina G
    Commented May 19, 2023 at 16:27
  • I missed your reference. This could also be someone or some device on your network, not necessarily from the internet.
    – harrymc
    Commented May 19, 2023 at 16:28
  • Maybe. But looking for something concrete. I'm leaning towards it being an expected activity but I'm not finding anything that completely explains this or at least provide any other information that could stick.
    – Nina G
    Commented May 19, 2023 at 16:31
  • The even still is logged before the user is authenticated even if it’s within the intranet. This answer properly explains the behavior
    – Ramhound
    Commented May 19, 2023 at 16:54
  • If all the devices on your network are uninfected, then this is expected behavior by a computer scanning the network neighborhood. The computer will test if it can reach the stage where a password is requested, but will stop at this point without completing the login (it can't). That's how locating network computers is done.
    – harrymc
    Commented May 19, 2023 at 17:05

You must log in to answer this question.

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