ESENT
Corey asked a question recently in the Win4n6 Yahoo group that peaked my interest...because it had to do with a Registry key.
In short, Corey had found the entries were created under the following key:
HKLM\Software\Microsoft\ESENT\Process
First, ESENT apparently refers to the built-in JET database engine that has shipped with Windows as of Windows 2000. According to various pages at the MS site, this DB engine is very limited, not allowing remote access, and only providing for simple queries...but it is used in instances with other storage formats (flat file, Registry, etc.) are simply not suitable. According to the MS Windows SDK blog:
"The ESENT database engine can be used whenever an application wants
high-performance, low-overhead storage of structured or semi-structured data."
I then began looking into the key itself to get an idea of what was happening. I found, on my system, a number of subkeys beneath this key...ipconfig, svchost, wmplayer, etc. As I found each executable image, I opened the .exe file in PEView and saw that each .exe had an IMAGE_DEBUG_DIRECTORY, as well as a IMAGE_DEBUG_TYPE_CODEVIEW directory listed. Within the IMAGE_DEBUG_TYPE_CODEVIEW directory, I could see a reference to a .pdb, or program database file, which is where symbols and program debugging information is stored. While this is admittedly a somewhat limited and narrow view, it did occur to me that this was something to check, if you have a full image that includes the Registry hives in addition to the executable files.
Of course, both Corey and I employed ProcMon to see what was happening when an executable listed in the ESENT\Process key was run. For the monitoring I did, I opened a command prompted, typed "ipconfig /all", started my capture, and then hit "Enter" for my command in the command prompt window. As soon as the command completed, I halted monitoring in ProcMon. I then began going through the output, and found that the ipconfig.exe process itself did, in fact, query the key in question.
Corey found in his capture, for wmplayer.exe, "RegSetValue" was used on the "DEBUG\Trace Level" value; I have run the ipconfig command several times and while I did see the accesses to the "ipconfig\DEBUG\Trace Level" value (ie, RegQueryValue), I do not see any values set (via RegSetValue), nor modified.
Another interesting artifact that I saw in the ProcMon capture was that while esent.dll is not included in the PE header of the executable image file, the DLL is loaded by the ipconfig.exe process.
Okay, so this is interesting stuff...but only in a limited manner. If you Google for "ESENT\Process", you'll see a number of hits at AV sites that refer to malware. As I read through some of these (here, here), I was reminded of some of the artifacts surrounding the MUICache key, and how sometimes what is referred to as "analysis" could simply be secondary or tertiary artifacts of how the executable was run, or simply from the OS running and doing it's thing.
However, there were other links, such as this one (refers to Virut) that seemed to indicate that a closer look at the executable file itself is likely warranted. Other entries at McAfee, such as this one, further indicates that there may be malware samples for which the ESENT\Process key entries are specifically created, and that this may definitely be worth a look. In many ways, entries beneath this key may...and I say may, as more research and assistance from Microsoft is definitely needed in this area...be similar to those beneath the MUICache key, in that they are indirect artifacts created not by the executable itself, but instead by the environment or eco-system (that's just a fancy way of saying "operating system") as the malware interacts with it.
I have a couple of test images that I can look at with respect to this key, and of course, I created an esent.pl plugin (took about 5 minutes) for RegRipper to make things like testing and analysis easier.
As a side note (and shout out), I'm reading through Malware Analyst's Cookbook at the moment, and there are a LOT of really good Python and Perl recipes listed in the book that would be abundantly useful for this kind of analysis. While my own book provides a short view into what a normal PE file should look like, the Cookbook provides not only a view into what malware looks like, but it also provides tools for examining malware files up close without actually having to run them.
So, going forward...any thoughts, comments, or assistance in understanding a bit more about the ESENT\Process key would be greatly appreciated!
Addendum: For anyone who uses or has used ProcMon, or more specifically, RegMon, when running applications, you'll usually see a process accessing the "Image File Execution Options" key; when associated DLLs are loaded, you'll see similar accesses, as well, for this key. When this key is accessed, it's the operating system looking to see if there is a Debugger value associated with the specific executable image file. It is this association with debugging that led me to think...tenuous, I know...that the files with .pdb associations in their PE headers were accessing the ESENT key. My reasoning was, if the OS is going to look for some sort of debugger association once, why not twice?
In short, Corey had found the entries were created under the following key:
HKLM\Software\Microsoft\ESENT\Process
First, ESENT apparently refers to the built-in JET database engine that has shipped with Windows as of Windows 2000. According to various pages at the MS site, this DB engine is very limited, not allowing remote access, and only providing for simple queries...but it is used in instances with other storage formats (flat file, Registry, etc.) are simply not suitable. According to the MS Windows SDK blog:
"The ESENT database engine can be used whenever an application wants
high-performance, low-overhead storage of structured or semi-structured data."
I then began looking into the key itself to get an idea of what was happening. I found, on my system, a number of subkeys beneath this key...ipconfig, svchost, wmplayer, etc. As I found each executable image, I opened the .exe file in PEView and saw that each .exe had an IMAGE_DEBUG_DIRECTORY, as well as a IMAGE_DEBUG_TYPE_CODEVIEW directory listed. Within the IMAGE_DEBUG_TYPE_CODEVIEW directory, I could see a reference to a .pdb, or program database file, which is where symbols and program debugging information is stored. While this is admittedly a somewhat limited and narrow view, it did occur to me that this was something to check, if you have a full image that includes the Registry hives in addition to the executable files.
Of course, both Corey and I employed ProcMon to see what was happening when an executable listed in the ESENT\Process key was run. For the monitoring I did, I opened a command prompted, typed "ipconfig /all", started my capture, and then hit "Enter" for my command in the command prompt window. As soon as the command completed, I halted monitoring in ProcMon. I then began going through the output, and found that the ipconfig.exe process itself did, in fact, query the key in question.
Corey found in his capture, for wmplayer.exe, "RegSetValue" was used on the "DEBUG\Trace Level" value; I have run the ipconfig command several times and while I did see the accesses to the "ipconfig\DEBUG\Trace Level" value (ie, RegQueryValue), I do not see any values set (via RegSetValue), nor modified.
Another interesting artifact that I saw in the ProcMon capture was that while esent.dll is not included in the PE header of the executable image file, the DLL is loaded by the ipconfig.exe process.
Okay, so this is interesting stuff...but only in a limited manner. If you Google for "ESENT\Process", you'll see a number of hits at AV sites that refer to malware. As I read through some of these (here, here), I was reminded of some of the artifacts surrounding the MUICache key, and how sometimes what is referred to as "analysis" could simply be secondary or tertiary artifacts of how the executable was run, or simply from the OS running and doing it's thing.
However, there were other links, such as this one (refers to Virut) that seemed to indicate that a closer look at the executable file itself is likely warranted. Other entries at McAfee, such as this one, further indicates that there may be malware samples for which the ESENT\Process key entries are specifically created, and that this may definitely be worth a look. In many ways, entries beneath this key may...and I say may, as more research and assistance from Microsoft is definitely needed in this area...be similar to those beneath the MUICache key, in that they are indirect artifacts created not by the executable itself, but instead by the environment or eco-system (that's just a fancy way of saying "operating system") as the malware interacts with it.
I have a couple of test images that I can look at with respect to this key, and of course, I created an esent.pl plugin (took about 5 minutes) for RegRipper to make things like testing and analysis easier.
As a side note (and shout out), I'm reading through Malware Analyst's Cookbook at the moment, and there are a LOT of really good Python and Perl recipes listed in the book that would be abundantly useful for this kind of analysis. While my own book provides a short view into what a normal PE file should look like, the Cookbook provides not only a view into what malware looks like, but it also provides tools for examining malware files up close without actually having to run them.
So, going forward...any thoughts, comments, or assistance in understanding a bit more about the ESENT\Process key would be greatly appreciated!
Addendum: For anyone who uses or has used ProcMon, or more specifically, RegMon, when running applications, you'll usually see a process accessing the "Image File Execution Options" key; when associated DLLs are loaded, you'll see similar accesses, as well, for this key. When this key is accessed, it's the operating system looking to see if there is a Debugger value associated with the specific executable image file. It is this association with debugging that led me to think...tenuous, I know...that the files with .pdb associations in their PE headers were accessing the ESENT key. My reasoning was, if the OS is going to look for some sort of debugger association once, why not twice?