Windows Hidden Registry Keys
Jodee Bouman
A lot of windows hacks and tweaks involve fiddling with the registry. Quite often, it involves adding a new key/value. However, there are times when I'd like to do a tweak and there is no online tutorial.
Just start reading Microsoft Technet and you will find many and more "hidden" registry keys / values. I don't know if there's any list about keys that are not here after clean installation but you will find them after started hacking Windows.
Already noted in comments, you should read more about windows internals and ask more specific question after you have some real problems with finding some special values. I think that if you really need full list of reg keys/values then you should make one (at least partially) yourself, as learning exercise.
Now you got few lines, what to do? If you are lucky values are hardcoded with keys and they can be retrieved from above by looking for record byte sequences and then finding right values. Also you can try to find error messages and their addresses to track down what part of program throws them out (some assembly skills needed but it's not too hard if full reverse engineering/program modification is not requirement).
I'm working with a new property schema, and have been in the habit of checking the registry when I register or unregister a new version. One of the primary places to check this is HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\PROPERTYSYSTEM\PROPERTYSCHEMA.
Anyway, I don't understand how this happens, and whether I should be worried about it. Exporting this key from a colleague's machine and re-importing it can temporarily help, as it will show keys in Regedit that were hidden/missing (even if they weren't on my colleague's machine).
The 32bit program data on 64bit systems available in 'Wow6432Node' folder of the registry (in above case 'SOFTWARE\Wow6432Node\MICROSOFT\WINDOWS...'). This is transparent to the applications, hence you can read data from applications but you don't see that in Regedit.
Harry Johnston's intuition was correct. I re-ran regedit from a command line with the path c:\windows\regedit, and I once again see what I expected under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertySchema. I could've sworn it wasn't showing it either, but it's working now, apparently.
To start off, my friends son tried downloading a free game but was instead blasted with a Trojan.VBS.Autorun.ag, along with Trojan.Downloader.Generic, and some other various adware. There were no security warnings, popups, or indication of infection. The only reason I knew to look for something was because his son called me over to check his other game he was playing out. When he was done, he was on youtube and I noticed an online support tab in his browser which was a huge Adware red flag.
I found a few viruses, removed them, but after searching more, realized the same virus was reappearing in different locations located in the temp dir. Sometimes in the Temp, others in temp\is-H8O4M.tmp
hkey_local_machine software microsoft windows currentversion runto see what reg entries were in the key, well there were absolutely no entries in here at all. Not even legit application entries. So my guess is the entries are being hidden from regedit.
My question is: What tools are useful for either extracting hidden keys and entries for later examination, or for opening the registry in such a way that the keys can be displayed? Are there any programs out there that can help me? Also, if I escalate privileges to system lvl when opening regedit will that help? Any push in the right direction is appreciated. Thanks in advance.
I recently had a problem like this only yesterday (although the adware was transmitted to mine through a web server). A useful way to get rid of it and find it in the key, that I've personally found helpful, is to download an adware cleaner (like adWcleaner), as they show you where the viruses are being generated from, and also give you the option to remove them.
On a side note: if you want to find the IP of the server transmitting the virus (if the virus transmits data through a webserver), download Norton, as it will say An intrusion attempt by "website" was blocked, along with the IP which you can then Nmap, for the TCP server.
Scenario: I'm performing a configuration audit on a server that's joined to the domain. For the mandatory security configuration settings, there are group policies defined and being pushed out to domain members, but not all of the settings. The remaining settings are supposed to be defined locally on the server through one of the many configuration interfaces. Some of the settings are easy to audit because there are registry keys that are created. Others... not so much.
For example, if I want to check that the 'Network access: Allow anonymous SID/Name translation' settings has been configured properly, I have to use a RSOP call (via Powershell, or another tool like BigFix/TEM). The problem is that settings defined by local GPE aren't reflected in RSOP.
Also, I have found that not all items are enumerated by getting the registry based GPOs and instead require using secedit to audit and very specific and complicated registry parsing to detect the changes with BigFix relevance.
I use this tool to set Local GPO for many things that either require the settings to be set through Local GPO, or settings I want to enforce on users using Local GPO, but deployed through BigFix / IBM Endpoint Manager.
MACHINE
Administrative Templates\System\User Profiles Add the Administrators security group to roaming user profiles At least Microsoft Windows XP Professional or Windows Server 2003 family This setting adds the Administrator security group to the roaming user profile share. Once an administrator has configured a users' roaming profile, the profile will be created at the user's next login. The profile is created at the location that is specified by the administrator. For the Windows 2000 Professional and Windows XP Professional operating systems, the default file permissions for the newly generated profile are full control, or read and write access for the user, and no file access for the administrators group. By configuring this setting, you can alter this behavior. If you enable this setting, the administrator group is also given full control to the user's profile folder. If you disable or do not configure it, only the user is given full control of their user profile, and the administrators group has no file system access to this folder. Note: If the setting is enabled after the profile is created, the setting has no effect. Note: The setting must be configured on the client computer, not the server, for it to have any effect, because the client computer sets the file share permissions for the roaming profile at creation time. Note: In the default case, administrators have no file access to the user's profile, but they may still take ownership of this folder to grant themselves file permissions. Note: The behavior when this setting is enabled is exactly the same behavior as in Windows NT 4.0.
HKLM\Software\Policies\Microsoft\Windows\System!AddAdminGroupToRUP
The default 64-bit version of Registry Editor (Regedit.exe) that is included with 64-bit versions of Windows displays both 64-bit keys and 32-bit keys. The WOW64 registry redirector presents 32-bit programs with different keys for 32-bit program registry entries. In the 64-bit version of Registry Editor, 32-bit keys are displayed under the HKEY_LOCAL_MACHINE\Software\WOW6432Node registry key.
You can view or edit both 64-bit and 32-bit registry keys and values by using the default 64-bit version of Registry Editor. To view or edit 64-bit keys, you must use the 64-bit version of Registry Editor (Regedit.exe). You can also view or edit 32-bit keys and values by using the 32-bit version of Registry Editor in the %systemroot%\Syswow64 folder. There are no differences in the way you perform tasks between the 32-bit version of Registry Editor and the 64-bit version of Registry Editor. To open the 32-bit version of Registry Editor, follow these steps:
You must close the 64-bit version of Registry Editor before you can open the 32-bit version (and vice versa) unless you start the second instance of Registry Editor with the -m switch. For example, if the 64-bit version of Registry Editor is already running, type %systemroot%\syswow64\regedit -m in step 2 to start the 32-bit version of Registry Editor.
To support the co-existence of 32-bit and 64-bit COM registration and program states, WOW64 presents 32-bit programs with an alternate view of the registry. 32-bit programs see a 32-bit HKEY_LOCAL_MACHINE\Software tree (HKEY_LOCAL_MACHINE\Software\WOW6432Node) that is completely separate from the true 64-bit HKEY_LOCAL_MACHINE\Software tree. This isolates HKEY_CLASSES_ROOT, because the per-computer portion of this tree resides within the HKEY_LOCAL_MACHINE\Software registry key.
To enable 64-bit/32-bit program interoperability through COM and other mechanisms, WOW64 uses a Registry Reflector that mirrors certain registry keys and values between the 64-bit and 32-bit registry views. The reflector is intelligent, in that is only reflects COM activation data.
The WOW64 Registry reflector may modify the contents of keys and values during the reflection process to adjust path names, and so on. Because of this, the 32-bit and 64-bit contents may differ. For example, pathnames that contain the system32 registry entry are written as SysWOW64 in the 32-bit section of the registry. The following keys are reflected:
The cybercriminals behind Poweliks implemented two clever techniques in their malware. The first was leveraging rundll32.dll to execute Javascript and the second was using a method to hide/protect their registry keys. I'll be focusing on the second method.
The technique of hiding/protecting registry keys using a non-ASCII character goes all the way back to over a decade ago. It's remarkable in a sense that after all these years, it still works on the latest Windows platform.
c80f0f1006