Options

F0 - system.ini: Shell= Yup that looks fishy!

Unknown
edited July 2004 in Spyware & Virus Removal
F0 - system.ini: Shell=

in my HJT log.. what do u guys think?

Comments

  • KwitkoKwitko Sheriff of Banning (Retired) By the thing near the stuff Icrontian
    edited July 2004
    It's apparently a bug in one of the versions of HiJackThis. Make sure you download the latest release and run it again. It should be gone.
  • Straight_ManStraight_Man Geeky, in my own way Naples, FL Icrontian
    edited July 2004
    I ignore that one, absent other things. Its in my ignore list. Alone it is no longer a pure single indicator of junk. together with other entries, it can give clues as to the hijack involved. It did show up in 1.97.7 and 1.98 until I did one of two things:

    Redid the shell entries to read:

    Shell=Explorer.exe

    OR put it on ignore list.

    Windows XP Pro works BOTH ways-- Explorer.exe is linked in elsewhere in registry also. So, right now, it is on ignore list, and thus I eliminate that one entry form as a sole entry for consideration. I use other HJT recognition indicators. IF Windows behaves, opens up Windows Explorer (which is what Explorer.exe is the underneath part of) and I can use it, and My Computer runs well, that one entry does not matter being that. AN ENTRY with something other than Explorer.exe present in it with a Shell= also in same entry, that I look real close at, but my system here works FINE with that particular entry that way, EITHER way shown.

    The possible "buggy thing" in HJT (and its basically a non-bug given HJT's purpose scope) is that it does not know to put back the Explorer.exe part, but HJT is a potential bad reg entry marker\flagger and reg entry deleter, and not a heavy registry repairer in the sense of restorer\healer of good entries per se outside of junk removal. It is a top notch flagger, but removes bad only. The "final" fix for the shell entries with nothing after the = sign is to restore Explorer.exe as sole target, using a registry editor-- every blinking time the shell gets application hijacked-- this is one kind of a shell:application bug+vuln exploitation in XP (unresolved, doced as present in January on Neohapsis by a low level code researcher(in this case, not a novice researcher, instead someone good at digging deep into the lower levels of XP, 2000 and 98, etc), and used since then), where the shell spec gets redirected to a non-Explorer.exe application that causes this.

    So far, Microsoft publicly is saying that the level of exploit of this in practice does not merit a full-court-press fix right now-- they IN FACT have more pressing issues to deal with. In fact, they are so swamped with Sasser-related calls on thier free security\virus hotline that you get a recording telling you where to look for how to kill that every two-three minutes of the hold music (PUB is the only place I do that discussion of support overload implications).

    BUT, they now know trojans are being written to (and security folks have seen some in the wild in past ten days that DO) use this shell:application vuln that in essence lets an exteriorly introduced app either be default run by Explorer.exe or run INSTEAD of it. Some of the other patches they are doing may help block this mostly, also, at other vuln access tree levels-- especially some of the downloadject fixes posted on Microsoft on July 13th. The ADODB.stream patches will help close the download and install route that has been used for this hijack to happen remotely. AFAIK, and I hope this really happens, a shell:application fix should be in SP2 for XP. Can't say will be, yet. CAN say SP2 RC2 closes one code method already implemented (thus proven) to use the ADODB.stream download and install route that lets this happen in a totally automatic and user-transparent manner.
Sign In or Register to comment.