MJ Registry Watcher

MJ Registry Watcher version 1.2.1.7 has been released at http://www.jacobsm.com/index.htm#sft . It is mega, and really covers most of the trojan registry hooks with its 105 default keys. It can drill down into the registry, adding subkeys to your list, and you can balance sheer number of keys against performance requirements of the PC yourself. Remember, all values for any given key are checked (even multi-strings and quadwords!), so WinLogon is covered. Enjoy.

Graphic

 

Hi Graphic Eq

Thanks for the great program, it looks like a real winner! I was just wondering if it would work ok with 9x/me systems? Thanks.

 

I don't see why not. You may have to add some keys to the default set, but have a look at https://www.wilderssecurity.com/showthread.php?t=32823&page=1&pp=25 to see a comparison table by Hojtsy.

Graphic

 

Superb! RegWatcher has become a *must have* in my security set-up. Thank you very much.

 

Hello again Graphic.

You already know how I feel about your program. A-NUMBER-1.

I do have one suggestion. Here is a scenario.

I really like the relatively new feature of being able to choose either a "prompt" when MJRW detects a key change, or to simply "accept" or "reject" all changes to monitored keys. I would like to be able to utilize the "reject" option in a situation where I have MJRW loaded on PC which is used by a newbie who doesn't install new software - just surfs the net & reads email.

However, I have noticed that when certain security programs do their auto-updates, a subsequent scan by this security program will set off a warning by MJRW. I guess the auto-update actually changes the program in some way, and also changes a registry key. And I DO want to accept this change to the registry.

So, I could go and manually remove the offending registry key from the list of keys being monitored by MJRW. That would allow me to reject all other changes, and still allow the update of my security app on this PC. But for the technically-challenged, determining which key is causing the warning, and deleting the correct key from the MJRW list can be slightly difficult.

What do you think about adding an option that would allow the user to remove a key that from the list being monitored that is associated to a warning? In other words, when a warning pops up, add a control (check box?) that the user would check if she wants to have MJRW automatically remove the registry key from the list being montitored that caused the specific warning.

Just a thought. Not really an added security feature - just a feature to make it more user friendly.

Thanks again.

 

I am not sure I understand you properly here. Are you saying that, certain security programs cause an alert box to spring up from MJRW, even when MJRW is set to auto-accept or reject changes? I would be interested to know exactly what the alert said - could you put up an image please? Or is it because the update causes a reboot, since MJRW does not have a configuration file yet, and goes back to Prompt mode when restarted?

Could your problem be solved by running 2 or more MJRWs, with different sets of keys and auto reject accept prompt settings? Are you running version 1.2.1.7?

Graphic

 

Sorry. A somewhat naive question here.

Does Registry watcher actually watch the following files?

config.sys, autoexec.bat,wininit.ini,winstart.bat,system.ini,win.ini

etc which I got from http://research.pestpatrol.com/Whitepapers/AutoStartingPests.asp

Or those under the heading "Folder autostart locations" and "File autostart locations" on http://www.diamondcs.com.au/index.php?page=autostarts

I know the name of your app is "Registry watcher" but it seems to watch the Start Menu\Programs\Startup folders anyhow, so you might as well extend it to watch those files?

After all we are not monitoring registry keys just for fun, but mainly to prevent autostarts?

If those are already covered , please ignore.

 

Graphic - I've attached a pic containing 3 of the multiple warnings after running a scan using (in this case) WindowsWasher. I get similar warnings with others.

I'm assuming that I am getting these warnings because the scan by WindowsWasher is changing a registry key. And I have MJRW set to prompt me when changes are made. If I were to set MJRW to reject warnings, I'm concerned the security software (in this case WindowsWasher) would not function properly. So maybe I simply want to remove the key being monitored that is affected here. How would I go about doing that? I could manually determine what key is being changed and remove it. What I'm suggesting is that MJRW give me the option of not monitoring that key anymore and have MJRW remove that key automatically from its list.

What do you think?

Edit: Yes, I am running the latest version.

 

Daisey : I see. I'll incorporate something like this into the next version. Perhaps it could "comment out" the key from further checks, in case you needed it again later.

Pollmaster : No, version 1.2.1.7 does not look at these files. The next version is going to monitor the date/time/filesize/file attributes of all of these files, by allowing filenames in the top window, and checking these parameters for each one it encounters. I heard of one nasty that I'll be looking for, and that is c:\explorer.exe (which shouldn't exist, or ought to be byte for byte identical to the official Windows one in c:\windows, if it does exist). On boot-up XP will look for this file first, *BEFORE* c:\windows\explorer.exe, and so a trojan could drop a bad explorer.exe into your root directory, and it would be "game over" for the PC.

