Miscellaneous Windows Registry Talk

[Amaroq_Starwind]

To start off this thread, I would like to ask a question.

https://en.wikipedia.org/wiki/Windows_Registry 

How come nobody ever uses QWORDs in the registry?

[exile360]

It is used occasionally, but I think for the most part it's because of the long history of backwards compatibility between x64 and x86, and most installers and the like were originally written for native 32 bit environments so there isn't much need for QWORD and other native x64 data types.  MS pretty much dictates what is commonly used for things, and even if you look at the hardware drivers' services keys in the registry, they're all using DWORD value types, even on native 64 bit Windows versions so my guess is it's either because of compatibility requirements, for ease of use/translation between x86 and x64, or simply because there's no real benefit from using QWORD and other native x64 data types (and most likely some combination of those reasons).

You can chat up the folks on MS Technet about it if you want something more concrete from industry insiders, but I'm betting it's probably just a matter of utility and there probably just isn't much need for it/reason to do it that way.  It's the same reason that even though most systems are now running 64 bit operating systems, many software programs are still coded in native x86/32 bit because they just wouldn't benefit from the larger addressable number of bits/amount of memory that native x64 provides.  It makes sense if you think about it.  I mean if you have an application that you know has no business ever consuming anywhere near the 4GB limit of a 32 bit application, why would you sweat rewriting it into native x64?  I mean what's the point?  Some may argue that a native x64 application is faster since it bypasses the x86 emulation layer, but I've run both native x64 and x86 versions of multiple applications in the past on my systems to test these very things and I can tell you that I couldn't tell the difference, even between native Windows applications like Internet Explorer and Windows Media Player which are both tied in so deeply to the OS core that you would think they of all programs would show some benefit from the added "speed" of using native x64 code, but I honestly couldn't tell any difference.

[Amaroq_Starwind]

If you gave me enough time, I could probably think of a use, such as storing a seed for a random number generator as just one example.

[Amaroq_Starwind]

Oh, and on that note... SInce QWORDs can still be used on 32-bit Windows, provided you're running at least WIndows XP, there really isn't any reason I can think of that you shouldn't use them.

[Amaroq_Starwind]

Okay, another bit of registry talk... Does anyone know of any good third-party registry editors?

[exile360]

Registry Hex Encoder (handy for conversions of value types/data)

Aezay Registry Commander

RegScanner by Nirsoft (very handy for quickly searching for data/values etc. in multiple locations/across the entire registry; very useful for removing traces of removed programs etc.)

As for QWORD value types, I guess it depends on what the benefits would be.  Based on the info here it seems its only benefit is that it can store larger values (more characters), so unless a program really needs to use value data of absurd lengths, it has little purpose/use, which would explain why we don't see it used too often.

[Amaroq_Starwind]

I wish there was a background process that would audit every change made to the registry by specific processes, users, etc...

That way it would be easier to uninstall programs cleanly, remove adware, rollback from tweaks gone awry, recover from corrupted registry files, etc.

Something like that might have other benefits too!

[exile360]

There is, it's called Revo Uninstaller, however you have to buy the Pro version to get the monitoring functionality.  I'm sure there are other activity logging tools/monitors around that could likely serve the same purpose if you learned enough about how to read and use their data/logs (tools like Procmon as well as some more advanced HIPS type apps).

Otherwise there's always backup tools like ERUNT which backs up registry hives as well as the built in System Restore functionality that can easily revert changes made by program installs (one reason I don't turn off/disable SR any more on my rigs like I used to, especially now that disk space isn't at such a premium, even on SSDs).

[Amaroq_Starwind]

My imagination is betraying me lately, it seems. It's not coming up with original ideas anymore, only stuff people are already doing 😢

Maybe registry auditing could eventually become part of Malwarebytes though, best-case scenario.

[exile360]

Back in the day that used to be a regular feature of many security products/tools, however these days it's of little use given the fact that most threats avoid using any obvious loading points when they can (tools like TeaTimer that came with older/pre-2.x builds of Spybot S&D).

As it is, Malwarebytes does scan registry hives, but I've discussed monitoring them in the past, for example to see if a process modifies/creates a known malicious value/key etc. (since Malwarebytes contains signatures for certain malicious registry keys/values, for example for PUMs as well as known malicious startups etc.), but the Dev told me that doing so would be really resource intensive given the number of registry reads/writes that occur on a near constant basis (even when idle, the system is often reading from/writing to various keys in the registry, not to mention the stuff that third party apps do whenever they're installed/launched/running in the background etc.) so I really don't think it would be a good idea (people would get pretty cross with Malwarebytes if their process suddenly started consuming near constant CPU cycles and more RAM than it already does as it would definitely impact overall system performance pretty much all the time).  As it is, they monitor all processes/threads in real-time for ransomware behavior (something I'm personally not a fan of since it's not too proactive since it only kicks in one you're already infected with an active ransomware threat; something the other more proactive components/layers should prevent, especially since most ransomware uses exploits to download/execute).

[digmorcrusher]

https://www.martau.com/

[Amaroq_Starwind]

@exile360 All the more reason to consider GPU Acceleration for Registry Auditing, especially since you could use GPU memory for it. Also, you would only need to audit Writes, not Reads, and there could be a Whitelist of processes that were safe to exclude from Registry Auditing (since again, it would track registry edits on a per-process basis).

