Access Denied: Identifying Unauthorized Logon Attempts

I can see from the numerous instances of event ID 529 (failed logon: bad username or password) in my Security log that someone is trying to use the local Administrator account to connect to a shared folder on a sensitive member server on my network. How can I determine the origin of these logon events?

If the attacker were using Kerberos authentication to try to access your server with an account in your Active Directory (AD) domain, the answer would be easy. You could simply check the Security logs on your domain controllers (DCs) for Kerberos event IDs such as event ID 672 (authentication ticket granted), event ID 673 (service ticket granted), event ID 675 (domain account authentication failed), and event ID 676 (authentication ticket request failed). You can capture these events by enabling Audit account logon events in your computer's audit policy. Kerberos events always include the client's IP address. For more information about tracking events in the Security log, see "Mining the Win2K Security Log," http://www.secadministrator.com, InstantDoc ID 20052.

However, because the attacker is targeting a local user on the member server, Windows 2000 is using NT LAN Manager (NTLM) instead of Kerberos. If you enable Audit account logon events on your member server, Win2K will start logging NTLM event ID 680 (successful authentication) and event ID 681 (failed authentication). Because NTLM supports transport protocols other than IP, these NTLM events don't report the client's IP address. Nevertheless, they do include the client's computer name. Unless the attacker is sophisticated enough to spoof his or her NetBIOS name, you might be able to track down the attacker by looking for a computer with this name. Depending on the size of your network and the configuration of your routers, you might be able to find the IP address of the computer by pinging the computer name or by typing the command

nbtstat -a 

You can also identify the media access control (MAC) address of the computer's NIC by typing

nbtstat -a 

or

nbtstat -a 

However, Nbtstat doesn't always work on large networks that have switches and routers, and a sophisticated attacker might detect Nbtstat or configure his or her computer to not respond to Nbtstat. Using Network Monitor to sniff the packets might get you closer to the culprit.

The version of Network Monitor that comes with Win2K Server will catch only packets going to or from the local computer, so you need to install the utility on your local computer. To install Network Monitor, open the Control Panel Add/Remove Programs applet and select Management and Monitoring Tools. Click Details, then select Network Monitor Tools and click OK. Proceed through the Windows Components Wizard. After you've installed Network Monitor, open it under Administrative tools.

To start capturing packets, click Capture, Start on the menu bar. After you think you've captured one of the attacker's attempts to connect by using the local Administrator account, click Capture, Stop, then click View. When someone tries to connect to a share, Win2K puts the username in the Security BLOB field of the Server Message Block (SMB) protocol. To weed out extraneous packets, create a display filter that looks for "admin." Click Display, Filter, select the Property tab, double-click SMB in the Protocol:Property list, and select Security BLOB. Enter 610064006D0069006E in the Value field and click OK. This filter causes Network Monitor to display only packets that contain "admin" in the packet's Security BLOB field, so you see only packets that someone trying to connect as an administrator generates. Be aware that the value above assumes the attacker is specifying administrator in lowercase. You might need to filter for ADMIN as well. To filter for any username in the Security BLOB field, you must enter in hexadecimal the ASCII value of each character of the username. Be sure to insert a double zero between each character as I did above.