dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
10020

Khaine
join:2003-03-03
Australia

Khaine to R2

Member

to R2

Re: Startup Reprised - but not completed...

SnapShoter.zip
10,228 bytes
This version should now work on 98, it also puts the inital.reg md5 in a *.log file, and in future versions I will be expanding its use of the log file.

The gui atm is terrible because I'm working on functionality, not prettyness. I hope to make it more customiseable so it won't always stick the reg file in the C drive.

R2 I took your advice and have changed what the program states if the registry has been altered.

If you try this please give me some feedback so I can improve it.

Also if you want to help, feel free to IM me
Khaine

1 recommendation

Khaine to R2

Member

to R2
Ok, so I have gotten the file comparison to work on 2k, and now to get it functional in 98. I have included a screenshot so you can see what it looks like
dave
Premium Member
join:2000-05-04
not in ohio

1 recommendation

dave to R2

Premium Member

to R2
No insult to the work intended; I agree it's useful, but it appeared to me that you were heading off in the direction of insisting on "complete or nothing". That's all.

(Yes, I overlooked explorer.exe being open; I'd pick another file instead. No, no-one's doing that as far as I know, and it's not "easy" -- you'd actually have to understand COFF, not that it's hard but I'm not impressed by the average skill level of bad guys. I just meant that there will forever be new ways to compromise a system).
psloss
Premium Member
join:2002-02-24

1 recommendation

psloss to R2

Premium Member

to R2

Re: How would this be used?

said by R2:
Should a Startup program show you Running Processes? It is a matter of opinion.
It's absolutely a matter of opinion -- a "startup program" can be narrowly focused, but I think it should be used in a broader context. But I hope that we can agree to disagree on this without it taking up too much of your time or becoming personal. And this has become tangential to the thread, so I'll stop.

Philip Sloss

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

1 recommendation

R2

MVM

No biggie. Moving on...

OK, as promised attached is the comparison of the programs. You will note I reluctantly added on AutoStart Explorer -- but I cannot guarantee that I did a great job with verifying its abilities. However, I HOPE someone will come back and rip me to shreads for NOT doing a good job on it!

Furthermore, I simply have not had time to verify each and every Registry Miscellaneous setting -- especially for WinNT-XP. One cannot help but notice that StartupList looks for many similarly named keys and values. Are they all useful?? I have no idea -- "MAYBE" is the best I can say.

How many of the nearly 100 items on the list are important? Again, I cannot be sure. I have looked into the ones on Win98 that I feel are most important.

Some items are simply not displayed correctly by the program. I must honestly state the AutoStart Explorer correctly identifies the dosstart file's contents on one computer, but not on another. I don't know why, but the one it fails on has a lot of REM lines in it....

I hope people will look over these lists and make comments as to the appropriateness of some of the items listed. One section that no one SEEMED to look at was the WinNT-XP Group Policy scripts. I can fairly easily run scripts there and I am not sure any of these programs would tell you this.

Furthermore, while these programs may examine the standard registry keys for Winlogon, ApplInit_DLLs, WOW, Desktop, and Shell= -- it appears to me that these keys can easily be modified in the "IniFileMapping" section of the registry. So... perhaps the IniFileMapping" section of the registry needs to be queried before simply looking at the standard keys. (Untested information)

Additionally, I THINK one can modify the Path statement so that other folders can be used to launch explorer.exe before C:\%windir%. Although at least StartupList investigates for SOME "stray" explorer.exe files, I don't see that it checks the Path statement first.

Again, more food for thought...
R2

R2

MVM

Oh, a few extra comments. More is not always better. At first glance, it appears that StartupList is far superior at finding the MOST Startup entries. However, there is a few problems with this analysis:
  1. The full display requires the user to run the program with various command switches. In my opinion, this makes the program much less user-friendly -- and much less helpful to Joe Enduser. It would not take much effort to simply display a user interface that gives the user radio button options before the program is run. The user could then choose exactly what he wanted the program to display.
  2. The default display of StartupList includes the BHO's and ActiveX controls in the Downloaded Program Files folder. To me, these should definitely be optional choices on the user interface.
Other points to consider about these programs include:
  • Autostart Explorer has by far the best initial appearing user interface window, with AutoRuns in second place.
  • However, the "Open Folder" button in Autostart Explorer (AE) never seems to work correctly (Win98).
  • Furthermore, Autostart Explorer (AE) offers no quick way to export its data to Notepad or Clipboard. All other programs offer relatively easy methods of copying the data so it can be posted into a forum.
  • Additionally, the right-click Context Menu on AE only shows a gray-out (non-functional) Properties option (Win98) So a 'pretty' interface that is only partially functional is not really a big plus.
  • The right-click Context Menu on Autostart Viewer (ASV) is the most useful and includes many nice options.
  • AutoRuns (AR) incorrectly places "Copy to Clipboard" and "Refresh" on its Context Menu (they have NO contextual function), but is does offer a nice and unique "Jump to..." option.
  • Only Autostart Viewer (ASV) allows you to Delete an item directly in the program.
  • Both AutoRuns (AR) and Autostart Viewer (ASV) suffer from not creating a button bar up top. AE creates a minimal one -- but at least it does that!
  • Only Autostart Viewer (ASV) has a direct Print function (albeit, not working correctly - Win98). Startup List (SL) uses Notepad for its 'interface', so it prints easily also.
  • Autostart Viewer (ASV) does use 'Optional Display Choices' in its single Menu Bar item -- "Main" (obviously a contradictory name!:)).
