Can't stop persistent 529 failed login attempts from within local machine

Hello, This is a worm that attacks to the PCs with enabled NetBIOS. The worm tries to establish null sessions or brute-force common user names.

Please disable Windows NetBIOS on the PCs and check the result. If you need to keep NetBIOS enable on the PCs for printer and file sharing then you need to block NetBIOS ports on the firewall.

Best protection against null sessions is blocking ports UDP 137 & 138, TCP 139, and TCP 445 at the firewall. Doing so will not allow null sessions from outside your network, but you are still vulnerable to internal attacks.  

Virus scan the afflicted system using its own virus scanner.  If nothing is found, try these online virus scanners, in order:

Symantec (slow, but finds more things)
BitDefender
Eset

Remember to scan any USB removable media that the users may be carrying around to prevent further infections.

If none of the above show an infection, continue with the Malwarebytes scanner.

Note that if the server is infected, it is probable that one or more of its clients are infected as well.  If the server itself is not infected, the virus resides on one of its clients and the scan above must be repeated on each of its clients until the infected machine(s) are located.

Thank you for your quick responses, want to let you know I have seen these posts. I will work with the suggestions and get back to you as soon as possible with the results.

I too have faced this annoyance.  I have seen this on standalone XP boxes not even networked to anything.  It could be an infection of Advapi, or, it could be a "bug" in windows XP as documented here http://support.microsoft.com/?kbid=811082

In windows xp security news forums it's been discussed and therefor mirrored in xp security archives like this one http://www.tomshardware.com/forum/21937-45-worrying-security-event
I generally detest and do not like the "oh just ignore the error that's normal" answer as unacceptable.
Here is another thread where suspicions about .Net and myriad updates seem to end with the replacing of the NVidea video drivers (!) as solving the problem http://forums.majorgeeks.com/showthread.php?t=229847

Thank you for your comments.

Artsec: I have tested my ports UDP 137 & 138, TCP 139, and TCP 445. The TCP ports are not visible on the internet. The UDP ports are enabled but not showing any activity on them and cannot be accessed by internet port tests. I don't want to disable the UDP ports because the workstation is on the network and is used remotely and . . . I just don't see that it will work because the printers are shared. I have watched the firewall reports and watched netstat activity and have seen nothing on those UDP ports that ever correlate to the times these failed log on attempts occur.

DrKhlan: Malwarebytes was the first thing I ran when I saw a problem, then I ran several other utilities, a full virus scan, etc. No problems showed up. I also ran your three suggestions and found no problems. This company's controller well understands that all the remote users must have updates, the antivirus programs, etc blah blah blah. Via the terminal server program, the users can only use one program and the internet browsers from within this workstation are blocked as well.

Ocanada_techguy: That is correct, this problem occurs even when it is completely disconnected from the network. Re the first and second links you suggest, since the PC has SP3, the hotfixes of the article are already applied. Re the third link, the PC they are talking about appears to be not on a network. As for ignoring the problem (I know you are *not* suggesting I do so . . . ), I have read that too but the logons are obviously a brute force attack of some kind because they are using test, admin1, user1, john, etc.

So, again, since this problem occurs when not connected to the network, the attack is coming from within. And I cannot track down how. . . I know this is probably a complicated and frustrating question so I am patient and grateful for others thoughts on this matter.

If you can find I would remove advapi.exe (presumably netdevil 1.2 virus or variant) *not to be confused with advapi32.dll

Ocanada techguy: I forgot to say last time that the video driver is Intel, not Nvidia. But yes, I have seen virus-like behaviors linked to Nvidia drivers. As for removing "advapi.exe", it's not there, only advapi32.dll

Ah k, well, there are several ways by which these might be happening.  Depending on security settings you might also have a 680 event for every 529 event.

As you've pointed out your example 3 example 4 kind, the username and/or domain (or machinename) for credential turn out to be usernamess that in your deternimation are old discontinued ones or legitimately exist BUT on other boxes never have been logging on to this particular box.

A possible reason might be if users are logging into the XP that runs XPUnlimited from machines or using accounts which have in the past had to connect to other machines or printers, there can be some apps, services or other which may "remember" the old credentials once used to make the connection, and a sort of "bug" in the app or service tries that credential on odd occasion, at an interval of maybe once an hour or even less.  So when users connect from their home/remote RDP clients the client may include the XPUnlimited "host" in such connection attempts.  For instance local resources like printers or disk drives require "discovery" which requires connection attempts, possibly to all the other machines that the XPUnlimited host has had local office LAN connections to other shares or printers throughout the office, and each new RDP session might instantiate those attempts each time.  The above links about NVidea and Bitdefender being such culprits are examples.  Theoretically then it could even be on the remote RDP clients that these are coming from.  Also Microsoft themselves had such an issue as referenced in kb article above.  I've seen other examples, SpyBot Search & Destroy comes to mind.

