[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2011
  • Last Modified:

SBS 2003 - Cannot locate source of Logon Attack Failures

I have a SBS 2003 server on my network, which has come under a brute-force attack from an unknown source (no source IP or source port).  I cannot find where this attack is coming from and believe it to be an infected client launching the attack at various times.

This is a sample of the many Event Viewer entries (the others have various user names):

Event Type:      Failure Audit
Event Source:      Security
Event Category:      Logon/Logoff
Event ID:      529
Date:            2/10/2011
Time:            1:20:04 AM
User:            NT AUTHORITY\SYSTEM
Computer:      <server name>
Description:
Logon Failure:
       Reason:            Unknown user name or bad password
       User Name:                             alice
       Domain:            
       Logon Type:                              3
       Logon Process:      Advapi  
       Authentication Package:      MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
       Workstation Name:      <server name>
       Caller User Name:      <server name>$
       Caller Domain:      <domain name>
       Caller Logon ID:      (0x0,0x3E7)
       Caller Process ID:      1564
       Transited Services:      -
       Source Network Address:      -
       Source Port:      -
(No "alice" user account exists on the network)

What is my best course of action to find out which client(s) may be compromised or where this attack is coming from?  Is there a better way/software to monitor incoming traffic no matter the source?

Thanks in advance.
0
geteke
Asked:
geteke
  • 3
  • 2
  • 2
  • +3
2 Solutions
 
Old UserCommented:
Download and install Wireshark

http://www.wireshark.org/

use this to capture the traffic and you should be able to identify the ip address that is causing your issue
0
 
Alan HardistyCommented:
Enable logging on your router for all inbound traffic.

Check to see what process ID 1564 is (Task Manager - Add the PID column if it is not showing which it won't be by default), then report back the process please.

Please also have a read of my blog article:

http://alanhardisty.wordpress.com/2010/09/28/increase-in-frequency-of-security-alerts-on-servers-from-hackers-trying-brute-force-password-programs/

and

http://alanhardisty.wordpress.com/2010/12/01/increase-in-hacker-attempts-on-windows-exchange-servers-one-way-to-slow-them-down/

Alan
0
 
Oh-Y-NotCommented:
First course of action would be to identify what PID 1564 is. I've seen those before, and I bet ya it is inetinfo.exe.

Report back when you have that info. What to do next depends on what info we have.

::: Tony
0
2017 Webroot Threat Report

MSPs: Get the facts you need to protect your clients.
The 2017 Webroot Threat Report provides a uniquely insightful global view into the analysis and discoveries made by the Webroot® Threat Intelligence Platform to provide insights on key trends and risks as seen by our users.

 
Alan HardistyCommented:
Tony - please read the previously posted comments before adding a repeat of what has already been posted.

Thanks

Alan
0
 
getekeAuthor Commented:
There is no Caller Process ID 1564 in Task Manager. It may only come around when the attack is being launched.

I have WireShark installed, but what filter should I set in the capture options?

Is there another way to find the source?
0
 
Alan HardistyCommented:
Have you added the PID column and sorted the PID column, then looked down the list for PID 1564?
0
 
Cliff GaliherCommented:
Just connecting a few of the dots, when the "workstation" in the event is the server itself, it means that a program or service running on the server itself is what is failing to authenticate. This takes things like network file shares, printer shares (SMB traffic) and similar client/server protocols off the table. What that leaves are various services that provide their own authentication method to the client and then authenticate against AD on the client's behalf. SQL *can* do this, but is rare. Most often this is a web page where the credentials are gathered in a web form and then the IIS server authenticates against AD, so the workstation ID is rightfully being reported as the server.

For SBS, there are several default services exposed. OWA, RWW, and if you've configured it, sharepoint. So the attack is likely external to your network. You have a webpage up so the attacker is just throwing random junk against your website and seeing what sticks.

A good UTM device can help you track where the attack is coming from, but in many cases these days, it is a botnet so the attack is *very* distributed and difficult to spot trends with the naked eye just scanning logs.

*GOOD* UTM devices offer HTTP/HTTPS screening and will notice the failed login attempts and will add IP addresses to a temporary blocklist providing a far better control mechanism and a more automated approach to managing brute-force hacks. I find TMG 2010 particularly well suited for this as it offers full SSL bridging so even HTTPS traffic is inspected and tracked.

HTH,

-Cliff
0
 
getekeAuthor Commented:
I did alanhardisty,  and it does not show PID 1564.  I also don't believe that this was a service on the server trying to authenticate, as the user names being used varied and were random. Some that were used were candy, mail, administrador (that's how it was spelled), alex, alice, and many others.

If there is no Source Address or Source Port, does that indicate that the attack was within the network and not from, say, the internet?  Are there other logs in SBS that could be of better help?  Could the Security Logs on the clients be of better help?
0
 
itcokCommented:
You could be seeing these events because of Brute Force attacks on the RWW or OWA login pages...

You can test this yourself by attempting to login with a fake user account and then watch as your security logs report the event. You'll see the following for each failed attempt.

       Logon Type:                              3
       Logon Process:      Advapi  
       Authentication Package:      MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
       Workstation Name:      <server name>
       Caller User Name:      <server name>$

Open in new window


I'm going to suggest that this is not a direct attack but rather a bot net that has found your login pages and is going to try to gain access before moving on to another IP.

If your hard pressed to take action you'll need to correlate the failed login events with your firewall logs so you can determine the originating IP and then block it.

I run an FTP server and am constantly under fire... I rely on good passwords to keep the bad guys out. But, if I see a repeat and frequent offender, I'll block the IP.
0
 
itcokCommented:
+1 to cgaliher comments...

Sorry Cliff, I tend to respond before reading through all the other responses.

0

Featured Post

Put Machine Learning to Work--Protect Your Clients

Machine learning means Smarter Cybersecurity™ Solutions.
As technology continues to advance, managing and analyzing massive data sets just can’t be accomplished by humans alone. It requires huge amounts of memory and storage, as well as high-speed processing of the cloud.

  • 3
  • 2
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now