I am going to introduce in the next version, a method of updating the list with new registry locations and startup files, by simply providing a separate link for the MJRegWatchKeys.txt file, rather than embedding the default list (currently over 8K of key names) into the RegWatcher executable. The file will also form part of the usual download zip file.

Best regards,

Graphic

 

Graphic , sounds great. Looks like Registry watcher is shaping up to be a very excellent tool for detecting autostart methods.

 

Thanks, Graphic. Now the only decision the user has to make what the impact is of not monitoring a specific key. And that's a decision I doubt software can help with.

 

Hi GE
I think this registry monitor does a fantastic job,thanks for your hard work
I want to tell you that I discovered a minor problem,if I change the refresh rate it changes back to 5 seconds if I restart the program
I hope you can find the problem

cheers
Kaupp

 

Graphic,
Your valuable help against malwares is much appreciated.
-hojtsy-

 

Hi,

I attempted to replace
hkey_current_user\software\microsoft\internet explorer\main

with
hkey_current_user\software\microsoft\internet explorer\main\start page
hkey_current_user\software\microsoft\internet explorer\main\search page
hkey_current_user\software\microsoft\internet explorer\main\search bar
hkey_current_user\software\microsoft\internet explorer\main\local page

in my monitored list, but it seems MJ RegWatcher do not allow watching of specific values. It is very unfortunate since 1) these 4 values should definitely be watched, and 2) the Window Placement value in the same key is always changing, producing irrelevant alarms with the default config.

Can we hope for a fix for this problem?
-hojtsy-

 

I'm working on 1.2.1.8 and it is nearly ready (it's only hours away - I am going to test this really well before I release it). It will have the following new features (many in response to requests above) :-

1) The top panel can now handle filenames, and it will monitor these for changes in the attributes, date-timestamp, and size. When you are on a filename instead of a registry key, the Regedit button becomes an Explorer button, so you can "visit" the file in Windows Explorer, and the Subkeys button becomes a View File button. They change back when you cursor onto a registry key.

2) A configuration file that stores everything (refresh rate, window positions and sizes, prompt accept or reject setting, and the last line you were on in the top window) is now in place, giving the whole app a "sticky" feel.

3) When there is a registry key value change alert, there is an extra option to the usual Accept/Reject choices. It is "Comment Out Key", and it will put a # sign in front of the key (#-prefixed lines in the top window are regarded as comments), accept the change, and report what it did in the log. Subsequent checks skip this commented-out key (and any other lines that start with #, for that matter).

4) There is now a facility to add names of certain values to an exemption list, so that all values for a key, except these ones, are checked. This enables values like "Window_Placement" to not be checked, while the rest of the values are. These can be edited and saved by right-clicking the "Log" button.

5) Lots of improvements to the user-interface, even though it looks practically identical to version 1.2.1.7. For example, when an alert pops up, the top panel will now highlight the key causing the alert, enabling much easier Regedits to get rid of added subkeys.

Testing is going rather well, so it may well be available tonight (about 10pm GMT). Thanks for your input everyone - invaluable as always.

 

Version 1.2.1.8 is now available for download from http://www.jacobsm.com/index.htm#sft

IMPORTANT : The Zip file contains a file MJRegWatcherKeys.txt
When you unzip it, it will want to overwrite your current file. If you have important keys in there, save them somewhere else first, and let this replace the current one, since it shows how OS-generic filenames can be specified. Then add your special saved keys to this new one.

Changes 1.2.1.7 to 1.2.1.8
1) The top panel can now handle filenames.
2) There is now a configuration file that stores refresh rate, window positions and sizes, prompt accept or reject setting, and the last line you were on in the top window.
3) When there is a registry key value change alert, you can accept the change and comment out the key, by pressing a new "Comment Out Key" button.
4) There is now a facility to add names of certain registry values to an exemption list.
5) Lots of improvements to the user-interface, even though it looks practically identical to version 1.2.1.7. For example, when an alert pops up, the top panel will now highlight the key causing the alert, enabling much easier Regedits to get rid of added subkeys.

I must admit, I'm feeling safer already

 

Graphic - Latest version is again a hit. I'm not experienced enough to know what subkeys to add, why to add them, or when to add them. But the other functionality is really nice. Thanks again, and keep up the great work! It is much appreciated.

 

@Graphic- Thanks is such an inadequate word but -- THANKS! Arigato. Gracias.

By the way, Paranoid2000 has a comment for your benefit back at the other thread at post #243 at HERE.

Paranoid2000 is one of my favorite gurus. I'm happy to see he is taking an interest in your superb RW.

 

Hi Graphic EQ,

RegWatcher is a wonderful piece of software. Thank you for the quantity, quality and generosity of your work.

