Sunday, August 13, 2023

Integrating Yara with RegRipper

A lot of writing and training within DFIR about the Registry refers to it as a database where configuration settings and information is maintained. There's really a great deal of value in that, and there is also so much more in the Registry than just "configuration information". Another aspect of the Registry, one we see when discussing "fileless" malware, is its use as a storage facility. As Prevailion stated in their DarkWatchman write-up:

Various parts of DarkWatchman, including configuration strings and the keylogger itself, are stored in the registry to avoid writing to disk.

The important part of that statement is that the Registry is and can be used for storage. Yes, you can store configuration settings, as well as information that can be used to track user activity, connected devices, connected networks, etc., but the Registry can just as easily be used to store other information, as well. As we can see from the Fileless Storage page (part of the MITRE ATT&CK framework) there are quite a few examples of malware that use the Registry for storage. In some cases, the keys and values are specific to the malware, whereas in other instances, the storage location within the hive file itself may change depending upon the variant, or even selections made through a builder. Or, as with Qakbot, the data used by the malware is stored in values beneath a randomly-named key.

As such, it makes sense leverage Yara, which is great for detecting a wide range of malware, via RegRipper. One way to find indications of malware that writes to the Registry, specifically storing its configuration information, is by creating a timeline and looking for keys being added or updated during the time of the presumed compromise. Another is to comb through the Registry, looking for indications of malware, shell code, encoded commands, etc., embedded within values, and this is where leveraging Yara can really prove to be powerful.

One example would be to look for either the string "MZ" or the bytes "4D 5A" at offset 0. If malware is stored in the Registry with those bytes stripped, then searching for other strings (PDB strings) or sequences of bytes would be an effective approach, and this is something at which Yara excels. As such, leveraging Yara to extend RegRipper makes a great deal of sense.

Maybe we can call this "YARR", in honor of International Talk Like A Pirate Day.

No comments: