MJ Registry Watcher

Graphic,
3 suggestions below

#1 :

Another thing that would be good is to add a lockdown mode

1. A user interface lockdown so that existing settings cannot be changed. Then require a password to be entered to allow changes
2. When the interface is locked give an option to change the behaviour for alerts (and restore the default setting when unlocked). Normally we may have it set to prompt and in lockdown it might be desirable to have reject

#2:
Allow alerts to be logged into the system event log (as well as your logfile)
This would make it easier for those of us that have things that monitor the eventlog already...

#3:
A little suggestion that would be a cool way to turbo-charge MJRW would be to give it the ability to add an additional watch to detect hidden keys (with a different scan frequency and for selected keys)
A nice little app called unhackme has been produced that does something like this, have a read of this post where it gives a brief description of what unhackme does, basically it looks up registry keys outside of the usual API path to check for hidden entries, smart idea....
It would be v.nice to have this in a freeware tool, especially one where the keys being watched are totally configurable by the end users
Being a commercial app I expect that unhackme will probably evolve into something more than what it is today, it would be great if your program could cover the basics of this style of checking as well

 

Sorry, Graphic, I thought you were saying that that kind of entry/response is currently functional in v1.2.3.4. I think, now, that you're saying you can change it to work that way in the next version. It would certainly be a helpful addition. In the case of a startup directory, would it also alert when a new file is added?

Thanks for the clarification. I didn't realize you were seriously proposing that it may be feasible to monitor a directory like C:\Windows, even on an alert-only basis. While it might be overkill for most systems/users, it certainly creates very interesting possibilities.

I agree that if rollback protection should ever become a configurable feature, size of the protected data is definitely a limiting factor.

 

Gottadoit, I have looked at UnHackMe and I think I can see where it is "getting off". In MJRW, there is already a registry branch backup feature, which uses the same format hive files (.reg files). Are you saying that these can contain hidden registry keys that are now visible in these files, albeit somewhat encoded, but not visible from the Windows API? If so, then we could prefix keys we want to protect using this method (rather than the Windows API method of retrieving keys and values from the registry) withan ampersand sign & so we would have :-

# - commented out
! - reject when in prompt mode
= - accept when in prompt mode
& - use hive checking instead of Win API to retrieve data

If you use &, the best I can do to report any differences encountered, is to file compare the recognisable textual parts of the hive. This would also mean that it could either leave the change, or restore the entire hive for the protected branch. But that'll probably be OK in most instances.

As for event logging, which category should the alerts go into? Application, Security, or System? Currently, I have 63, 0 and 2008 events in each respectively.

Earth1 (or perhaps I should call you Mike, me old matey!), the directory protection mechanism would alert on any change to the protected folder, including a new file added, an old one deleted, or a file renamed, or a file's attributes changed. It could be made to detect added or deleted subdirectories, but do we want that? If we do, that'd be easy. Please let me know what you think. I don't think it should recurse subdirectories, but you may have other ideas.

I've already started 1.2.3.5 and the new (heavy) key sets are done. Now the new features...

 

Hi Graphic, I've answered to so many things, and matey sounds better than most. Just wanting you to know that your efforts are very personally appreciated.

The directory alerts sound very good indeed. I, too, think that monitoring files is the most important thing. I doubt full recursion would be used much, but there may be times when first level subs are of interest. If it's easy enough and you want to add that, you could monitor for subdirectories as:

Code:

c:\watchDir\???      or      c:\watchDir\*

Files in watchDir could be implied by the above, or could be monitored separately via the entry:
c:\watchDir\

... but I still can't figure out how you avoid the 3-question-mark emoticon

 

Hi again,
Using your new method of describing CPU usage (seconds of CPU/hour) I've discovered my system shows a marked increase when switching to the new (heavy) key list. My AMD XP-1700+ requires about 6-7 sec/hour when monitoring the new list. When I switch back to the MJRegWatchKeys.1 list that was originally included with RegWatcher.zip v1.2.3.4, the CPU usage drops to under 0.2 sec/hour. It seems the new list has caused more than a 30-fold increase.

