Yes, yes, I know…you’re probably thinking, “you wrote it, dude”, and while that’s true, that’s not the reason why I really love RegRipper. Yes, it’s my “baby”, but there’s so much more to it than that. For me, it’s about flexibility and utility. At the beginning of 2020, there was an issue with the core Perl module that RegRipper is built on…all of the time stamps were coming back as all zeros. So, I tracked down the individual line of code in the specific module, and changed it…then recompiled the EXEs and updated the Github repo. Boom. Done. I’ve written plugins during investigations, based on new things I found, and I’ve turned around working plugins in under an hour for folks who’ve reached out with a concise request and sample data. When I’ve seen something on social media, or something as a result of engaging in a CTF, I can tweak RegRipper; add a plugin, add capability, extend current functionality, etc. Updates are pretty easy. Yes, yes…I know what you’re going to say…“…but you wrote it.” Yes, I did…but more importantly, I’m passionate about it. I see far too few folks in the industry who know anything about the Registry, so when I see something on social media, I’ll try to imagine how what’s talked about could be used maliciously, and write a plugin.
And I’m not the only one writing plugins. Over the past few months, some folks have reached out with new plugins, updates, fixes, etc. I even had an exchange with someone the other day that resulted in them submitting a plugin to the repo. Even if you don’t know Perl (a lot of folks just copy-paste), getting a new plugin is as easy as sending a clear, concise description of what you’re looking for, and some sample data.
Not long ago, a friend asked me about JSON output for the plugins, so I’ve started a project to create JSON-output versions of the plugins where it makes sense to do so. The first was for the AppCompatCache…I still have a couple of updates to do on what information appears in the output, but the basic format is there. Here’s an excerpt of what that output currently looks like:
{
“pluginname”: “appcompatcache_json”
“description”: “query\parse the appcompatcache\shimcache data source”
“key”: “.ControlSet001\Control\Session Manager.”
“value”: “AppCompatCache”
“LastWrite Time”: “2019-02-15 14:01:26Z”
“members”: [
{
“value”: “C:\Program Files\Puppet Labs\Puppet\bin\run_facter_interactive.bat”
“data”: “2016-04-25 20:19:03”
},
{
“value”: “C:\Windows\System32\FodHelper.exe”
“data”: “2018-04-11 23:34:32”
},
{
“value”: “C:\Windows\system32\regsvr32.exe”
“data”: “2018-04-11 23:34:34”
},
Yeah, I have some ideas as to how to align this output with other tools, and once I settle on the basic format, I can continue creating plugins where it makes sense to do so.
Recently, we’ve been seeing instances of “Scheduled Task abuse”, specifically of the RegIdleBackup task. To be clear, while some have been seeing it recently, it’s not “new”…Fox IT, part of the NCC Group,
reported on it last year. It’s also been
covered more recently here in reference to GraceWire/FlawedGrace. Of all the reporting that’s out there on this issue, what
hasn’t been addressed is how the modification to the task is performed; is the task XML file being modified directly, or is the API being used, such that the change would also be reflected in the Task subkey entry in the Registry?
From the RegIdleBackup task XML file:
<Actions Context=“LocalSystem”>
<ComHandler>
<ClassId>{CA767AA8-9157-4604-B64B-40747123D5F2}</ClassId>
</ComHandler>
</Actions>
So, we see the COM handler listed in the XML file, and that’s the same CLSID that’s listed in the Task entry in the Software hive. About 2 years ago, I updated a plugin that parsed the Scheduled Tasks from the Software hive, so I went back to that plugin recently and added additional code to look up CLSIDs within the Software hive and report the DLL they point to; here’s what the output looks like now (from a sample hive):
Path: \Microsoft\Windows\Registry\RegIdleBackup
URI : Microsoft\Windows\Registry\RegIdleBackup
Task Reg Time : 2020-09-22 14:34:08Z
Task Last Run : 2022-12-11 16:17:11Z
Task Completed: 2022-12-11 16:17:11Z
User : LocalSystem
Action : {ca767aa8-9157-4604-b64b-40747123d5f2} (%SystemRoot%\System32\regidle.dll)
The code I added does the look up regardless of whether the CLSID is the only entry listed in the Action field, or if arguments are provided, as well. For example:
Path: \Microsoft\Windows\DeviceDirectoryClient\HandleWnsCommand
URI : \Microsoft\Windows\DeviceDirectoryClient\HandleWnsCommand
Task Reg Time : 2020-09-27 14:34:08Z
User : System
Action : {ae31b729-d5fd-401e-af42-784074835afe} -WnsCommand (%systemroot%\system32\DeviceDirectoryClient.dll)
The plugin also reports if it’s unable to locate the CLSID within the Software hive.
So, what this means is that the next time I see a system that’s been subject to an attack that includes Scheduled Task abuse, I can check to see if the issue impacts the Software hive as well as the Task XML file, and get a better understanding of the attack, beyond what’s available in open reporting.
Finally, I can quickly
create plugins based on testing scenarios; for some things, like parsing unallocated space within hive files, this is great for doing tool comparison and validation. However, when it comes to other aspects of DFIR, like extracting and parsing specific data from the Registry, there really aren’t many other tools to use for comparison.
Interestingly enough, if you’re interested in running something on a live system, I ran across
reg_hunter a bit ago; it seems to provide a good bit of the same functionality provided by RegRipper, including looking for null bytes, RLO control characters in key and value names, looking for executables in value data, etc.