Locked reg key

  • Thread starter Thread starter Alex Clark
  • Start date Start date
A

Alex Clark

Hi all,

I've just cleared load of viruses off a friend's laptop but I've got an odd
problem with the registry. There's a reference to one of the infected files
I deleted in there in a couple of different places - one is in HKCR\CLSID,
the other is in
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper
Objects\, but both are thoroughly locked.

The machine is XP Home, but I can see the security tab. I tried rebooting
into safe mode, I still cannot delete either of these keys. I tried to
alter the security permissions, take ownership, change effective permissions
etc, it gives me "Access Denied". I used a utility from Microsoft called
"psexec" to launch Regedit under the SYSTEM account to see if I could
override privs that way, but still no luck.

Other keys under the same parent keys will allow me to edit them just fine -
it's just these two keys that are locked out.

My assumption then was that some process was still running that had a lock
on these registry keys. A bit disturbing as that could only be a malicious
process, but a full antivirus scan in both safe mode and normal mode brought
up nothing but a few tracking cookies.

I tried the SysInternals Process Explorer tool to see if I could find any
process which had an open handle to those registry keys. Again, nothing.

So I'm running out of ideas as to why these keys should be locked at all.
I'm a software developer and *I* can't come up with a reasonable
explanation, other than a rootkit - I would actually love to know exactly
how this has been achieved, because it's baffling me!

Thanks,
Alex
 
Hi Alex Clark,

Open Regedit. Find the key you want to delete. Go to the Parent Key.
Right-click on the Parent Key and click Permissions.
 
thecreator said:
Open Regedit. Find the key you want to delete. Go to the Parent Key.
Right-click on the Parent Key and click Permissions.
Click to expand...