The coverage stats did increase under the new list, but not _THAT_ much.
New List: 1440 values (165K) and 1316 subkeys (15K)
1.2.3.4 List: 1137 values (92K) and 750 subkeys (9K)
Both were clocked several times "runas" admin using the same throttle settings (10ms & 3 lines per throttle).

My system is still very responsive, so I tried stressing the system. With the CPU maxed out (but no registry intensive apps) I found that MJRW was using about 18 sec/hour (new list) and the system remains responsive. I think that performance under stress is _greatly_ improved over "pre-throttle" days. I don't sense a problem here, but perhaps a surprising trade-off. Thought I'd check to see if you're suprised.

 

Is there anyway to run MJ registry watcher has a service?

I'm thinking of following the procedure here http://www.haxial.com/faq/auto-startup/mswinservice/ but it would be better if there was a built in method like that in javacool's filechecker then using a hack.

 

Services require the bare minimum of UI and user interaction. A service should never "pop up" with anything, so I would not recommend this. Plus, there is no advantage in doing so.

 

Firewallls and anti-viruses usually run (partially) as a service. Yet both of them display pop ups. The benefit of running as a service is more access rights for the software (which is not needed by RegWatcher) and a minimal level of protection from termination (not that relevant). So I agree that RegWatcher would not profit from beeing a service.
-hojtsy-

 

Earth1, the heaviest keys in the new set are :-

hkey_local_machine\system\\services\\imagepath

hkey_local_machine\system\\services\winsock2\parameters\\\\packedcatalogitem

These two are crippling in that, with them in, I get 255K of values, and without them, I get 56K of values. Getting values from the registry is where the CPU work is mostly done, so this is why the new set is 5 times heavier on the processor! However, it has always been a dream of this forum that all service image paths could be protected, and that TCP/IP sockets were untamperable with. This is the price we have to pay to get that security. Mind you, it isn't bad on 1GHz processors and up with a 10ms throttle and 3 lines per spark.

Now, as for the not appearing as smileys - that's right the question marks - that's the one the yup ooyah ha ha ha - I'll tell you how when 1.2.3.5 is released. I have only got to implement the "&" prefix for keys that have the extra protection of a hive export comparison, so that hidden registry entries (as commonly made by rootkits) can be discovered. Yet more CPU to your elbow! I would use this one sparingly. Everything else is ready to go, so it won't be long now. Directory protection is marvellous, but c:\windows\system32 is a trifle heavy on cpu usage (peaks at 100% as it gets information on all 2,000 files).

 

I hope you include them only into the Highest set.

I don't think that RegWatcher should attempt to fight rootkits. It is not low level enough to do that. This hive exportation trick is just temporarily working, rootkits could cover this hole in a short time. I have better tools to fight rootkits (such as Process Guard) and would rather not waste CPU on this. Let RegWatcher only do what it is made for.

Again something you could not afford on a ususal system. Checking of c:\windows\system32 changes should rather be on-demand. And tools for that already exist.

-hojtsy-

 

Hojtsy, it seems that you know something about rootkits that I don't. Are you saying they may be able to change the output of regedit /e ? I know they can hide registry entries, files, and even fool task manager into thinking that they are not running, even making free memory seem more than it actually is, for extra stealth. If ProcessGuard does the job, and does it a lot better than MJRW can, then I doff my cap to it. However, for those of use not rich enough to buy PG, then MJRW with the "&" prefix on a key, could do a rudimentary check. Without the "&", it would not do these checks and therefore not waste CPU, as you mentioned before. Hive checking will be entirely optional.

I will follow your advice about commenting out the 2 heavy keys from all lists except the High and Highest sets. People can always put them into their custom set if their PCs can handle them (and most can - my 2.8GHz P4 HT uses 2 seconds per hour CPU for MJRW on the highest set).

As for directory protection, c:\windows\system32 was not meant to be a serious suggested directory to protect. I was more thinking of Earth1's suggestion to protect all startup directories, regardless of user name, so an example directory protection key (which will be in all key sets by default for the next release) is :-