So the choice of the 'best' program remains far from clear. All programs appear to have some good points.

[text was edited by author 2003-05-08 13:20:00]

Wayne DCS
Premium Member
join:2001-12-07
Australia

Wayne DCS to R2

Premium Member

to R2

Re: Startup Reprised - but not completed...

That must've taken quite a while to test and put together
That's great work R Not, I'll look into the check list tomorrow (well, later today - 2am here at the moment,just analysing a polymorphic trojan before i hit the sack) to try and get that list 100% checked in the ASV column. It might take a few days, maybe a week or more, but we'd like nothing more than for it to obtain 100% detection according to your criteria.

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2

MVM

I wish I had the resources and 'staff' to actually check into all of the items listed above. I simply do not -- and furthermore, I leave for a trip to Chicago tomorrow AM. I cannot in good consciousness tell you that you need to get "100%" on the list -- certainly, searching the HKCU RunServices keys should NOT be a priority on anyone's lists.:)

But at least this brings to light -- eh, as best I can -- where a Startup program should consider looking to be "relatively complete". Of course, I would add an extended "Shell Spawn" section, but I think I have beaten that WAY beyond death...

Additionally, I failed to point out that only Autostart Viewer (ASV) checks the standard Run keys in both HKCU and HKU\Default. To tell you the truth, I am not sure that is necessary, but it could not hurt!

Wayne DCS
Premium Member
join:2001-12-07
Australia

Wayne DCS

Premium Member

Ok, ive spent all morning working on ASV and I'll be spending the rest of the day on it, but here are some notes of what I've done so far and questions I've got for you in regards to a couple of things you listed that aren't autostarts ..

1) ASV was already checking for c:\explorer.exe existance (not on your list, but you didnt give ASV a checkmark for 'Stray explorer.exe entries' which this is). Nonetheless, I've added PATH environment variable checking - it recurses through the list in the same order the operating system does, and will let you know if it finds an explorer.exe in a directory before it finds explorer.exe in the Windows (or system32) directory.

2) IniFileMapping. Here is some information i couldnt find on the web, but in the MSDN CD library there's a good article called "Mapping .INI File Entries to the

Registry" (PSS ID Number Q102889). Here's a snippet:
---
Under Microsoft Windows NT, Windows 2000, and Windows XP, .INI file variables are mapped into the Registry as defined in the Under Microsoft Windows NT, Windows 2000, and Windows XP, .INI file variables are mapped into the Registry as defined in HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\IniFileMapping
---

Basically, IniFileMapping alters the behavior of the INI-related APIs (such as WritePrivateProfileString and GetPrivateProfileString) so that they access the registry rather than the .ini file. I've never seen a trojan write directly to existing .ini files because they're too easy to corrupt, and using the existing APIs not only makes it easier, it also makes it more reliable so it's in the trojans best interest to use the normal INI-related API functions.

Even if a trojan did directly modify, for example, system.ini [drivers], it wouldn't work because IniFileMapping means the .ini file isn't used - only its registry counterpart. So in conclusion, IniFileMapping isn't anything to worry about - it just means that the values will be coming from the registry, not the .ini files.

3) Added improved analysis of file association autostarts. For example, in the case of exe files, the HKEY_CLASSES_ROOT\.exe key is examined. This should almost always be "exefile", so then HKEY_CLASSES_ROOT\exefile\shell\open\command is examined. However, if the value WASN'T "exefile" - let's say it was "otherfile", then HKEY_CLASSES_ROOT\otherfile\shell\open\command would ALSO be examined. I don't believe any other autostart viewing programs do this, but it's critical they do or trojans will be able to remap the associations to avoid detection.

4) Why is super-hidden file extensions on an autostart list? NeverShowExt/hiding files/etc has nothing to do with autostarting ...

5) Likewise, why is 'regedit integrity verification' on an autostart list? And why only regedit?

6) It's hard to see which keys you're referring to because of shortened paths. For example, "HKCU\.\Windows NT\..\Windows\Load=" obviously expands to "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load, but others aren't as easy to guess. Can you kindly provide a full list of those reg keys without shortening them so we can tell which ones they are?

Many thanks,
Wayne

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2