Nope, tried it and it doesn't work - I tried to get permissions to propagate
down to all child keys from that parent key, but it warns me that
permissions could not be set on some sub-keys. I've literally tried forcing
a brand new set of permissions (and ownership) on the entire root key (i.e.
HKCR and HKLM) but it gives me that same error - when I check, it turns out
that it's these culprit keys which still won't take the permissions. :-(
 
Hi all,

I've just cleared load of viruses off a friend's laptop
Click to expand...


If there were truly a "load of viruses," it's very likely that you did
not successfully clean everything. The one time I am almost always in
favor of doing a clean reinstallation of Windows is when there are
multiple infections. Anything else is unlikely to fix everything
that's wrong.
 
Kelly,

Don't have access to the exact CLSID right now but my understanding is it's
a different CLSID on every machine that this particular little gem of a
virus installs itself on. The registered class' InProcServer references
"C:\Windows\System32\cabvie.dll", which was a virus. I had to use recovery
console to successfully rename that file - it was locked the same way as the
reg keys are now - and then after a successful boot into normal mode, I
could delete it.

The BHO key's name matches the CLSID and again references this file - which
no longer exists.

I'm currently using the Recovery Console to try and remove these registry
keys, but with no success. My understanding from what I've seen on the
interwebs is that the command line tool, reg.exe, should work in the
recovery console - it doesn't thought :-(

Anyone know why I can't use reg.exe command line tool from Reco-console?

Thanks,
Alex
 
Hi Alex,

Most you can rename starting with the .dll. Once done, you can delete each
folder level.

Editing the Registry

The procedure described above works by changing an entry in the Registry. If
you are familiar with Registry editing, direct editing is another route and
it has the advantage of being available to those with the Home Edition of
Windows XP.

Open regedit and find HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Setup\RecoveryConsole\. In the right pane, this key will
have an entry "SetCommand". Put a value of 1. This is shown in the figure
below. Be sure to back up the Registry before doing any editing.

http://commandwindows.com/recovery.htm



--

All the Best and Happy Holidays,
Kelly (MS-MVP/DTS&XP)

Taskbar Repair Tool Plus!
http://www.kellys-korner-xp.com/taskbarplus!.htm
 
Kelly,
Most you can rename starting with the .dll. Once done, you can delete
each folder level.
Click to expand...

Yeah that's already gone, it's just these two reg keys that are completely
locked and un-removable.
Open regedit and find HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\Setup\RecoveryConsole\. In the right pane, this key will
have an entry "SetCommand". Put a value of 1. This is shown in the figure
below. Be sure to back up the Registry before doing any editing.
Click to expand...

Already did that to give me a bit more power in the reco console, for all
the good it did.

Unfortunately, the reg.exe program is not available from the recovery
console prompt. Quite how MS expect you to repair Windows from the RC when
you can't even use basic registry editing commands is beyond me.

Looks like my choices are to either leave it alone, or start messing with
specialised boot CDs to try and access the registry from a different
environment. Woohoo.

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

| Hi all,

| I've just cleared load of viruses off a friend's laptop but I've got an odd
| problem with the registry. There's a reference to one of the infected files
| I deleted in there in a couple of different places - one is in HKCR\CLSID,
| the other is in
| HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper
| Objects\, but both are thoroughly locked.

| The machine is XP Home, but I can see the security tab. I tried rebooting
| into safe mode, I still cannot delete either of these keys. I tried to
| alter the security permissions, take ownership, change effective permissions
| etc, it gives me "Access Denied". I used a utility from Microsoft called
| "psexec" to launch Regedit under the SYSTEM account to see if I could
| override privs that way, but still no luck.

| Other keys under the same parent keys will allow me to edit them just fine -
| it's just these two keys that are locked out.

| My assumption then was that some process was still running that had a lock
| on these registry keys. A bit disturbing as that could only be a malicious
| process, but a full antivirus scan in both safe mode and normal mode brought
| up nothing but a few tracking cookies.

| I tried the SysInternals Process Explorer tool to see if I could find any
| process which had an open handle to those registry keys. Again, nothing.

| So I'm running out of ideas as to why these keys should be locked at all.
| I'm a software developer and *I* can't come up with a reasonable
| explanation, other than a rootkit - I would actually love to know exactly
| how this has been achieved, because it's baffling me!

| Thanks,
| Alex

I'll lay a bet that *NONE* were viruses. All that were removed were trojans.

I'll lay another bet that the system is still infeced as noted by your mentioning of
BHO's.

Chances are you have Vundo and/or Conhook trojans and the registry entries aren't "locked"
they are protected by the loaded malware.

They are protected by the DLL loaded in BHO also being loaded in other locations such as
Winlogon/Notify.

I don't know your expertise so I'm not going to give you manual instructions using the
Recovery Console at this time.

For now I suggest using Malwarebytes Anti-Malware
http://www.malwarebytes.org/mbam/program/mbam-setup.exe
 
Alex said:
Hi all,

I've just cleared load of viruses off a friend's laptop but I've got an odd
problem with the registry. There's a reference to one of the infected files
I deleted in there in a couple of different places - one is in HKCR\CLSID,
the other is in
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper
Objects\, but both are thoroughly locked.

The machine is XP Home, but I can see the security tab. I tried rebooting
into safe mode, I still cannot delete either of these keys. I tried to
alter the security permissions, take ownership, change effective permissions
etc, it gives me "Access Denied". I used a utility from Microsoft called
"psexec" to launch Regedit under the SYSTEM account to see if I could
override privs that way, but still no luck.

Other keys under the same parent keys will allow me to edit them just fine -
it's just these two keys that are locked out.

My assumption then was that some process was still running that had a lock
on these registry keys. A bit disturbing as that could only be a malicious
process, but a full antivirus scan in both safe mode and normal mode brought
up nothing but a few tracking cookies.

I tried the SysInternals Process Explorer tool to see if I could find any
process which had an open handle to those registry keys. Again, nothing.

So I'm running out of ideas as to why these keys should be locked at all.
I'm a software developer and *I* can't come up with a reasonable
explanation, other than a rootkit - I would actually love to know exactly
how this has been achieved, because it's baffling me!

Thanks,
Alex
Click to expand...

What does "locked" mean? That you cannot modify or edit the key name or
its data values? From other subthreads, it appears you already checked
permissions on that registry key to ensure you are allowed to
modify/delete it. So perhaps the problem is that a null character was
used in naming that key. regedit parses on strings but the rendered
strings may not match the actual names. regedit won't show null
characters, so something like "protected<null>key" looks like
"protectedkey" to you and to regedit (when it attempt to read that key).
You can use SysInternals' RegDelNull utility to get rid of registry keys
that incorporate a null character within them.

http://technet.microsoft.com/en-us/sysinternals/bb897448.aspx

This technique of inserting null characters into registry keys is not
solely used by malware. For example, many games use SecuROM to copy-
protect their CD from being copied, and SecuROM puts some entries into
the registry using the null character to ensure the user doesn't
accidentally delete them and render the game unusable. When you're done
with the game, you could use the RegDelNull utility to let you delete
those keys (of which some are the license keys for you to use the game
but you don't need them if you uninstalled all those games), or you
could use SecuROM's own uninstaller utility from their site to delete
their protected keys (except they will leave behind the license keys in
case you reinstall the game).
 
I'll lay a bet that *NONE* were viruses. All that were removed were
trojans.
Click to expand...

Have to point out, "trojan" is simply one variety of a virus. That's like
saying "I'll bet that was a Taurus, not a Ford"...
I'll lay another bet that the system is still infeced as noted by your
mentioning of
BHO's.
Chances are you have Vundo and/or Conhook trojans and the registry entries
aren't "locked"
they are protected by the loaded malware.
Click to expand...


AVP8, SpyBot S&D, and Windows Defender report it as clean. This is why I'm
concerned that a rootkit has been installed, not an average trojan virus.

They are protected by the DLL loaded in BHO also being loaded in other
locations such as
Winlogon/Notify.
Click to expand...

Hmmm, that's unusual, as I thought BHOs were loaded by the shell
(explorer.exe) and IE. Not saying you're wrong, but why would Winlogon need
to load a BHO when it doesn't have a shell as such?
 
What does "locked" mean? That you cannot modify or edit the key name or
its data values?
Click to expand...

Yep, I can read it in Regedit but it won't let me:
Rename the key
Delete the key
Add sub-keys to the key
Change/Delete/Add values into the key
Alter security permissions on the key.
From other subthreads, it appears you already checked
permissions on that registry key to ensure you are allowed to
modify/delete it. So perhaps the problem is that a null character was
used in naming that key. regedit parses on strings but the rendered
strings may not match the actual names. regedit won't show null
characters, so something like "protected<null>key" looks like
"protectedkey" to you and to regedit (when it attempt to read that key).
You can use SysInternals' RegDelNull utility to get rid of registry keys
that incorporate a null character within them.

http://technet.microsoft.com/en-us/sysinternals/bb897448.aspx
Click to expand...

Now that is interesting, and I wasn't aware of it. I'll try this, thanks
:-)
 
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.

RootKitRevealer hasn't "revealed" anything that appears to be a rootkit
though, and all other AV scans show that I'm clean. It's just this stupid
reg key that won't unlock itself, which is making me paranoid.

Thanks,
Alex
 
| Have to point out, "trojan" is simply one variety of a virus. That's like
| saying "I'll bet that was a Taurus, not a Ford"...

Actually... No.

Trojans and viruses are both variries of malware. Viruses self replicate. Trojans do not
and need "assistance" through such methodologies as the vulnerability/exploit vector and
Social Engineering. All viruses are malware, not all malware are viruses.


| AVP8, SpyBot S&D,
| and Windows Defender report it as clean. This is why I'm
| concerned that a rootkit has
| been installed, not an average trojan virus.

They are most likley wrong.


| Hmmm, that's
| unusual, as I thought BHOs were loaded by the shell
| (explorer.exe) and IE. Not saying
| you're wrong, but why would Winlogon need
| to load a BHO when it doesn't have a shell
| as such?


No, Browser Helper Objects are used by IE and Winlogon/Notify is loaded during the logon
process prior to when Explorer.exe (the shell) is loaded. Thus if the DLL is loaded prior
to the Explorer, the Registry entries and the DLLs are already protected. Winlogon
doesn't load a BHO, the malicious actors have programmed their malware to load in a way
that makes it have more than one load point is an effort of self preservation. Now there
are OTHER ways the DLL(s) can be loaded in addition to a BHO besides using
Winlogon/Notify. This way however is very common and quite effective.

Again I suggest MBAM. Unless you know how to use the Recovery Console where you can go to
the folder where the DLL resides (most likely %windir%\system32) and either delete the DLL
or rename it. Then you can find you can manipulate the Registry entries to remove their
loading points. However I would STILL recommend MBAM.
 
From: "Alex Clark" <[email protected]>

| 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.

| RootKitRevealer hasn't "revealed" anything that appears to be a rootkit
| though, and all other AV scans show that I'm clean. It's just this stupid
| reg key that won't unlock itself, which is making me paranoid.

| Thanks,
| Alex

RootKit Revealer, as a anti RootKit utility, pales against Gmer. However protecting a
Registry entry doesn't need a rootkit to be performed.
 
Again I suggest MBAM. Unless you know how to use the Recovery Console
where you can go to
the folder where the DLL resides (most likely %windir%\system32) and
either delete the DLL
or rename it. Then you can find you can manipulate the Registry entries
to remove their
loading points. However I would STILL recommend MBAM.
Click to expand...

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.
 
RootKit Revealer, as a anti RootKit utility, pales against Gmer. However
protecting a
Registry entry doesn't need a rootkit to be performed.
Click to expand...

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.
 
Have to point out, "trojan" is simply one variety of a virus. That's like
saying "I'll bet that was a Taurus, not a Ford"...
Click to expand...



That's not at all correct. Viruses and trojans are both varieties of
malware, but neither is a variety of the other.
 
Have to point out, "trojan" is simply one variety of a virus. That's
That's not at all correct. Viruses and trojans are both varieties of
malware, but neither is a variety of the other.
Click to expand...

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... :-)
 
Back
Top