Get hive root with --bn

[DFIR-Purim]

RECmd version # 2.0.0.0

Describe the bug When using --kn, I can successfully use the alias "ROOT\" to get all keys under the root path, without the need to know the root path name in advance. However, when using --bn, "ROOT" alias does not work. Within the hive I'm analyzing, the root path is named "CsiTool-CreateHive-{00000000-0000-0000-0000-000000000000}" and the only method in which I was successful in fetching the data I wanted was defining: KeyPath: CsiTool-CreateHive-{00000000-0000-0000-0000-000000000000}\

The results were:

To Reproduce Mentioned above

Expected behavior Mentioned above

Additional context I hope I made sense

[EricZimmerman]

Does a wild card not work for that? A *

[DFIR-Purim]

Thank you for the very quick response! I tried using KeyPath: ROOT* and got no results

[EricZimmerman]

What does just

*

Do

[DFIR-Purim]

cmdline is .\RECmd.exe -f .\SOFTWARE --nl --bn .\BatchExamples\Test.reb --csv .

Used KeyPath: * Got:

[EricZimmerman]

If it's in a batch file you'll have to put that single star in single quotes because yaml doesn't like it otherwise

[DFIR-Purim]

Putting a single star in single quotes only gave me details about the root path itself without detailing the keys it holds, unlike what I get when using "--kn ROOT\*"

Again, I truly appreciate your assistance with this issue!!

[EricZimmerman]

its not the general use case for the tool, in batch mode, to get a list of keys. the root key is generally not specified at all

[DFIR-Purim]

The reason I'm doing this, is that I want to dump the keys under ROOT to CSV, and it's impossible with --kn unfortunately. I have a case in which a malware creates a key under root, but it's a generated string so in order to detect it I need to view the timestamps of all keys under root

[DFIR-Purim]

Is there a way to export the keys under "ROOT\*" (not recursively) to CSV?

[EricZimmerman]

@AndrewRathbun have you ever tried this?

[AndrewRathbun]

@AndrewRathbun have you ever tried this?

I'll have to give this a go after hours! I'll report back

[AndrewRathbun]

Alright, sorry for the delay on this.

I made a test Batch file, ROOTtest.reb, as seen below:

Description: ROOT test
Author: Andrew Rathbun
Version: 1
Id: 49ff9762-4dce-413f-928b-786daa8aec5a
Keys:
    -
        Description: ROOT Key Test - SOFTWARE
        HiveType: Software
        Category: ROOT Keys
        KeyPath: ROOT\*
        Recursive: false
        Comment: ROOT test
    -
        Description: ROOT Key Test - SYSTEM
        HiveType: SYSTEM
        Category: ROOT Keys
        KeyPath: ROOT\*
        Recursive: false
        Comment: ROOT test
    -
        Description: ROOT Key Test - SAM
        HiveType: SAM
        Category: ROOT Keys
        KeyPath: ROOT\*
        Recursive: false
        Comment: ROOT test
    -
        Description: ROOT Key Test - SECURITY
        HiveType: SECURITY
        Category: ROOT Keys
        KeyPath: ROOT\*
        Recursive: false
        Comment: ROOT test
    -
        Description: ROOT Key Test - NTUSER
        HiveType: NTUSER
        Category: ROOT Keys
        KeyPath: ROOT\*
        Recursive: false
        Comment: ROOT test
    -
        Description: ROOT Key Test - UsrClass
        HiveType: UsrClass
        Category: ROOT Keys
        KeyPath: ROOT\*
        Recursive: false
        Comment: ROOT test

First things first, I collected my registry hives using this KAPE command:

.\kape.exe --tsource C: --tdest C:\temp\RegHiveTest\tout --tflush --target RegistryHives --debug

and I ran this RECmd command against the aforementioned hives using the following command:

.\RECmd.exe -d "C:\temp\RegHiveTest\tout" --bn "C:\temp\ROOTtest.reb" --nl false --csv C:\temp\RegHiveTest

This resulted in what I believe to be what @DFIR-Purim is looking for:

Nothing beyond ROOT\* was grabbed using the above ROOTtest.reb batch file. If we want this to be in production, I can clean it up a bit and name it better, like ROOTKeyDumpNonRecursive.reb or similar. Thoughts?

[AndrewRathbun]

@DFIR-Purim any feedback on the above?

[DFIR-Purim]

@AndrewRathbun we appreciate all your amazing work! Unfortunately the person with whom you communicated is no longer a DFIR analyst. If our team ever gets to use the new feature you've added, we'll make sure to update you.

[EricZimmerman]

Ok xool