%bootdrv%Documents and Settings\\Start Menu\Programs\Startup

One more thing - should I offer the options (perhaps only in Prompt mode) to delete added subkeys, or delete added files or directories? Values are already restorable, but this is the best I can do for the rest. Whaddya fink?

 

Of course. Just to mention one thing they could replace regedit.exe. (possibly after disabling the file protection). Or they could hack the file system access in the kernel so fake registry hive file is returned into the real regedit when it accesses the hive file. Or they could patch regedit.exe in the memory when it is loaded. And the list goes on and on. Currently rootkits may not be doing these things, but there will be new versions. None of this can be stopped by RegWatcher, and all of this can be stopped by a proper application sandbox, such as Process Guard for example. In summary I don't think this `&` feature would have much use in the long run.
-hojtsy-

 

Graphic, Thanks for the info on which new keys are CPU intensive. I wonder if there are other keys that might fall into the category of "May be too extreme for a system with few cycles to spare and/or is seldom/never on the internet". My laptop and development systems each qualify somewhat differently.

I would be inclined to vote for making delete available in each of these cases. Better yet, perhaps, additions could be rolled back preemptively. Files could be moved (or copied/deleted) until approved. Registry keys would need to be copied/deleted until approved. If approved, the change is copied or moved back into place.. For files, move may be preferable to copy (eg. move to /RegWatcherHold) because it's not only faster, but avoids the possibility of exhausting disk space. Of course, this still wouldn't address every kind of rollback (eg. deletions) and it may be overly cumbersome to implement.


Now that MJRW is acquiring some fairly esoteric (and expensive) capabilities, I'd like to revise a suggestion I threw out a while back regarding multiple frequencies. When gottadoit suggested an "unhackme-like" ability to detect a rootkit hiding certain registry keys, he also mentioned that it would probably be better to do that with less frequency. Other possibilities, like checking system32\drivers\ every 30 minutes, spring to mind.

My idea is still to use multiples of the fundamental monitoring frequency so that you won't need to set additional timer interrupts. The new twist is to specify the slower (multiplexed) rate as an entry in the key-list file. The list would be interpreted normally until encountering a line like:
@frequency=60
... after which, the keys/files/directories that follow would be skipped 59 times, then checked once, skipped 59 times, and so on. Assuming that the basic monitoring frequency is every 5 seconds, the subsequent entries would be checked every 5 minutes. If MJRW could support multiple @frequency rates, then large jobs could be fairly effectively staggered by using different prime numbers.

Of course I don't know how easily the new logic could be integrated. It probably entails converting at least one list/array structure into groups that share a common "multiplexing count", then adding an outer loop to step through each group. If this is possible, it may allow MJRW to be used in more flexible and diverse ways. Just food for thought.

 

Right, last call before 1.2.3.5 is released. When MJRW is put into "Reject" mode, should it automatically "Quarantine Added Files" and "Quarantine Added Subkeys"? At the moment, the version 1.2.3.5 that I have ready only allows these 2 functions when in "Prompt" mode. If "Reject" mode should undo as much damage as possible, then should MJRW change from "Reject" mode to "Prompt" mode, as soon as it is interacted with? Or should it use Quantum Physics to establish whether the PC is being scrutinised, and go into Prompt mode automatically. When you leave the PC, it goes into Reject mode automatically! (Just joking about the Quantum Physics!!)

 

Sounds like you're keeping busy. To be honest, I haven't used Reject mode much yet, but my confidence is growing enough that I'm considering it. Anyway, if my reasoning sounds suspect, I've probably misunderstood something.

I think the most important feature of Reject mode is that it can keep up with a series of changes. So long as Prompt mode can't stack a series of "undone-pending" changes, then Reject mode remains the ultimate protection. If it's possible to send out an alert without interrupting Reject mode's ability to keep protecting, that could be a very good thing. If sounding the alarm interferes with Reject mode's protection, then maybe not. I might change my tune, though, if I install a few hotfixes with MJRW in reject mode.