Could it be something within the one box itself?  Yes, since we have seen this phenomenon on standalone boxes that aren't even connected to any lan or network whatsover (a very rare thing in today's world).  In those cases an application or something set to run as a service may have a flaw, as previously referenced.

So it might not be malicious, or it could be.  In comment you also mention brute-force attack, so perhaps I can help you to distinguish between the different kinds, the different avenues by which these may be happening.

A couple of key security concerns to point out for the reader.  1. On XP (as well as 2000 and 2003) these events in event logs do NOT have the originating IP address.  Later Windows OS does record the IP in the event which greatly helps id their source.

2. Port-scanning "robots" are all over the internet, sometimes having hijacked other people's computers and running in the background on theirs without them even knowing.  These "bots" scan and find open ports and some will also try brute-force gaining access, attempting the usual Administrator, admin, User, Guest, john and other most common usernames and passwords (blank, 12345 etc) to see if they get in and if they do report this back to some that are constantly running on the internet and infected boxes discover open ports.

If your users are going to connect, the ports must be open, but if they're open, scanners will find them.  About the only solutions are a) only open the ports when needed, b) set-up firewall rules on machine and/or router/switch networking equipment so that originating IPs have to be added explicitely to an allow whitelist (which is a burden/obstacle anytime client's IP address changes at the whim of their ISP, or else c) implement a VPN that's protected and/or encrypted which can help secure all other port avenues of attack, but which may add overhead or hurdles.

I mentioned a tool to help.  For your open situation, there are several.  1. You can install the Port Reporter tool (service).  The Port Reporter tool runs as a service on computers that are running Windows Server 2003, Windows XP, and Windows 2000. The tool logs TCP and UDP port activity
http://support.microsoft.com/kb/837243 
You can then use the PR-Parser tool to open and view the logs in a grid that you can filter and apply criteria.
http://support.microsoft.com/kb/884289

I find this tool helpful for recording the IP address of incoming RDP Remote Desktop attempts.  I've oft seen, tere could be as many as 800+ hacking attempts in a single 30 minute period.  It also identifies outgoing connections and the processes that opened them.

It makes a new logfile for each day or if the logfile gets too big (which in your case can happen quickly) so keep in mind those logfiles accumulate and you want to archive/filter and/or discard them.  Either that or set the service so it is not automatic and only run it during periods you want to capture.

There are other traffic monitoring tools, Wireshark for instance.

If you're convinced it's within the box itself, the ProcMon Tool from the Microsoft SysInternals Suite may help pinpoint what is happening.

see also https://www.experts-exchange.com/questions/26823052/Monitor-network-traffic-in-XP.html

ocanada_techguy: There are no companion 680 events. It appears not to be a matter of a service "remembering" old credentials since it is calling up usernames that never existed on any PC on the network. Since I ran Shields-Up for hours and it could not get into the workstation in question, it seems to me the firewalls and router settings being used are secure. I also used other port testing utilities with the same result. Whitelisting IPs *would* be the nightmare you suggest, since the ISPs from which the employees connect change their IPs all the time. Port Reporter shows the same results I get in netstat and Avast-Pro Firewall -- every IP tracked is one I recognize as an employee connection.

Yes, I do believe it is internal, on this workstation itself since  it occurs when disconnected from the network and I see not attempt to open unexpected ports. I will try the other suggestions ASAP today. Just wanted to let you know where I am at this point.

ocanada_techguy: I intalled and checked activity with Wireshark and Commview (yes, handy to know about, thank you for the suggestions) but I recognize all the IPs that show up. I worked with ProcMon all day today (I use the SysInternals rootkit utility but forgot about PM so thanks on that, too) but I can't find any process that should not be opening, no program running, no IP that should not be there.There is nothing during the times the 529/539 events occur that points to any process, etc that is suspicious.

Today, the fake usernames changed to "aloha" and "pos", with numerous attempts with "administrator" even though the attempts are blocked after 3 tries. I searched on "aloha" for quite a while and came up with nothing helpful. There are a couple threads about it on E-E's forum but they only say, yes, there appears to be hacking going on.

When I test the RDC ports the results come back that they are available but not open so I am *assuming* that's about as secure as I can get them, though I'm no expert so I may be wrong. I'm going ot try TCPView (just found it) as another tool now, just for one more try with something. Will give results on that little experiment when I get them.

TCPView showed nothing during the time 529/539 events occurred.

I ran Microsoft Baseline Security Analyzer and came up with everything as suggested for best practice. I'm at a loss. I know I can't forget about this.

Hmm, well, let's consider... just because you recognize the IPs that accesses are coming from doesn't mean those computers at those IP addresses don't have spyware/malware on them which could be probing for vulnerabilities and/or attempting connection(s), right?
How many 529s are there? A handful corresponding to each legitimate RDP connection, and then maybe an additional one each hour or so? Or is it a burst of several hundred at various hours (like one would expect a brute force attack)?
As discussed, I've seen a couple 529s corresponding to every legitimate logon and log back ins from screensaver fast-user-switching password prompt at the console of standalone machines.  (and so when RDP connections are idle and then the wiggle mouse return to session those re-establishing connection could have same effect)
And of course you very likely have a combination of all of these, as well as brute force attacks from unknown IPs.

Thank you for not giving up on this problem.

The remote PCs are being brought into HQ one at a time (which should also help me see if that affects the problem) for me to go through to clean up, and I do hope to find something that leads me to what has infected the TS.

The 529 failed logons are now clustering up to 100 or more sequentially, 25 attempts of one user following another, 25 at a time whether it's a fake (unknown) user like User32 or a legitimate username from somewhere on the network and noted as being locked out for exceeding logon attempts. The time sequence changes, although it always happens at least once as soon as a user legitimately successfully logs in. Fast-switching is disabled. Usually, a failed attempt with a username occurs few minutes (sometimes 5, sometimes 30, sometimes an hour or so) and I find no correlation with someone logging on or an app being used or a service being called upon.

Yesterday, a new sequence has started. A fake name type 10 appears (like this one):


then it is followed by:


and then that is followed with a repeat of the failed logon followed again by the Event ID 515 for Winlogon\MSGina and goes on for several attempts, each following the other.

Failed type 3 and 4 logons as well as individual type 10s also occur off and on during the day, sometimes as singletons, sometimes in clusters of varying numbers of attempts.

Because many of the failed attempts are type 10, one would think at least some of these are coming from one of  the remote users, but  I get the type 10 even when no remote uses have been logged in for several hours.

Short answer: you don't have a VPN you're far more vulnerable.

