{"id":2267,"date":"2014-01-10T16:25:55","date_gmt":"2014-01-10T16:25:55","guid":{"rendered":"http:\/\/www.hexacorn.com\/blog\/?p=2267"},"modified":"2016-10-21T21:43:06","modified_gmt":"2016-10-21T21:43:06","slug":"beyond-good-ol-run-key-part-6-2","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2014\/01\/10\/beyond-good-ol-run-key-part-6-2\/","title":{"rendered":"Beyond good ol\u2019 Run key, Part 6"},"content":{"rendered":"<p>The subject of today&#8217;s post is an obscure autorun mechanism that targets specifically users of applications written in Visual Basic. The trick forces VB applications to load a specific DLL into the context of the application. Let me repeat it &#8211; this particular autorun mechanism will trigger anytime someone runs an application written in Visual Basic so it&#8217;s sort of a random autorun which I believe is still very reliable &#8211; after all, VB applications are very popular and many people use them on daily basis.<\/p>\n<p>If you ever &#8216;procmonned&#8217; any VB application you might have noticed that at some stage it is checking the content of the following registry key:<\/p>\n<ul>\n<li>\n<pre>HKLM\\SOFTWARE\\Microsoft\\VBA\\Monitors<\/pre>\n<\/li>\n<\/ul>\n<p><a href=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/vbappenummonitorskey.png\"><img decoding=\"async\" loading=\"lazy\" class=\"aligncenter size-full wp-image-2270\" src=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/vbappenummonitorskey.png\" alt=\"vbappenummonitorskey\" width=\"818\" height=\"53\" srcset=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/vbappenummonitorskey.png 818w, https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/vbappenummonitorskey-300x19.png 300w\" sizes=\"(max-width: 818px) 100vw, 818px\" \/><\/a><\/p>\n<p>The VB app (or, more precisely MSVBVM60 DLL) enumerates this registry node (if it exists) looking for subkeys which in turn are later queried for a few specific values.<\/p>\n<p>The mechanism appears to be designed for debugging\/monitoring purposes because one of the values the VB apps query for is called <em>EnableEventMonitor<\/em>. The registry keys\u00a0 used by this mechanism point to Event Monitoring DLLs that can be loaded into the process space of the VB application. The loading happens via CoCreateInstance API utilizing\u00a0 some unknown interface referenced via GUID DE32EFB0-4A56-11D1-AA89-00008612DCF1.<\/p>\n<p>Knowing what expected values are allows us to craft a registry file that will help us to add our own VB monitor:<\/p>\n<pre style=\"padding-left: 30px;\">Windows Registry Editor Version 5.00\r\n\r\n[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VBA\\Monitors\\TestMonitor]\r\n\"EnableEventMonitor\"=dword:00000001\r\n\"CLSID\"=\"foobar\"\r\n\r\n[HKEY_CLASSES_ROOT\\foobar]\r\n\r\n[HKEY_CLASSES_ROOT\\foobar\\Clsid]\r\n@=\"{00000000-0000-0000-0000-FFFFFFFFFFFF}\"\r\n\r\n[HKEY_CLASSES_ROOT\\CLSID\\{00000000-0000-0000-0000-FFFFFFFFFFFF}\\InprocServer32]\r\n\"ThreadingModel\"=\"Apartment\"\r\n@=\"&lt;your path&gt;\\\\test.dll\"<\/pre>\n<p>Just to quickly walk through it, we are adding the <em>TestMonitor<\/em> entry under:<\/p>\n<ul>\n<li>\n<pre>HKLM\\SOFTWARE\\Microsoft\\VBA\\Monitors<\/pre>\n<\/li>\n<\/ul>\n<p>We then enable it by setting the value of <em>EnableEventMonitor<\/em> to 1.<\/p>\n<p>After that we are linking it to the HKCR entry that in turn links it to the actual DLL via the CLSID value (it&#8217;s actually a bit misleading name for the value since this particular CLSID doesn&#8217;t need to look like a regular GUID).<\/p>\n<p>As a result CLSID entry under <em>HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VBA\\Monitors\\TestMonitor<\/em> (<em>foobar<\/em> in our case) points to the entry under HKCR (<em>HKCR\\foobar<\/em> in our case), and that entry points to the typical COM server entry via its Default value (pointing in our case to <em>00000000-0000-0000-0000-FFFFFFFFFFFF<\/em>). And of course, the <em>HKEY_CLASSES_ROOT\\CLSID\\{00000000-0000-0000-0000-FFFFFFFFFFFF}\\InprocServer32<\/em> points to our DLL.<\/p>\n<p>I hope you are confused \ud83d\ude42<\/p>\n<p>After we add the registry entries all we need to do now is dropping our test dll file in the <em>&lt;your path&gt;\\\\test.dll<\/em> location.<\/p>\n<p>Running a simple &#8216;Hello World&#8217; application written in VB loads the specified dll &#8211; in my case the test DLL sends notifications to the debugger and these can be intercepted with a Debug View:<\/p>\n<p><a href=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/vbamonitors.png\"><img decoding=\"async\" loading=\"lazy\" class=\"wp-image-2268 aligncenter\" src=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/vbamonitors.png\" alt=\"vbamonitors\" width=\"456\" height=\"130\" srcset=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/vbamonitors.png 456w, https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/vbamonitors-300x85.png 300w\" sizes=\"(max-width: 456px) 100vw, 456px\" \/><\/a>The procmon log is much richer this time:<\/p>\n<p><a href=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/eventmonitoradded.png\"><img decoding=\"async\" loading=\"lazy\" class=\"aligncenter size-full wp-image-2275\" src=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/eventmonitoradded.png\" alt=\"eventmonitoradded\" width=\"1041\" height=\"353\" srcset=\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/eventmonitoradded.png 1041w, https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/eventmonitoradded-300x101.png 300w, https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2014\/01\/eventmonitoradded-1024x347.png 1024w\" sizes=\"(max-width: 1041px) 100vw, 1041px\" \/><\/a><\/p>\n<p>Notably, the DLL doesn&#8217;t need to implement any COM functionality. CoCreateInstance will load it as a DLL library, and then query for the interface; it is not implemented, but the code execution is achieved. One could obviously add DLL exports to handle the COM requests and maybe even implement the mystery interface.<\/p>\n<p>Last, but not least. Instead of <em>EnableEventMonitor<\/em> value set to 1 (which is a global setting), one can use Environment variable\u00a0 called <em>VBAEV_&lt;name of the monitor&gt;<\/em> and set it prior to running VB program in the environment of that targeted VB application.<\/p>\n<p>In our case it would be:<\/p>\n<pre style=\"padding-left: 30px;\">set VBAEV_TestMonitor=1<\/pre>\n<pre style=\"padding-left: 30px;\">helloworld.exe<\/pre>\n<p>launched from a command line. This would make the VB app launch with the inherited environment from the command line processor in which we set the <em>VBAEV_TestMonitor<\/em> to <em>1<\/em>. This will ensure we load a DLL only to the <em>helloworld.exe<\/em>, but not other VB applications.<\/p>\n<p><strong>Update 2016<\/strong><\/p>\n<p>It turns our that I have not explored all the possibilities here &#8211; the very same mechanism is used by the Visual Basic Engine libraries (VBE6.dll, VBE7.dll) that are responsible for running Visual Basic for Applications code (yes, the Office macros). Not a big surprise, but worth documenting and only shows how close the source code of these VB products must be&#8230;<\/p>\n<p>So, as long as the system&#8217;s user is working with the macrodocuments, or using VBA in Outlook, the malware could leverage this key as a persistence mechanism.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The subject of today&#8217;s post is an obscure autorun mechanism that targets specifically users of applications written in Visual Basic. The trick forces VB applications to load a specific DLL into the context of the application. Let me repeat it &hellip; <a href=\"https:\/\/www.hexacorn.com\/blog\/2014\/01\/10\/beyond-good-ol-run-key-part-6-2\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[13,35,15,19,9],"tags":[],"_links":{"self":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/2267"}],"collection":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/comments?post=2267"}],"version-history":[{"count":7,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/2267\/revisions"}],"predecessor-version":[{"id":3896,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/posts\/2267\/revisions\/3896"}],"wp:attachment":[{"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/media?parent=2267"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/categories?post=2267"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.hexacorn.com\/blog\/wp-json\/wp\/v2\/tags?post=2267"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}