Quarantine data (with the log file) could make it possible to recover from a minor "forgot to turn it off" lapse. It might also help determine, after the fact, whether an attack had been attempted and what kind it was. On the other hand, it creates some extra housekeeping. I think it sounds worthwhile, but I may be in the minority.

 

Same here. I am using Prompt mode only, so it is not that important for me to see any new features in Reject mode.
-hojtsy-

 

Thanks very much to Graphic for the superb MJRW, and to Hojtsy and Earth
for their valuable contributions.

I leave it on Reject mode and Highest on my 98se but now I am wondering
if you guys believe that to be a bit too full time fierce.

It might be an idea to ask you all, when should one need to allow
fiddling about in the Reg. ?

I can understand that MJRW needs to be OFF when installing a new program,
and maybe ?? when receiving a AV or Anti Spyware Update, can you please say if there might be other situations to consider before allowing full time Reject ?

TIA,

Kind Regards.

 

Hi, MICRO, thanks for asking some good questions. I'm definitely not your best registry authority here, but if I say something dumb, somebody else should be all over me soon. Also, I have no experience with Win '98, so some of my comments may not apply to your system.

As I start to use Reject mode more, I think I'll still switch to Prompt mode when I anticipate uncertainty. For instance, program installatiions of software not yet on my "trusted list". If the installer tries to make a suspicious change, you can still reject it. More importantly, you're now aware of the suspicious activity. Alternatively, with Reject mode, just remember to check the log for suspicious entries.

I'd also recommend spending enough time in Prompt mode to have a sense of what is being rejected and when. The log file lists each change, but you'll get a better feel for the cause and effect by seeing it happen in Prompt mode. It may point out certain values (in a sensitive key) that do have valid and harmless reasons to change. My goal for optimal settings would be to allow nothing dangerous, but reject as little as possible.

My best guess is that, so long as your AV/AT/AS is just doing a signature update, there is no need to turn off MJRW. Even if an executable is updated, it will likely use the same registry startup invocation. I would suggest using Prompt mode, so you can test whether this assumption is true. That way, if you accidentally do an update in Reject mode, you'll have some idea how likely it is to have caused a problem.

I am inclined to turn off MJRW when I'm installing something that I trust. MJRW's pre-emptive, one at a time rollback can leave the registry out of sync during an install. For instance, the installer has updated the registry with a dozen keys/values, but the fourth update has been reversed by MJRW. After you answer MJRW's prompt, the fourth update suddenly comes back into sync, but the seventh update goes out of sync a few seconds later. Most installations will probably survive without a hitch, but I'd rather not keep testing the possibilities. In general, I think, factors that increase the likelihood of MJRW inadvertently interfering are:
#3) Larger program
#2) Low-level nature of program
#1) Any program written my Microsoft

My pick for most crucial time to turn off MJRW would be when installing Microsoft service packs or even hotfixes. Many times, updated files cannot be changed until Windows is restarted. Swapping out critical system files is controlled by MJRW-protected registry entries that Windows will read at the next boot. Those entries tell it to swap a new file for the old one while the system can still do so. If you reject that registry update, you could, conceivably, get part of a hotfix installed without getting the rest of it. Installation (or version updates) of security software also seems like a good time to turn MJRW off. Of course, installing security software that you're not yet sure you trust is a always a paradox to be avoided.

These are my main conclusions at the moment, and the logic I used to get there. I hope there are more opinions forthcoming, because I'm struggling my way through this learning curve too.

 

Thanks for listening!

And thanks to Earth1 and hojtsy for refining the idea!

Excellent!

I assume you've added auto-reject (and auto-accept) buttons to the prompt dialog much like the way there is a button for auto-comment? If not... then there's an idea.

Sira

 

Sira, buttons for prefixing the keys with ! and = sounds like a good idea. Good job I didn't release it last night.

Earth1 and MICRO, I adopt the following practice for MJRW use :-

If I am away from my PC but it is on and/or connected to the net, I leave it on full-time auto-reject. Any additions to subkeys and files/directories will be auto-quarantined, so, you can get the changes back if necessary.

If I am at my PC, and *NOT* installing software or hardware, then I switch it to Prompt mode.

