Possible Malware Infection on Home System

So, I've a potential malware infection on a host within my home LAN.  It is a Windows 7 system.  Before anyone ridicules the choice of Windows, let it be known that it is rather easy to secure a Windows system from a lot of malware.  Really.  And in my line of work, I've seen many non-Windows systems compromised, so my view is entirely different than the typical *nix zealots out there.  If you aren't already aware, I tend to be highly objective when it comes to OS ideology.  I'm not going to be open to discuss things if the first shared thought is, "why are you using Windows?"  I'm not for the "down with the man" mentality.

Now, about this issue.  Here are the current symptoms:

McAfee AV is installed.  It was found to not be running when I first began to investigate.  I reactivated it last night, did a quick scan (no issues detected) and then did a full scan (no issues detected).

I also ran MalwareBytes.  It didn't find anything other than some cookies that it suggested to be removed (I removed them).

I also ran both AdAware and Spybot: Search and Destroy.  Both found some spyware-related things that I removed.  They didn't find anything with high severity.

I also ran the MS malicious software removal tool (it didn't detect any issues).

I did all this yesterday evening and finished around 8PM.

I also have Snort sniffing traffic on the LAN.  It is detecting some rather weird traffic.  It is seeing the Win7 system trying to communicate with a Linux host on port 137 (the Linux host is refusing the attempts).  Also, if I do a tcpdump to see any traffic coming from the Win7 machine, I see the Win7 machine connecting to each Linux server on the LAN on port 80.  What's odd about that is that it seems to have focused purely on the Linux machines, and each and every machine it connects to actually has Apache running.  I've seen no service scans (or any other scans).

This morning, I decided to check the Snort logs and saw that the activity stopped occurring after my "fix" last night, but that it started up again at 2:44AM this morning.  When I checked the Win7 host, McAfee wasn't running.  I couldn't restart it (it was unresponsive).  I did another MWB scan, which didn't detect anything.  I checked the system logs and didn't see anything other than a lot of DNS errors (that may be indicative of anti-antivirus activity).  I then went to the McAfee AV home page to get a status of my system and saw that the status was, "This device needs to be online to get the latest protection updates."  Weird, especially since I've no indication that the system isn't online.

I decided to search the McAfee pages to see what solutions they offer (free solutions).  Right off the bat, I saw that the only thing they offer is a $90 removal service...WTH.  Their product let the machine get compromised, then they want to charge an additional $90 for removal (and no other free offerings).  That seems hokey.  I never had this problem with Norton/Symantec.

At this point, I'm probably going to reinstall the system with it's factory image.  This is the first time in a very long time (I'm talking 10+ years) that I've had to reimage due to malware on a Window system.  I've other systems in the house running Windows, and some have NO 3rd-party AV (my Alienware system is running Win8 and it's using Windows Defender without issue).

I'll keep this post updated with any other information I discover over the next few days.

UPDATE - I've found some free tools -- http://www.mcafee.com/us/downloads/free-tools/

UPDATE 2 - I've conducted some scans using the free tools and I'm still not able to find anything.  I'm wondering if the activity I've observed is actually part of their host discovery toolset...that sorta makes sense.  If only I could get some type of verification on this from a McAfee rep, or maybe find some document that describes how the host discovery system works and how it would look from a network security perspective.  But all that still wouldn't explain why the AV keeps disabling in the middle of the night...

FINAL UPDATE - Issue resolved.  After investigating further, I found that there was no infection.  Two things were occurring:  1) I've found that the AV services appear to be polling for services (network discovery - Symantec/Norton has this feature as well), 2) the self-update process had hung, which was causing the AV shutdowns.  Once I removed the existing version and got the latest, I found that there was a drastic difference between the two versions.  As well, the account portal had changed.  The fact that there was a major client upgrade may've broken communication with the account portal (that began working once I upgraded manually).  When this subscription is up, I'll either use Windows Defender or use one of my existing Symantec licenses to install that AV onto the system...not liking the McAfee AV experience.  :/

Sophos Vulns

I saw this at an internal website (internal to my work):

Two vulnerabilities in Sophos’ anti-virus software for Microsoft Windows and Unix/Linux, will allow an attacker to remotely inject arbitrary code and also produce a Denial of Service (DoS) attack. Any version prior to 2.48.0 is affected. Please follow the links below for remediation.
http://www.heise-security.co.uk/news/94954
http://www.frsirt.com/english/advisories/2007/2972
http://www.sophos.com/support/knowledgebase/article/28407.html

This reminds me that the FAA is running Sophos AV clients on both their Windows and *nix IDSs...its stupid to even run AV on a machine that is dedicated to IDS, but I thought about them nonetheless...heh.

Edited on 8/28/2007:

I wanted to elaborate on my comments.

There's are several reasons why you shouldn't run AV on security devices:

1. The AV solution may have zero-day vulnerabilities. Sure, you can block off all attempts against the management interface of the IDS device, but why even set yourself up to a possible compromise of a critical piece of architecture?

2. AV (and firewall...yes, both installed on an IDS in the FAA's case...I'm not BSing) solutions usually demand quite a bit of system resources. IDSs usually demand major system resources also. The two will eventually bump heads, unless the IDS is seeing no traffic (which, IMO, means that the IDS is worthless or may need its sniffing interface to be placed at a more critical location).

3. Just because NIST recommends a certain security posture doesn't mean that their recommendations should be applied blindly (yes, I'm talking about the FAA). I'm also aware that the Department of Transporation (which FAA falls under) demands this ridiculous requirement. Managers should question anything that isn't apparent in guidelines from higher headquarters...to not do so is to admit that you are a follower and not a 'do-er'.

I say these comments because I worked with the FAA for awhile and certainly didn't like their way of thinking, but I worked there (as a contractor, which didn't help my situation much) and just took what was dished to me. After several years of wondering if I should've voiced my opinion more strongly before leaving their organization, I'd have maybe actually taught their management and DOT's management some things about REAL security and how their security professionals SHOULD operate. All I can say now is that I now know (and experienced) what NOT to do, especially as a security professional.

Bud, if you're reading this, know that I'm in a far better place and while I wish my friends still working there well, I do know that I will never ever be the type of person that put up with sub-par management and sub-par decision-making. I'm certainly working in a better place, but I'd like to thank you for making me a better person...you did make me better at knowing idiots when I see them. IDSs and firewalls on IDS devices...hahahaha!