MVM

  1. It is sometimes hard for me to tell exactly what each program is checking and what they are not checking -- that is one of the reasons why it took so long to get that list done. I used the list of items on your page here, plus I did my own testing. Clearly, with this many number of entries, it was not possible for me to test them all. I did the best I could, but I am sure I made several mistakes. I had to get that done before my trip.
  2. I think you are just about to get my point about IniFileMapping.;) Continue on with you analysis and take the next step. OK, you are checking only the default key assignment for the registry values in question. What if I simply used the IniFileMapping key to MAP the information to a different key?? You would be left looking in the WRONG key! This is much the same as ONLY checking the default Startup folders. I can easily fake you out by reassigning the Startup folders to non-default folder. The analogous situation can occur here....
  3. Based on what I have been reading, verifying the File Extension Associations would be a smart thing to do. I outline the detailed version doing that here. And KhanineBOT's program would pick up Command Hijacking (Spawning) as well. It all depends on how sophisticated the Trojan writers become at using this technique -- it can get quite complicated. Also, while this is an "AutoStart" method, it is not a true "Startup" method -- so programmers seem to view the importance of this topic differently depending on the goals and desired use of their program.
  4. The super-hidden file extension concept has been included on the oft-quoted "TLSecurity" Startup list for years -- so perhaps this is simply a tip-of-the-hat to that old -- now apparently defunct -- standard. In defense of SL, that is not included by default -- it only appears if you run the program with command switches.
  5. I don't know why ONLY regedit. That type of check could be done on MANY File Extensions -- as I have stressed above. The "regfile" type IS included on my long list here -- so regfile is NOT INappropriate to evaluate because of the potential for Command Hijacking (Spawning), it just is not the ONLY type that should be looked at...
  6. Sorry, I had to sacrifice those keys somewhat to keep the image width intact and improve overall readability. I actually have to leave for the airport!! But, download StartupList and check it out. SORRY. My wife is staring at me!

Khaine
join:2003-03-03
Australia

Khaine to R2

Member

to R2
SnapShoter.zip
19,376 bytes
Source.zip
9,992 bytes
Ok I have a fully working final version (unless any bugs are found), this version will extract your HKCR and then at a later date you run it again and do a comparison, and it will point out what keys have changed.

Currently it is quick and dirty, it calls regedit to export the HKCR branch, and fc.exe to do the file compare.

I have made 2 versions, one for 95/98/Me and one for NT/2k/XP this is because using fc /L on 2K makes every character on a seperate line, and so I use /U.

To get these to work, please place either 2k.bat or 98.bat in C:\ depending on which version of Windows you run.

The source code is included, feel free to improve it
Khaine

Khaine to R2

Member

to R2
I also forgot, Have fun in Chicago R2
Merijn
join:2002-09-09
NL

Merijn to R2

Member

to R2
R2, that table you posted has to be the best comparison I have ever seen

I now know exactly what I'm missing in StartupList, and I'll get to the missing feature ASAP.

I've already done fix the AltStartup debacle - checking all 8 possible regvalues and the folders they specify.

As for the VMM32 and IOSUBSYS sections, I don't see how these are relevant yet. Honestly I have no idea how they work, and if a trojan ever used them yet. I don't think I'll be putting those two in StartupList.

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2

MVM

Thanks. It was fun -- albeit time consuming.:)

I am not sure about Vmm32 and Iosubsys as well -- I cannot test all of these.:(

If you are interested, I wrote a little front-end user-interface for StartupList. If I have time later, I will test it out and package it out as a beta...
R2

R2 to Merijn

MVM

to Merijn
I was thinking SOMETHING like this. I still have some bugs to work out -- but that should be quite possible.

If you are thinking of adding more switches, let me know. Plus, if you know the next version number -- although I guess I should be able to automatically extract that from the executable...

Khaine
join:2003-03-03
Australia

Khaine to R2

Member

to R2
R2 you certainly have put alot of time and effort into this, and I hope that it helps improve our understanding of where programs can startup in windows.

I also hope you like the final version of my simple HKCR checker

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2

MVM

It was a good excuse for me to look into this area -- it is something that has always intrigued me.

Your HKCR Checker is a good idea.

Personally, I would like to see this concept incorporated into other "Trojan Detecting" or "AutoStarting" software. I guess it will depend on whether Trojan writers begin using this 'autostart technique' as the sole method of launching their malware. That may be what it will take to inspire the programmers to offer any thing more than a token attempt at investigating 'Shell Spawning' or 'Shell Command Hijacking'.
R2

R2

MVM

I could not help but notice...

Here is YET ANOTHER piece of malware -- this time a Worm -- that is using the "Shell Command Hijack" or "Shell Spawning" technique to help "AutoStart" itself.

This one is again using the txtfile File Type -- one that NONE of the present "AutoStart" or "Startup" programs look at -- despite the fact that 'txtfile' seems to rank second only to executable extensions as the "most abused" file type...
Merijn
join:2002-09-09
NL

1 recommendation

Merijn to R2

Member

to R2
said by R2:
If you are thinking of adding more switches, let me know. Plus, if you know the next version number -- although I guess I should be able to automatically extract that from the executable...
The next version will be 1.60.0000, or 1.6 for short.

It'll probably have a new switch /md5 that calculates filesize and MD5 checksum for each file if it makes sense. This would help automated analysis of logs, as well as detection of trojans that replace and mimic a system file.

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2

MVM

Thanks. I will modify the interface to include those.