If I am at my PC, and *I am* installing software or hardware, then I switch it to Accept mode.

It really is as simple as that. Keep your eyes peeled tonight, because version 1.2.3.5 will be released. There are just 2 changes left to implement :-
1) Buttons to allow prefixing with ! and =
2) Exemptions support (probably in the subkeys exemptions file) to allow certain filespecs to be exempt from checking. I noticed %windir%tasks causes an alert for any task the scheduler runs, since it records the date/time of the last run on the timestamp of the file defining the task.

MJ

 

Graphic,
Please include the new key:
hkey_lmus\software\microsoft\windows\currentversion\policies\network
See this post.
-hojtsy-

 

Graphic,
Firstly sorry about the delay in replying

For the event logging, I'd probably put it into Application, but if you could make it configurable then I'm sure that everyone would choose something different

That wasn't what I was meaning (or what I understood the unhackme behaviour to be). My understanding was that it basically read and parsed the binary data files that contain the registry and compared the information found with what is visible using the API interface

Its not a 5 minute addition and the malware writers probably will eventually intercept file access to the file and give back binary data to hide what they have done, so hojtsy is probably correct in his evaluation that it isn't a long-term useful feature to have as it will probably become redundant at some point

Thanks for considering it, it may well still be a useful addition - if I can find some code that reads and parses the raw registry file it would reduce the time and effort for you to add it in

The hive checking idea on exported registry files has interesting uses...
Consider a small/medium sized environment where you want to check that certain specific startup entries don't get deleted... keep the .reg file on a fileserver share and have mjrw check it every few hours
That would require the "&" entries to have their own mode so that they can be put in place in spite of normal user interaction, and that in turn requires password protection so that malware couldn't use this feature to attack a user with mjrw installed

 

Graphic,
Another little question for you and this is related to how you are accessing the registry at the moment. Do you use the Win32 API or the Native API ?

If you are using the Win32 API then there is potential for keys to be created that you cannot access
Have a read of Hidden Registry Keys? on the sysinternals site

Regards

 

Version 1.2.3.5 of MJ Registry Watcher is available at http://www.jacobsm.com/index.htm#sft

It has a greatly improved help file, and these new features :-

Changes 1.2.3.4 to 1.2.3.5
1) Now recovers gracefully from failed key writes.
2) Options to turn the alert sound off, and to change the WAV file used.
3) Directories protection implemented.
4) Added %bootdir%documents and settings\\start menu\programs\startup to all sets.
5) Implemented prefix support for :-
! - reject when in prompt mode
= - accept when in prompt mode
& - use additional key checking / slowed down filespec checking
6) Now prompts when manually closed.
7) When a change is made to the top window, checking is suspended, until the changes are saved, and the checking loop manually restarted.
Quarantine implemented.
9) %windir%tasks added to all lists.
10) Split off settings menu items into a separate submenu.
11) Added key hkey_lmus\software\microsoft\windows\currentversion\policies\network to all sets.
12) Corrected bug with subkey additions.
13) Added buttons to support quarantining additions and various other functions.
14) Many other refinements and improvements.

Sorry I couldn't implement everything, but I felt this was enough to warrant a new release.

I am not at liberty to divulge my registry and file/directory access methods, since, the alert in the bottom panel of the screen snapshot at http://www.jacobsm.com/index.htm#sft probably means I'm in trouble already! Bear in mind the snapshot was taken when I had just rebooted the PC and wasn't yet on the net. Does anyone know what this LSA stuff means?

Here is a funny thing. If you set MJRW to protect its own log file, and then put it into auto-accept or reject mode, you'll get an alert every sweep! Great for testing your audio alert snippet

 

Graphic,

It does not appear to be anything untoward -
LSA = Windows Local Security Authority

I Googled the controlset002\control\lsa
and there were 3 or 4 clues to it being windows files, and a mention of
Win.Media Player.

Then with msv1_0 it's apparently a .dll file and they refer to
a, ' subset of replicated data '.
Not much help.

Thanks for the guide on Reject - Prompt - Accept.

Kind Regards.