In-Reply-To: <2BF76EF9C289D046B3E7B9E20F9B0642AD7F48@mail.paylessoffice.com>
Dan,
A company who I do consulting for has had 2 machines in the past 2
months who have been infected with adware and spyware who's network
interface shows "Limited or no connectivity". The first was some time
ago, and the only way I could get the machine to talk on the network was
to slick and rebuild it (probably the responsible thing to do anyway).
Was it really the responsible thing to do? Unless you could show that the
system had been subject to an Admin-level compromise, what did the "slick and
rebuild" buy you? Yeah, you got a working system, but since you never
discovered what the issue was, how do you go about protecting the system from
it in the future?
"Slick and rebuild" should be conducted when the facts and evidence show it to
be necessary. Doing so in the short term may get systems up and running again,
but using a variety of tools, you can collect volatile data for analysis, and
actually perform a root cause analysis. From there, you may find that you do
not have to "slick and rebuild" at all...and you'll be able to protect all of
your other systems from the same issue.
From what I have read on the internet this means that the computer
cannot connect to it's DHCP server.
True, but there may be a reason for it.
A repair of the interface results in
an error saying that an address couldn't be obtained from the server.
When you say "repair", what do you mean? Based on the response, I would assume
that you did an "ipconfig /release" followed by a "/renew"...is this the case?
Reinstalling TCP/IP, Repair installs of WinXP, reinstalls of SP2, Virus
and Ad-aware scans do not fix the problem. Dealing with the 2nd machine
this has happened to,
Have you done any packet sniffing to see what's being sent out? I once had a
situation that I was assisting on, and the end of the story was that the
application on our end had a hard-coded 5 sec time out...so, even if the
transaction was completed successfully (saw the response code and data coming
back from the server), the client still reported an error. Increasing the time
out to 10 sec dropped the error rate from over 20% to under 0.1%. So sometimes
looking at the traffic can tell you a lot.
Also, check the subnet mask and gateway settings.
I've found a process called wmiprvse.exe that didn't look familiar,
Okay, it's not clear what you did to determine how familiar or legit it maybe,
so here are some suggestions:
1. Did you get the full path of the process's executable image? According to
a quick Google search, it should be in C:\WINDOWS\System32\wbem\wmiprvse.exe.
2. Did you get a chance to check the File Version information embedded within
the file? According to several sources found via Google, this is a valid
Microsoft file...checking the file version information would quickly verify
this.
In summary, it seems as though you made assumptions about what happened and
then allowed those assumptions to direct your "investigation". I don't
recommend this an approach, as in the long run, it really doesn't buy you a
great deal.
I hope some of my suggestions help...
H. Carvey
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
