What is a Backdoor for...
After exploiting and gaining access to a system, the next step would be to install a backdoor on the target machine. A backdoor is typically a covert method of bypassing normal authentication or encryption in a computer, product, embedded device, or its embodiment. Backdoors are most often used for remote access to a computer. The reason for installing a persistent backdoor is important since attackers want to maintain access to the compromised machines even after the users reboot. Instead of having to constantly deliver payloads to the user to establish C2, attackers install backdoors after the initial infiltration so that the whole process does not have to be repeated again and again. Next, we shall explore ways to install persistent backdoors on our test machines.
Reference
1. Persistent Backdoor using Metasploit
Pre-Requisites
For creating a persistence backdoor, you should have a compromised machine of the victim with a Meterpreter session.
Install Backdoor
Attempt 1: metsvc (FAILED to install a service)
Reason that it failed is because metsvc required admin privileges to open service manager according to https://stackoverflow.com/questions/32464177/error-metsvc-cannot-open-the-service-manager0x00000005
Reference:
Attempt 2: persistence.rb (FAILED)
A number of alerts stating "Process Terminated" notifications from OpenEDR on the target Windows VM. When the Meterpreter script was executed on the Kali Linux, we can see a series of executions of VEsNPiEZshYrECm.exe. Since DetectOnly was disabled, it prevented the execution of this foreign (by foreign we mean the file was NON-existent before the execution) EXE file. Since this foreign EXE was repeatedly written & launched by Cscript.exe, it is why there were a lot of notifications from OpenEDR.
The following shows the relationships between these events.
The out-of-the-box OrientDB web-UI unfortunately is not that "intelligent" to show relevant edges. So what we do is click on a vertex to show a menu, there is an arrow menu INTO the node, and an arrow OUT of the vertex. The lower screenshot shows what goes into the payload.
With proper edge naming, we give the viewer a clear idea of what's going on with this method. In this case, cscript.exe wrote an exe file. Of which, it was executed-after-written to that path repeatedly. Since OpenEDR is enforcing protection, all installation of backdoor attempts are terminated but the Metasploit module is retrying quite a few times. No signature-updates for such protection as it is designed for closed-networks. See https://github.com/jymcheong/OpenEDR/wiki/2.-Profiling-&-Threat-Hunting#threat-hunting--profiling
References:
Reasons why the Metasploit modules were not working:
- Stopped by OpenEDR (DetectOnly is not enabled) OR
- Stopped by Windows Defender Antivirus because it will start automatically whenever the machine is rebooted. Tried disabling it permanently in Group Policy but it still runs automatically after restart.
Attempt 3: exploit/windows/local/registry_persistence (SUCCESSFUL)
Description:
This module will install a payload that is executed during boot. It will be executed either at user logon or system startup via the registry value in "CurrentVersion\Run" (depending on privilege and selected method). The payload will be installed in registry.
Steps:
After establishing a meterpreter session, use the following commands to execute registry persistence.
If the exploit is successful, it will create a registry key and install a run key as shown in the screenshot below.
Whenever the user reboots the machine and the meterpreter session closes, all you need to do is to set up the multi handler payload and execute it.
As shown in the screenshot above, whenever the user logs into the system, we will automatically get a meterpreter session because of the autorun script that we have installed in the registry.
We are also able to see the newly created registry key in Registry Editor on the target machine.
Observations:
Sequence noted in ODB console:
System > smss.exe > smss.exe > winlogon.exe > userinit.exe > explorer.exe > cmd.exe > powershell.exe > powershell.exe
Next, we investigate cmd.exe & powershell.exe on the front-end investigation board.
As seen in the screenshot above, cmd.exe is only tagged with "Unusual CommandLine" label. Let's investigate into the command line that was used.
Looking at the CommandLine field, we can see that it is very similar to the value data of the registry key that we created on the victim's machine. Next, we will look into powershell.exe
As seen in the screenshot above, powershell.exe was tagged with "Unusual Process Sequence" & "Unusual CommandLine". Let's investigate the CommandLine field.
Looking at the CommandLine field, we can see that a VERY long command has been used. Parts of the command has been encoded, which means that analysts will have to decode the text to figure out the exact command that was used.
Next, we will take a look at ODB graph to see what else we can find.
We can see that powershell.exe initiated multiple network connections to 192.168.1.6, which is the IP address of the Kali Linux VM (where I am launching my attacks). This indicates that the target machine is trying to establish a meterpreter session with my Kali Linux VM.
References:
2. Persistent Backdoor DLL with OneDrive (FAILED)
YouTube Link: https://youtu.be/1j5pnvA6txM
A content creator in the YouTube video above made use of a python script a.py for DLL hijacking against OneDrive to create a persistent backdoor. However, no links to a.py could be found in the YouTube video so I searched for his GitHub. Found https://github.com/magnusstubman/dll-exports which looks similar to what he did. Followed steps listed but when I restarted the VM, there was an error message pop-up saying that OneDrive.exe could not be launched.
Removed version.dll that I added from OneDrive and rebooted. OneDrive was able to run again, meaning that the dll file that was added is causing the issue.
Upload DLL to OneDrive folder
Using the meterpreter session that you have established, go to the directory where you want to upload the DLL file to. In this case, I will be uploading to OneDrive folder.
meterpreter > cd C:/Users/User/AppData/Local/Microsoft/OneDrive
Once inside the directory, upload the DLL file as shown in the screen shot below.
On the target machine, we can see that version.dll has been uploaded into OneDrive folder.
References
3. SharPersist
SharPersist is a Windows persistence toolkit written in C#. It was created in order to assist with establishing persistence on Windows operating systems using a multitude of different techniques.
Installation
Refer to https://github.com/fireeye/SharPersist#steps-to-build on how to compile the project.
Persistence Technique Used
These are the techniques available for use in SharPersist. For this example, I will be using the startupfolder technique to spawn calc.exe from cmd.exe whenever the machine is booted up.
Commands Used
SharPersist -t startupfolder -c "C:\Windows\System32\cmd.exe" -a "/c calc.exe" -f "Some File" -m add
Results
calc.exe was spawned after logging into the system!
ODB console
After executing the powershell command:
We can see powershell.exe > SharPersist.exe lineage sequences.
After logging into machine:
We can see calc.exe being spawned by cmd.exe.
Investigation-board presents summarized Process anomalies
SharPersist.exe was tagged with 4 labels:
- Foreign EXE - Because the compiled binary file DID NOT exist before the occurrence of this alert
- Unusual Process Sequence - Because this is the first sighting of this process-sequence after profiling phase
- Unusual CommandLine - Because OpenEDR has not seen this command line before
- Loaded Foreign DLL - Because SharPersist loads and uses foreign compiled DLLs. When looking into ODB console, we can see that SharPersist uses DLLs like Fody.dll and FodyCommon.dll.
There were also 4 activities from SharPersist.exe as shown in the screenshot below:
Activities of SharPersist.exe:
- created Some File.lnk (file extension for a shortcut file used by Microsoft Windows to point to an executable file),
- created SharPersist.exe.log (automatically produced file that contains a record of events from certain software i.e. SharPersist)
- terminated SharPersist.exe (after the command has finished executing)
- modified file creation time of Some File.lnk
Lastly, we look into calc.exe.
calc.exe was only tagged with "Unusual Process Sequence" & "Unusual CommandLine" because OpenEDR has not seen this process sequence and command line before. Furthermore, we notice that calc.exe is a background process. calc.exe is an interactive application and hence should be a foreground process. Based on these observations, it is clear that there is suspicious activity with regards to the creation of this calc.exe.
more importantly, should a calculator app be "background"?