Locked reg key

[VanguardLH]

Sheesh, even this didn't do the trick - although I'm uncertain as to
RegDelNull's effectiveness here. I ran it on HKCR and HKLM and it
reported no null keys (even with the recursive option enabled). I
then ran RootKitRevealer and that *did* warn me of two keys with
nulls in them inside the HKLM hive, so apparently RegDelNull didn't
do a great job of searching.

I haven't used RegDelNull often enough to become expert in its use. I
do remember that it is picky regarding command-line syntax and
parameters. If, for example, the hierarchical path for a registry key
includes spaces, you'll have to double-quote the string for identifying
that path as a parameter.

If you use the tool correctly and it reports no embedded nul registry
keys then it could be something still left running on your host that is
protecting the registry. Have you yet tried rebooting into Safe Mode
for Windows and then do the registry edits?

I then ran RootKitRevealer and that *did* warn me of two keys with
nulls in them inside the HKLM hive ...

I take it that the registry keys with embedded nulls that were reported
by Rootkit Revealer were not the same ones that you are trying to
delete.

 

[Alex Clark]

If you use the tool correctly and it reports no embedded nul registry

keys then it could be something still left running on your host that is
protecting the registry. Have you yet tried rebooting into Safe Mode
for Windows and then do the registry edits?

Yep, multiple attempts but with no joy. I was hoping the recovery console
would allow me to use the "reg.exe" command line tool, because I'm fairly
sure I'd be able to delete it via the RC, but it wouldn't.

I take it that the registry keys with embedded nulls that were reported
by Rootkit Revealer were not the same ones that you are trying to
delete.

Yeah, they were different. A couple were in some sort of
Software\Security\Secret key, and there were another couple who's data from
the API calls didn't match the raw data on disc - those were part of the
Broadcom 802.11 settings, and as far as I can tell they're legit.

So either there's a fairly sneaky rootkit on there which is evading
detection, or whatever created those keys screwed them up in a very specific
manner so as to prevent regedit from being able to do anything to them. I
did try the command line reg.exe utility under safe-mode command-prompt
boot, but it still gave me errors/access denied.

So, a bit stumped really!

 

[David H. Lipman]

From: "Alex Clark" <[email protected]>


| I already did this before posting here - recovery console was the only way I
| could delete the DLL that these registry entries point to. After I deleted
| it, my virus scans are now coming up negative. The ONLY weird issue
| remaining, as far as I can tell, is a pair of registry entries which are
| thoroughly locked.

| Process Explorer (SysInternals) isn't showing any process with an open
| handle to either of these keys. I just cannot modify them in any way - I
| either get "Access Denied" errors or the wonderfully descriptive "Error
| Deleting Key".

| I've even tried spawning RegEdit under the SYSTEM account using the psexec
| tool, and that didn't help either.

Assuming that the Registry entry that uses the DLL where the DLL has been deleted will not
allow access then it MAY have changed access rights. What you need to do then is give the
account (or adminstrator) full rights to the Registry key.

 

[David H. Lipman]

| Well, semantics aside, it's been a long time since I've heard people
| differentiate a trojan from a virus, particularly as nowadays "virus" is
| synonymous with "any malware on a computer". Back in the days of the fun
| trojans like BO and NetBus there was a distinction, but I wouldn't really
| tell a user "no you don't have a virus at all, you have a trojan". But I
| digress...


Lay people with NO knowlege call anything bad a virus and is totally incorrect. One must
differentiate a virus from other malware because of of self replicating capabilities and
thus requiring additional or altered actions.

 

[David H. Lipman]

| No, but hiding itself to this extent arguably would. As I've mentioned in
| other posts, I've used a couple of process monitoring tools to scan all open
| handles from all processes and *nothing* appears to be locking those
| registry hives. In order to hide from tools like that would by definition
| require a rootkit, either user-mode or kernel mode.

Not true. There is file peering, multiple load points and the removal of access
priveledges to name a few. None of which needs to use RootKit techniques or kernelr level
capabilities.

 

[Alex Clark]

Assuming that the Registry entry that uses the DLL where the DLL has been

deleted will not
allow access then it MAY have changed access rights. What you need to do
then is give the
account (or adminstrator) full rights to the Registry key.

Yep, again, did all this first and foremost - regedit won't even allow me to
alter the permissions on the key. I've tried spawning regedit under the LSA
but it still won't let me (1) alter permissions on the key or (2) alter the
key, its subkeys and its values in any way at all.

That leaves me with:

1) some process has an open handle on that key, and is thus preventing
changes to it. Process Explorer does not show any open handles on this key
however.

2) The key has somehow been corrupted in such a way as to prevent regedit
from being able to write to it.

 

[David H. Lipman]

| Yep, again, did all this first and foremost - regedit won't even allow me to
| alter the permissions on the key. I've tried spawning regedit under the LSA
| but it still won't let me (1) alter permissions on the key or (2) alter the
| key, its subkeys and its values in any way at all.

| That leaves me with:

| 1) some process has an open handle on that key, and is thus preventing
| changes to it. Process Explorer does not show any open handles on this key
| however.

| 2) The key has somehow been corrupted in such a way as to prevent regedit
| from being able to write to it.



What was results after running MBAM ?

 

[thecreator]

Hi Alex,

I read all the posts in your thread. I guess that the fastest way to get
rid of viruses and stubborn Registry Keys is to do a reformat and reinstall
of the operating system.

And that's why I / one moves their Document Folder to a seperate
partition. It makes restoring a Partition Image a snap or even doing a
reformat and reinstall of the operating system, faster than trying to solve
a problem.

Then all you need to be running is a Sync Backup program to sync your
E-mail Store Folder, Favorites, Desktop and AddressBook to a different
backup partition.

 

[VanguardLH]

Yep, multiple attempts but with no joy. I was hoping the recovery console
would allow me to use the "reg.exe" command line tool, because I'm fairly
sure I'd be able to delete it via the RC, but it wouldn't.


Yeah, they were different. A couple were in some sort of
Software\Security\Secret key, and there were another couple who's data from
the API calls didn't match the raw data on disc - those were part of the
Broadcom 802.11 settings, and as far as I can tell they're legit.

So either there's a fairly sneaky rootkit on there which is evading
detection, or whatever created those keys screwed them up in a very specific
manner so as to prevent regedit from being able to do anything to them. I
did try the command line reg.exe utility under safe-mode command-prompt
boot, but it still gave me errors/access denied.

So, a bit stumped really!

There are some registry keys that even administrators are not allowed to
access and only the System account can get at them. The purpose is to
keep you from shooting yourself in your foot and make the OS unbootable.
When you look at the keys revealed by RootKit Revealer and the other
ones you were trying to edit, who is listed as the Owner of them in the
permissions list under advanced settings in regedit?

You could try taking ownership of those registry keys. Or you could use
SysInternals' psexec utility under an admin-level account to run the
registry.exe program under the System account:

psexec -s -i regedit

You can use SysInternals' Process Explorer to see that regedit.exe is
being ran under user = SYSTEM. Then see if you can delete those keys.
You have already backed them up, right, in case they really are needed?
Got image backups, too, in case you can't boot into Windows and need to
restore that partition's image?

Since permissions are probably being inherited from a parent key, did
you ever disable inheriting parent permissions (advanced settings for
permissions) when trying to change them on the keys that you want to
delete? Sometimes regedit doesn't show the permissions changes until
you make then, exit regedit, and reload regedit.