I did have one minor glitch which isn't RW's fault, but perhaps you (or others) have some feedback. RW was fine when I logged in as Admin (Win2000-sp4), but when I logged into a "User" account, it quickly popped up with all of the existing entries in my HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run key. It insisted (erroneously) that all of the entries were new, and it stood ready to allow or deny these "changes". I discovered that this happened because the security on the HKLM-Run key was set as read-only for "User" accounts. I changed the key's permission for "User" to be read/write, and now MJRW starts without complaint and detects both changes and non-changes correctly.

First, though, I tried to solve the problem by having startup invoke MJRW with "runas admin". It ran without problem, but then I realized it was showing the HKCU/startup data for my admin login (doh!). Not counting MJRW, I do usually have an admin task running (ksh shell and/or ProcessGuard GUI). Does starting a trusted app with "runas admin" open a hole in my security? What about the need to monitor multiple HKCU and HKEY_USERS locations?

Now, I'm pondering whether or not to keep the new read/write HKLM-Run key policy in place. I'm inclined to leave write permission for "User" on all registry keys that I want to protect because (in my opinion):
1) As a restricted "User", running fewer applications with admin privilege increases my security.
2) I'd rather be aware of what's happening than blindly trust restrictions to provide adequate protection.
3) MJRW's undo-until-approved policy increases my confidence enough to make this small allowance.

My first assumption may be highly over-simplified or even dubious. I'd really like to know if others place much value on not having admin privileges for everyday usage. Perhaps I'm just not proficient at working through some of the complications that a restricted user can encounter.

Thanks again,
Mike

 

Mike, MJRW reads all its keys in read-only mode. It only requires update access *WHEN* a change occurs. Perhaps something is wrong with Win2000 SP4 registry access to read-only keys is actually *DENIED* instead of read-only.

 

Graphic, Is this the first time you've had a report of all values for a key being perceived as new at every startup? Before MJRW, I was using Mike Lin's StartupMonitor which seemed fine from the "User" account. Maybe this is just something bizarre.

 

I'm wondering whether MJRW forming its list of values and subkeys when it starts, is actually occurring before Windows 2000 can copy the new values across to the key from the HKEY_USER branch (which is what it does when you logon as a different user). So, I could rewrite MJRW to not form the list until it has been running for 2 seconds. To test this theory, I have put a zipped version of the revised MJRW .exe file at http://www.jacobsm.com/rwtest.zip . Could you please try it and let me know if it solves the problem? TIA.

 

Graphic, After removing write permission for User logins from HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, RW v1.2.1.7 still flags everything in that key as newly added. When I switched to the test version (rwtest.zip), RW began flagging the keys as newly added every 5 seconds. It didn't stop until I exited the program. Finally, I downloaded and tested version 1.2.1.8, which behaves the same way as v1.2.1.7 (flagged new at startup only).

Since this is an HKLM key, would there still be a startup timing issue, or does that only apply to HKCU? In any case, this must be related to something else, because I get the same results when I exit MJRW and restart it the from a command line.

 

I just want to add one more thought. If you think it's important to solve this mystery, I'm more than happy to help. OTOH, I don't want to sidetrack you if this is just anomalous behavior on my system.

Do you have any idea whether many people are using MJRW from within restricted accounts? Do you know whether or not HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run is commonly write protected from restricted accounts?

 

It is strange that you experience different behaviour from versions 1.2.1.8 and the rwtest zip supplied earlier, since they are exactly the same, except for the delay at startup. In terms of code added to turn 1.2.1.8 into rwtest, I simply added one statement - Sleep(2); so why one should alert only once, and the other continuously, I don't know. However, if you have denied write access to the key, this would explain the alerts - they happen because MJRW tries to write the original key back *BEFORE* it puts up an alert box. If the write is unsuccessful, the alert box is still put up on the screen. If accepted, MJRW tries to restore the changes to the key (even though it doesn't need to). That write will also fail, but the comparison array is set to what is now there, and further alerts should not occur. The only thing I can think of is some other program constantly refreshing the HKLM Run key with what is there at boot up, by clearing whatever is there and rewriting the entries, and this program must therefore have *WRITE ACCESS* to the key. Could it be the OS itself, refreshing the key periodically, because of the security setting on it? You'd have to hook the RegNotifyChangeKeyValue event to find out.

Exactly how are you starting up MJRW? Could you try not auto-starting it up, and do it manually, after switching to a user account? What happens if it is started manually? Does it work properly? If so, it may be timing issues, but the rwtest version had a 2 second delay after going to the tray, where it does nothing, and lets the system continue starting up. If it still goes wrong after starting manually, I'd like to dig deeper into this issue. Perhaps giving MJRW a command line switch to specify the delay before activity after starting, so you could experiment with different settings...

I start RegWatcher from my user startup folder, so whether it starts is based on which user signs in. I hope some of the questions and suggestions help. Let us know, thanks,