Need Help With TDIMon to Eradicate Nasty Bug

I have a pretty serious problem with a Trojan on a Windows 2000 computer
here where the Trojan will every 10 minutes attempt to mount a remote
NetBIOS file system using various remote IP addresses. Many of these I
could traceroute to Asian universities.

I downloaded the Sysinternals tool TDIMon to have a look at what system
component was generating the traffic, and unfortunately the component
appears to be in the kernel. The activity comes fom what TDIMon calls the
System:8 process, and according to the SysInternals ProcessExplorer
application, the System process with PID 8 is the root of the kernel.

TDIMon has a column next to the Process name that is named "OBJECT". The
TDIMon help file doesn't describe this column. This appears to be an
eight digit hexadecimal identifier, possibly for threads or DLLs inside the
kernel. Is someone familiar with this identifier, and what application
would help me trace those numbers back to specific drivers, DLLs, or EXEs in
the kernel?

--
Will

I thought those were the objects passed between the TDI calls (pointers
to its allocated structures) in order to effect the communication.

"Will" <westes-(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
>I have a pretty serious problem with a Trojan on a Windows 2000 computer
> here where the Trojan will every 10 minutes attempt to mount a remote
> NetBIOS file system using various remote IP addresses. Many of these I
> could traceroute to Asian universities.
>
> I downloaded the Sysinternals tool TDIMon to have a look at what system
> component was generating the traffic, and unfortunately the component
> appears to be in the kernel. The activity comes fom what TDIMon calls
> the
> System:8 process, and according to the SysInternals ProcessExplorer
> application, the System process with PID 8 is the root of the kernel.
>
> TDIMon has a column next to the Process name that is named "OBJECT". The
> TDIMon help file doesn't describe this column. This appears to be an
> eight digit hexadecimal identifier, possibly for threads or DLLs inside
> the
> kernel. Is someone familiar with this identifier, and what application
> would help me trace those numbers back to specific drivers, DLLs, or EXEs
> in
> the kernel?
>
> --
> Will
>
>

Will wrote:
> I have a pretty serious problem with a Trojan on a Windows 2000
> computer here where the Trojan will every 10 minutes attempt to mount
> a remote NetBIOS file system using various remote IP addresses.
> Many of these I could traceroute to Asian universities.
>
> I downloaded the Sysinternals tool TDIMon to have a look at what
> system component was generating the traffic, and unfortunately the
> component appears to be in the kernel. The activity comes fom what
> TDIMon calls the System:8 process, and according to the SysInternals
> ProcessExplorer application, the System process with PID 8 is the
> root of the kernel.
>
> TDIMon has a column next to the Process name that is named "OBJECT".
> The TDIMon help file doesn't describe this column. This appears
> to be an eight digit hexadecimal identifier, possibly for threads or
> DLLs inside the kernel. Is someone familiar with this identifier,
> and what application would help me trace those numbers back to
> specific drivers, DLLs, or EXEs in the kernel?

Wouldn't it be faster to flatten the machine and reinstall Windows or
reimage it?

--
Kerry
MS-MVP Windows - Shell/User
www.VistaHelp.ca

Will,

You already probably have done the following, but if you are really
wanting to get to the root (if not rootkit) of this hack, then it may be
better to use some of the other utilities from the PsTools suite, as
TDImon may be looking at this from too lowlevel of a perspective.
You might also find usefulness from the MS provided
PortRptr or perhaps even PortQry
http://support.microsoft.com/kb/837243
http://support.microsoft.com/kb/310099
although possiblly you are seeing traffic due to a loaded driver.

Roger

"Will" <westes-(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
>I have a pretty serious problem with a Trojan on a Windows 2000 computer
> here where the Trojan will every 10 minutes attempt to mount a remote
> NetBIOS file system using various remote IP addresses. Many of these I
> could traceroute to Asian universities.
>
> I downloaded the Sysinternals tool TDIMon to have a look at what system
> component was generating the traffic, and unfortunately the component
> appears to be in the kernel. The activity comes fom what TDIMon calls
> the
> System:8 process, and according to the SysInternals ProcessExplorer
> application, the System process with PID 8 is the root of the kernel.
>
> TDIMon has a column next to the Process name that is named "OBJECT". The
> TDIMon help file doesn't describe this column. This appears to be an
> eight digit hexadecimal identifier, possibly for threads or DLLs inside
> the
> kernel. Is someone familiar with this identifier, and what application
> would help me trace those numbers back to specific drivers, DLLs, or EXEs
> in
> the kernel?
>
> --
> Will
>
>

"Roger Abell [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> You already probably have done the following, but if you are really
> wanting to get to the root (if not rootkit) of this hack, then it may be
> better to use some of the other utilities from the PsTools suite, as
> TDImon may be looking at this from too lowlevel of a perspective.
> You might also find usefulness from the MS provided
> PortRptr or perhaps even PortQry
> http://support.microsoft.com/kb/837243
> http://support.microsoft.com/kb/310099
> although possiblly you are seeing traffic due to a loaded driver.

I will look at those. Is there really no utility that will reveal any
activity by specific DLLs or drivers inside the kernel? Pretty incredible
that Microsoft doesn't provide something like that, given the wide exposure
that kernel files have.

I'll go through the list of installed hidden devices looking for ones that
seem out of place as well. Probably if I remove it the trojan would just
put it back, but that behavior by itself would give some clues.

Would SFC have any use at this point, or would the virus have also planted
itself into the cache that SFC uses for comparisons and restores?

--
Will

"Kerry Brown" <(E-Mail Removed)*a*m> wrote in message
news:OnM%(E-Mail Removed)...
> Wouldn't it be faster to flatten the machine and reinstall Windows or
> reimage it?

I suspect that this activity has been there for maybe more than a year. We
only detected it because of my efforts to start putting things behind
firewall segments, and the firewall monitor shows the traffic pretty
clearly. I guess that's one advantage of using a firewall for the internal
company router. You have a historical record of traffic and an
opportunity to filter that traffic for interesting artifacts, like attempts
to connect on port 139 or 445 outside the local network. The bottom line
is we probably don't have a good backup to restore from.

As far as would it be easier to rebuild from scratch, maybe yes and maybe
no. I have seen this same Trojan now on one other machine here in the
past, and it's clear we have some exposure to it internally (probably a
hacked installer on some software we use). I would like to know what DLL
or EXE is infected if I can get that in less than say two days of work. It
might save us from future infections as well.

--
Will

Will wrote:
> "Kerry Brown" <(E-Mail Removed)*a*m> wrote in message
> news:OnM%(E-Mail Removed)...
>> Wouldn't it be faster to flatten the machine and reinstall Windows or
>> reimage it?
>
> I suspect that this activity has been there for maybe more than a
> year. We only detected it because of my efforts to start putting
> things behind firewall segments, and the firewall monitor shows the
> traffic pretty clearly. I guess that's one advantage of using a
> firewall for the internal company router. You have a historical
> record of traffic and an opportunity to filter that traffic for
> interesting artifacts, like attempts to connect on port 139 or 445
> outside the local network. The bottom line is we probably don't
> have a good backup to restore from.
>
> As far as would it be easier to rebuild from scratch, maybe yes and
> maybe no. I have seen this same Trojan now on one other machine
> here in the past, and it's clear we have some exposure to it
> internally (probably a hacked installer on some software we use). I
> would like to know what DLL or EXE is infected if I can get that in
> less than say two days of work. It might save us from future
> infections as well.

You're right to figure out the cause. I would still probably flatten any
infected computers once the cause was determined. If the machine has been
compromised for a year who knows what has been done to it?

--
Kerry
MS-MVP Windows - Shell/User
www.VistaHelp.ca

"Will" <(E-Mail Removed)> wrote in message
news:44edneqx-(E-Mail Removed)...

>> You already probably have done the following, but if you are really
>> wanting to get to the root (if not rootkit) of this hack, then it may be
>> better to use some of the other utilities from the PsTools suite, as
>> TDImon may be looking at this from too lowlevel of a perspective.
>> You might also find usefulness from the MS provided
>> PortRptr or perhaps even PortQry
>> http://support.microsoft.com/kb/837243
>> http://support.microsoft.com/kb/310099
>> although possiblly you are seeing traffic due to a loaded driver.
>
> I will look at those. Is there really no utility that will reveal any
> activity by specific DLLs or drivers inside the kernel? Pretty
> incredible
> that Microsoft doesn't provide something like that, given the wide
> exposure
> that kernel files have.

For cases where the cause of the traffic is listed merely as "System" / PID
8, I'd think TDImon or Process Explorer. I don't believe PortQry or any
other publicly available Microsoft tool will tell you the information you
need.

--
kind regards,
Karl Levinson, CISSP, CCSA, MCSE [MS MVP]
-------------------------
Microsoft Security FAQ:
http://www.securityadmin.info

--
kind regards,
Karl Levinson, CISSP, CCSA, MCSE [MS MVP]
-------------------------
Microsoft Security FAQ:
http://www.securityadmin.info

"Will" <(E-Mail Removed)> wrote in message
news:44edneqx-(E-Mail Removed)...

>> You already probably have done the following, but if you are really
>> wanting to get to the root (if not rootkit) of this hack, then it may be
>> better to use some of the other utilities from the PsTools suite, as
>> TDImon may be looking at this from too lowlevel of a perspective.
>> You might also find usefulness from the MS provided
>> PortRptr or perhaps even PortQry
>> http://support.microsoft.com/kb/837243
>> http://support.microsoft.com/kb/310099
>> although possiblly you are seeing traffic due to a loaded driver.
>
> I will look at those. Is there really no utility that will reveal any
> activity by specific DLLs or drivers inside the kernel? Pretty
> incredible
> that Microsoft doesn't provide something like that, given the wide
> exposure
> that kernel files have.
>
> I'll go through the list of installed hidden devices looking for ones that
> seem out of place as well. Probably if I remove it the trojan would just
> put it back, but that behavior by itself would give some clues.
>
> Would SFC have any use at this point, or would the virus have also planted
> itself into the cache that SFC uses for comparisons and restores?

SFC would only help if one of the executables or dlls had been modified. I
see no reason to suspect that's the case here. I'm not sure I would bother
with SFC for malware investigations.

RE: Process Explorer from sysinternals.com, see this previous post where a
similar thing [IP traffic from "System" process] was happening. Maybe it
will help you track down the cause. Please let me know what happens, as
I've had similar cases in the past myself and expect more in the future.
From a previous post:

"Scott Townsend" <(E-Mail Removed)> wrote in message

news:<(E-Mail Removed)>...

> Found ProcExp from SysInternals, then looked at the System Process

> Properties, there is a TCP/IP tab

> then every 6-7 seconds the TCp Connection would show up. I did a stack

trace

> on it and came up with:

>

> ntoskrnl.exe+0xa3d9

> ntoskrnl.exe+0x95063

> ntoskrnl.exe+0x982a8

> ntoskrnl.exe+0xa62d3

> ntoskrnl.exe+0xa63a2

> ntoskrnl.exe+0xa63e5

> ntoskrnl.exe+0x699f

> ntoskrnl.exe+0xc577

> RpshSi.sys+0x59822

> ntoskrnl.exe+0x9603c

> ntoskrnl.exe+0xb3b5

> ntoskrnl.exe+0x9d128

> ntoskrnl.exe+0x18c81

>

>

> RpshSi.sys is part of COMTROL, a Serial to TCP/IP Device. The RpshSi.sys

> Device Driver was installed on both machines trying to communicate to the

> Serial to TCP/IP Device.

>

You may want to take another look at the updated PortRptr Karl,
although admittedly in this case with the issue being attributed to
System it may not provide the needed mapping of loaded modules.

"Karl Levinson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Will" <(E-Mail Removed)> wrote in message
> news:44edneqx-(E-Mail Removed)...
>
>>> You already probably have done the following, but if you are really
>>> wanting to get to the root (if not rootkit) of this hack, then it may be
>>> better to use some of the other utilities from the PsTools suite, as
>>> TDImon may be looking at this from too lowlevel of a perspective.
>>> You might also find usefulness from the MS provided
>>> PortRptr or perhaps even PortQry
>>> http://support.microsoft.com/kb/837243
>>> http://support.microsoft.com/kb/310099
>>> although possiblly you are seeing traffic due to a loaded driver.
>>
>> I will look at those. Is there really no utility that will reveal any
>> activity by specific DLLs or drivers inside the kernel? Pretty
>> incredible
>> that Microsoft doesn't provide something like that, given the wide
>> exposure
>> that kernel files have.
>
> For cases where the cause of the traffic is listed merely as "System" /
> PID 8, I'd think TDImon or Process Explorer. I don't believe PortQry or
> any other publicly available Microsoft tool will tell you the information
> you need.
>
> --
> kind regards,
> Karl Levinson, CISSP, CCSA, MCSE [MS MVP]
> -------------------------
> Microsoft Security FAQ:
> http://www.securityadmin.info
>
>
>
>