Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2022
  • 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 HardistyCo-OwnerCommented:
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
Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to Squarespace.com and use offer code ‘EXPERTS’ to get 10% off your first purchase.

 
Alan HardistyCo-OwnerCommented:
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 HardistyCo-OwnerCommented:
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

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