![\"\"](\"https:\/\/www.hexacorn.com\/blog\/wp-content\/uploads\/2020\/02\/runddl32_2.png\")
<\/a><\/figure><\/div>\n\n\n\nThe very same happens when a 64-bit rundll32.exe is used to load a 32-bit library. <\/p>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\nIt’s like that… and that’s the way it is. <\/p>\n\n\n\n
This is a well-known stuff and you are probably wondering where I am going with it.<\/p>\n\n\n\n
Today most of applications are 64-bit, so one could exploit the rundll32.exe behavior I described in various ways:<\/p>\n\n\n\n
Scenario 1<\/strong><\/p>\n\n\n\n Set up a persistence Run key (or use any other common startup method) to point to rundll32.exe <name of a 32-bit library><\/em><\/p>\n\n\n\n This will keep the persistence entry clean (points to a signed 64-bit rundl32.exe, even if full path is not explicitly set in a startup entry to point to c:\\windows\\system32\\rundll32.exe), and will ensure cascading execution of a 32-bit rundll32.exe that will load the given 32-bit DLL (possibly malicious). <\/p>\n\n\n\n Scenario 2<\/strong><\/p>\n\n\n\n Same as before, set up a persistence in any way you like, just pointing it to a rundll32.exe and using a file name of an existing, clean 32-bit DLL, and then place a malicious rundll32.exe under c:\\windows\\SysWOW64.<\/p>\n\n\n\n This will launch the malicious 32-bit rundll32.exe.<\/p>\n","protected":false},"excerpt":{"rendered":" The role of Rundll32 is to load DLLs. On a 32-bit OS it is a very straightforward task, but when you mix architectures interesting things happen. One of a side-effects of having more than one architecture on the same box … Continue reading