Imperceptible granting of administrator rights

All Friday, friends. Today we are sharing with you yet another material translated on the eve of the launch of the reverse engineering course .



I had a cool idea how to get a user to run your application without social engineering or using third-party exploits. Then you can simply move forward and initiate a mass infection of the executable files, but this can cause many unforeseen problems, and also means that digitally signed applications from trusted suppliers will appear as untrusted files. It is a good idea to “capture” just one dll. I will not call this method bypass UAC (User account Control), because you still need to get permission to run the application (not yours).

Loadlibrary

You may already be familiar with this concept, but I will nevertheless explain what it is. When the application calls LoadLibrary in the dll, but does not provide the full path to the file, the system first checks the KnownDlls registry key, in which it looks for the path, if it is not there, the system will look in the directory from which the application was executed, and then it will search in system paths such as system32 / syswow64.

You can well place your dll in the same directory as the application and give it the same name as a normally bootable system dll would have, but in any case, your dll must meet the following requirements:

• The application should download the dll by name and not the full path (as is often the case);
• The required library must not exist in HKLM \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ KnownDLLs;
• Your dll should match the processor architecture (remember that 64-bit processors will simply skip 32-bit libraries and vice versa);
• The library is located 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 one, the bot dll was recorded in the same directory as the installer, and then the installer was launched. When the installer is executed, user account control displays a message that the application is supplied by a trusted source of “Adobe Systems Incorporated”, and the user is most likely to install this application (this leads to the execution of a malicious bot dll).


Is this a real update to Flash Player? Or ZeroAccess? No one knows.

Less invasive method

Imagine that there is a folder in which 90% of applications that require elevated account rights are located, and that it is writable without this kind of rights. Well, such a folder exists and this is a folder %userprofile%Downloads. You probably understand what I'm getting at.

I did not expect to find a dll, which is loaded by the majority of applications and at the same time meets all the criteria 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, name it “dwmapi.dll”, put 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 the dll.

Creating an 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 heading there is a related import directory that will be overwritten by our section heading. Therefore, after about 2 hours of writing an application to restore all PE from scratch, someone reminded me that the linked import directory exists only to speed up the download 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 get back to where I started and felt stupid. After two lines of code, my infector worked as it should, and I could move on to the next step. Now the infector simply disconnects and rewrites the linked import directory with a new section header, adds a new section to the end of the PE file, adjusts SizeOfImage to accommodate the new section, and then changes AddressOfEntryPoint to point to our new section.

All we need now is the code that we put there.

Shellcode

The obvious choice was to force the added section to execute shellcode, so we didn't need to worry about relocations and import. The actual code is pretty simple and written using some convenient FASM macros, I’ll quickly go over how it works.

• The stack is checked to ensure that dwmapi.dll has been called by DLL_PROCESS_ATTACH;
• The Ldr PEB structure is used to obtain the base address of Kernel32 and Ntdll;
• A simple GetProcAddress implementation is used to import the following functions: NtOpenProcessToken, NtQueryInformationToken, NtClose, ExpandEnvironmentStringsA, CreateProcessA;
• The current process token is opened and the code requests it to confirm that the application from which we are starting has UAC administrator rights;
• It turns out the cmd.exe path, and then the command line is called;
• The execution is transferred back to the real entry point of dwmapi.dll, which is why the execution can continue.

Putting it all together

The end result of the operation infects dwmapi.dll with our shellcode and places it in the download folder, as soon as the user downloads and runs the installer, which requires administrator rights, a command line will be called up as administrator (due to Wow64FsRedirect and the fact that most 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!