One more thing to consider: Always have these sorts of things be Optional Features; don't turn it on by default, but whenever a new update hits, have a notification display that experimental new features are available. That way people don't freak out about their graphics card suddenly sounding like a mythical deity got her tails caught in a jet turbine, but they will  still know that a new feature is there for them to try out, with a disclaimer that it may make their computer a fair bit louder.

[exile360]

Two problems with that approach:

1. It doesn't address the fact that power usage (whether from the CPU or GPU) is a primary concern these days, with more devices than ever (including, and especially PCs) now being mobile devices that rely on battery power, not to mention the fact that users with discrete GPUs (which would be a requirement; you couldn't do that sort of thing with Intel integrated graphics on lower end machines because they don't have that computing capability) so whether you're using the CPU or GPU to do it, it's going to raise the power output of the system (not to mention heat, which can also be risky) which in turn shortens the battery life of the device.

2. History has proven that any feature introduced as an option disabled by default will not be used/enabled by the vast majority of users so its benefit would be extremely limited.  Most people ignore such alerts/notifications (and many are hostile towards them because they just want their security apps to shut up and quietly do their jobs and only inform them if there is a problem/infection etc.), and so it likely wouldn't be worth pouring the Dev resources necessary into it to make it happen unless it were enabled for everyone out of the box.  This is especially true because it is a preventative/protection mechanism.  It's not like rootkit scanning which you only really need as a last resort when you think you're infected to check for/remove an installed/active rootkit; this is a protection mechanism designed to prevent threats from making malicious modifications to the registry, so it really needs to be turned on otherwise what's the point?

While it is true that whitelisting safe/known good processes can help, there's also the issue that the bad guys could easily exploit some vulnerability or use legitimate methods to write malicious data into the registry, so whitelisting virtually anything could pose a serious risk to the system's security because you can bet the bad guys would test to determine if any processes are allowed/whitelisted then figure out how to take advantage of that fact.

The reality is it's just too easy to change things via the registry, but on the flip side it's just as easy to change them back, so a remediation only approach like Malwarebytes uses currently is really sufficient, especially since the more proactive protection mechanisms are far more likely to identify and stop the attack/threat before it ever gets that far.

That also doesn't address the fact that many legit sysadmins in the business world regularly use such restrictive registry policies (including many that Malwarebytes would normally detect as PUM) to help secure the systems they manage, and it's much less of a headache if they only have to worry about a scan setting off a detection for a policy they've put in place than it would be to deal with an active protection mechanism preemptively stopping their policies from taking effect (the number of support tickets generated on the business side would skyrocket in no time, guaranteed).

I don't want to slam the idea or anything (again, I myself proposed this very thing years ago to the Devs when I was in Product Management for Malwarebytes so I do see the value), but I really think there's a good reason most vendors choose not to do this these days (there used to be many more tools/products that did, but they weren't widely used and were often seen as more of a hassle to work with than they were worth, just like most HIPS and third party firewalls that behave like/include HIPS type components/functions).  In fact, I believe this is the very reason Safer Networking stopped including TeaTimer with Spybot S&D and why, even in the later 1.x releases, it wasn't installed by default any more (you had to check a box in the installer to install it) and it would be in a read-only/allow-all type mode relying on a blacklist of known bad processes and registry changes even if you did install and enable it, making its function far more limited/less proactive (unless you changed it to paranoid mode to make it act like the old versions did; so again, more steps/non-default settings).

It's a lot like User Account Control in Windows.  It was a great idea and it works well to help secure a system against attackers and malware, however Microsoft turned it down in Windows 7 and later versions deliberately because the prompts came up too often and users got annoyed, either turning it off or becoming trained to always click Yes, OK, or Allow so it wasn't serving its purpose any more.  They found a good balance I think, but even today we still come across users who have UAC completely or partially disabled on their systems even though it poses a risk to their security just because they don't want to deal with the prompts/notifications at all.  Introducing any such mechanisms into Malwarebytes would likely get so many complaints that they would end up pulling the feature back anyway, or as you say having it off by default, which means hardly anyone would use it, especially the novice/normal users who in fact are the ones who really need the extra security the most (the more technical users like you and me can always check our registries and loading points with tools like Autoruns and will recognize when something is there that doesn't belong, so we don't really need the babysitter watching over us to tell us when it happens, though it might be a bit more convenient).

[Amaroq_Starwind]

Well, it could also just scan the registry at regular intervals to  silently record any and all changes that occurred since the last periodic registry scan, and using existing APIs to determine what processes were running at that time to try to deduce which processes were responsible for which changes (again, recording only, no immediate actions). Nowhere near as detailed as a complete registry audit, but also nowhere near as power-hungry.

It could also only audit the registry in more detail when certain types of processes run (such as installers), when a process needs to run with administrative privileges, when processes run while the user isn't actively using the computer, when the computer is running on AC power, and/or even just when an unrecognized process runs for the first time, etc. There are a lot of ways that you could configure it.

Also of note; the integrated graphics of modern AMD and Intel CPUs do actually have compute capabilities, and GPU computing is actually quite energy efficient compared to running everything on the CPU only... But regardless, there's probably better solutions to everything.

[exile360]

Same problem.  Some AVs do this sort of thing with background scans/idle scans etc., but as it is Malwarebytes does have a default scheduled scan that will look for such registry entries so that should be sufficient.

The more advanced logging/diagnostics stuff already exists in the business client, so I wouldn't want them to cannibalize their own products by offering similar functionality in the consumer version (plus I know users would complain about the constant spikes in resource usage etc. if they did).