Imperceptible issuance of administrator rights
All with Friday, friends. Today we are sharing with you one more material that was translated on the eve of the launch of the course “Reverse Engineering” .
I had a cool idea how to force a user to run your application without social engineering or using third-party exploits. Then you can simply move forward and initiate a massive infection of executable files, but this can cause many unforeseen problems, and will also mean that applications with digital signatures from trusted vendors will appear as unreliable files. A good idea would be to “capture” just one dll. I will not call this method the UAC (User account Control) bypass, because you still need to get permission to launch the application (just not yours).
You may already be familiar with this concept, but I will still explain what it is. When an application calls LoadLibrary in a dll, but does not provide the full path to the file, the system first checks the KnownDlls registry key in which it searches for the path, if it is not there, the system will search in the directory from which the application was executed, and then look for in system paths such as system32 / syswow64.
')
You can easily put your dll in the same directory as the application, and give it the same name as a normally loaded system dll, but in any case, your dll must meet the following requirements:
The ZeroAccess virus used this method to take advantage of "social engineering" and force the user to run the file. To begin with, the Adobe Flash installer was downloaded from the official, the bot dll was written to the same directory where the installer was located, and then the installer was launched. When the installer is executed, the user account control reports that the application is delivered by a trusted source “Adobe Systems Incorporated”, and the user is most likely to install this application (this causes the bot to execute a malicious dll).
Is this a true flash player update? Or ZeroAccess? Nobody knows.
Imagine that there is a folder in which there are 90% of applications that require elevated account rights, and that it is writable without such rights. Well, this folder exists and it is the
I did not expect to find the dll, which is loaded by most applications and meets all the criteria of the malicious dll, and after about five minutes of searching, I found a gold mine:
Success! But the fact is that as soon as we start the installation, it will not work, since we have replaced an important library, but this is easy to fix. We infect dll.
At first, I just wanted to add a new section header, change the NumberOfSections field in the PE header, and then just add my section to the end of the PE file. It turned out that immediately after the last section header there is a directory of the related import, which will be overwritten by our section header. Therefore, after about 2 hours of writing an application to restore the entire PE from scratch, someone reminded me that the associated import directory exists only to speed up the loading of imported files and can be overwritten and then simply disabled in the PE header.
For the next 15 minutes, I held CTRL + Z to go back to where I started and felt silly. After two lines of code, my infector earned as it should, and I could move on to the next step. Now the infector simply disables and overwrites the directory of the associated import with a new section header, adds a new section to the end of the RE file, adjusts the SizeOfImage to accommodate the new section, and then changes the AddressOfEntryPoint to point to our new section.
All we need now is the code that we put there.
The obvious choice was to force the added partition to execute the shellcode, so we don’t need to worry about relocation and import. The actual code is fairly simple and written using some convenient FASM macros, I will quickly go over how it works.
The final result of the work infects dwmapi.dll with our shellcode and places it in the downloads folder as soon as the user downloads and launches an installer that requires administrator rights, a command line running as an administrator will be called (due to Wow64FsRedirect and the fact that most of the settings work under wow64, we can use the same code on 32-bit and 64-bit Windows systems).
You can find the full infector and shellcode on my github: https://github.com/MalwareTech/UACElevator .
That's all. See you on the course!
I had a cool idea how to force a user to run your application without social engineering or using third-party exploits. Then you can simply move forward and initiate a massive infection of executable files, but this can cause many unforeseen problems, and will also mean that applications with digital signatures from trusted vendors will appear as unreliable files. A good idea would be to “capture” just one dll. I will not call this method the UAC (User account Control) bypass, because you still need to get permission to launch the application (just not yours).
LoadLibrary
You may already be familiar with this concept, but I will still explain what it is. When an application calls LoadLibrary in a dll, but does not provide the full path to the file, the system first checks the KnownDlls registry key in which it searches for the path, if it is not there, the system will search in the directory from which the application was executed, and then look for in system paths such as system32 / syswow64.
')
You can easily put your dll in the same directory as the application, and give it the same name as a normally loaded system dll, but in any case, your dll must meet the following requirements:
- The application must load the dll by name, not the full path (as is often the case);
- The required library should not exist in HKLM \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ KnownDLLs;
- Your dll must match the processor architecture (remember that 64-bit processors will simply skip 32-bit libraries and vice versa);
- The library is in System32 or Syswow64, since specific paths often do not work.
The ZeroAccess virus used this method to take advantage of "social engineering" and force the user to run the file. To begin with, the Adobe Flash installer was downloaded from the official, the bot dll was written to the same directory where the installer was located, and then the installer was launched. When the installer is executed, the user account control reports that the application is delivered by a trusted source “Adobe Systems Incorporated”, and the user is most likely to install this application (this causes the bot to execute a malicious dll).
Is this a true flash player update? Or ZeroAccess? Nobody knows.
Less invasive method
Imagine that there is a folder in which there are 90% of applications that require elevated account rights, and that it is writable without such rights. Well, this folder exists and it is the
%userprofile%Downloads folder. You probably understand what I'm getting at.I did not expect to find the dll, which is loaded by most applications and meets all the criteria of the malicious dll, and after about five minutes of searching, I found a gold mine:
dwmapi.dll . This library not only met all the criteria, but also downloaded all the installation files. Now let's create our own dll, call it “dwmapi.dll” , place it in the Downloads folder and run the installation file.Success! But the fact is that as soon as we start the installation, it will not work, since we have replaced an important library, but this is easy to fix. We infect dll.
Creating a DLL infector
At first, I just wanted to add a new section header, change the NumberOfSections field in the PE header, and then just add my section to the end of the PE file. It turned out that immediately after the last section header there is a directory of the related import, which will be overwritten by our section header. Therefore, after about 2 hours of writing an application to restore the entire PE from scratch, someone reminded me that the associated import directory exists only to speed up the loading of imported files and can be overwritten and then simply disabled in the PE header.
For the next 15 minutes, I held CTRL + Z to go back to where I started and felt silly. After two lines of code, my infector earned as it should, and I could move on to the next step. Now the infector simply disables and overwrites the directory of the associated import with a new section header, adds a new section to the end of the RE file, adjusts the SizeOfImage to accommodate the new section, and then changes the AddressOfEntryPoint to point to our new section.
All we need now is the code that we put there.
Shell code
The obvious choice was to force the added partition to execute the shellcode, so we don’t need to worry about relocation and import. The actual code is fairly simple and written using some convenient FASM macros, I will quickly go over how it works.
- The stack is checked to ensure that dwmapi.dll was caused by DLL_PROCESS_ATTACH;
- The Ldr PEB structure is used to get the base address of Kernel32 and Ntdll;
- A simple implementation of GetProcAddress is used to import the following functions: NtOpenProcessToken, NtQueryInformationToken, NtClose, ExpandEnvironmentStringsA, CreateProcessA;
- The current process token opens and the code requests it to confirm that the application you are running from has UAC administrator rights;
- The path to cmd.exe is obtained, and then the command line is invoked;
- Execution is transferred back to the real entry point dwmapi.dll, which is why execution can continue.
Let's put it all together
The final result of the work infects dwmapi.dll with our shellcode and places it in the downloads folder as soon as the user downloads and launches an installer that requires administrator rights, a command line running as an administrator will be called (due to Wow64FsRedirect and the fact that most of the settings work under wow64, we can use the same code on 32-bit and 64-bit Windows systems).
You can find the full infector and shellcode on my github: https://github.com/MalwareTech/UACElevator .
That's all. See you on the course!
Source: https://habr.com/ru/post/457082/
All Articles