If you've collected the IP addresses for some of those clusters, you might recognize some IPs and therefore have an idea which employees home/remote boxes are contributing to the problem, but I suspect you'll also find some clusters of brute force attempts are coming from the four corners of the planet, and because of it's spread distributed approach, you've got to check/clean them all.
For the benefit of all readers:
That's how many such malware are designed, a distributed de-centralized approach, whereby time is spent looking for open ports and vulnerable boxes, reports that information back to some central servers somewhere, then infection or snooping to capture usernames and unencrypted passwords if possible, which are reported back or shared, as well as dictionary and brute force attacks in clusters at random intervals.  All of this runs peer-to-peer-like in the background of infested machines of users that have absolutely no idea except that their system is slower than it was when it was new.  Whether it's the russian mob hoping to capture credit cards, or China hoping to happen upon a defense contractor, it's all mysterious secret underground stuff of white hats versus black hats.
One way they guess usernames or email addresses is through "different" vulnerabilities, such as a form on a browser, because people usually use the same username and same password for multiple things.  If a rogue facebook app prompts for username/password and people go ahead and supply it, it might share that so the miscreants can immediately try the same password to break into that email and then every online service they find inside that email account.  Some forms on browsers aren't encrypted and ask for email, username so simple malware can collect it.  Same idea with printer, or even graphics driver for goodness sakes, the graphics driver has to communicate with other "protected" processes and has to pass credentials.  As of Service Pack 2 Windows XP introduced Data Execution Prevention (DEP), and so on and so on.
Look at windows update critical updates, many of them say words like "this update is designed to prevent a remote ... executing / gaining access ... " etc etc.   Are there remote / home boxes where these are significantly behind/out-of-date, or malware has disabled updates on the box?  That's a big red flag.  Does every box have both anti-virus as well as anti-spyware current and up-to-date?  Enforce a corporate policy that every box should.  Microsoft Security Essentials is free for home so there's no cost excuse not to.
Enforce domain password policy so complexity is high and cannot keep or reuse the same password forever.  Educate your users http://money.msn.com/identity-theft/how-i-would-hack-your-passwords.aspx?page=0 as well as on the necessity for critical updates and up-to-date anti-virus and anti-malware/anti-spyware.
For detection, one tool is usually not enough.  You'll find one tool may find an extra item or two that another misses.  SuperAntiSpyware portable is a good on-demand test, you can check and clean a machine with it without necessarily installing it.  Malwarebytes is another excellent tool, that you install, and after it's trial period the active protection in-tray stops but you can still manually scan with it (such as once a month or whenever suspicious behaviour is noticed).  If rootkits are suspected (and these can be difficult to detect as advanced ones create their own hidden encrypted folder so anti-virus cannot look at it's files/contents) then HitManPro, TDSSKiller, or ComboFix can help.

The only IP addresses I find are the ones I recognize and they only show in the firewall logs or IP trace/track utilities (not in the SystemEvent files which would be handy), with no relation I can see to the failed logons because, as I've said, the logons occur even when the TS workstation has its Ethernet cable disabled.

When the TS was first setup, I worked with Cisco to try to set up VPN but they said the various internet connections were too weak even though they were highspeed. No matter what the Cisco techs and I tried, the connection either could not complete or it would drop for the remote users. It was an expensive experiment. Until now, the router firewall configurations we use appeared to work because, in the 4 years the TS has been running, it has never been infected.

I have a tight grip on the in-house computers but the remote ones are a bit rogue because whenever a branch needs a new station, the branch manager just goes out and buys one and I never see it until there is a problem. Not ideal and the controller knows that is not ideal but it has been something I've battled for years. Now that we have this problem, I may have finally convinced them to give the new machines to me first.

I block the use of browsers on remote PCs as I get them and the remote users all know they are not to use Facebook, etc on their company workstations. (In-house PC workstation browsers are blocked.) As I get the remote PCs in, I check for that kind of activity just to be safe. They know they are supposed to allow the updates or install automatically and of course I check for that. As each one comes in, I install my remote repair program which tells me if Windows updates are needed/installed. They know the anti-virus/spyware needs to be kept up-to-date, will be checked as they come in and with the remote repair program installed I can check them myself.

Password policy is already high and they are changed on schedule, but changing the passwords has made no difference in the 529 failed logons attempts because the logon attempts occur repeatedly even after the username is locked out for surpassing the number of password attempts allowed.

When doing routine cleaning I run a variety of malware tools. Malwarebytes is run first, SuperAntiSpyware is run second, then followed by others and a full antivirus scan, etc and I keep working with the box until it comes up clean. Combofix is used when needed as well. Yes, once in a while a rootkit requires I use several utilities until I can track it down, and HitManPro and TDSSKiller are two of them. All of these programs and more have been run on this workstation and come up clean. That's why I'm flummoxed that the 529 attempts are still going on.

I will run PortReporter again, logging a couple hours tonight when only remote users are connected, a couple hours tomorrow when both in-house and remote are active, and then a couple hours when the PC is completely off the network. I will look at these logs and then give you an up-to-date answer ASAP.

Am writing to tell you today is the first day I have been able to even touch a computer. I am quite ill this week and am not yet back to work. I will get back to this, I hope, in a couple days. My apologies.

I am scheduled to get back to work tomorrow. Please forgive my inability to work on this problem. This was very bad timing for me to get  pneumonia!

OK, I ran 2 hours of PortReporter with the terminal server e-net cable unplugged. Before looking at the Parser, I checked the corresponding time in the Security log and you are right. [Red faced] The logon attempts are *not* present. I would have sworn cross-my-heart-and-hope-to-die that I did not have my reports mixed up but . . .

Apparently, my original "unplugged report" times were wrong, they must have overlapped when the cable was plugged in and I did not realize it. I am glad I was willing to back down and run the reports again when you were politely insistent that my observations were likely to be flawed.

I will now work step-by-step with only the two servers on, then check as PCs come on. This will take some time.

Do you wish to consider this closed? Do you feel I have a handle on it now that you have shown me where my assumption was incorrect? I feel I can continue on my own, egg-on-my-face and all, but if you have any more pointers I'd be glad to hear them. And BTW, I think you were incredibly polite, professional and patient, and spent a lot of time on this and certainly deserve more points than my original 500. I will look into how to change that.

Cupitor, oh, okay, ah yes time zone differences on timestamps and such, it happens.
Thank you for you kind words, no worries.  Well, just know it is not outside the realm of possibility a handful happen when no network, (probably very few, 1 or 2 at several hr interval, but yeah could've misled you).

Well, I will close this then. Since this is my first question ever, I hope I get the helpful/accept process correct! Again, thank you.

This person has great patience and I appreciate the polite persistence that made me go back and run another trial that led me to see where I messed up my report. Also, the "FYI" explanations are a great help to those who want to try the solution but don't quite yet understand all they are attempting.