In this article, we are going to describe the utility of the BITSAdmin tool and how vital it is in Windows Penetration Testing.

TL; DR

BITSAdmin is a tool preinstalled on Windows OS that can be used to download malicious files. It is one of the Living Off Land (LOL) Binaries.

Disclaimer

The main objective of publishing the series of “Windows for Pentester” is to introduce the circumstances and any kind of hurdles that can be faced by any Pentester while solving CTF challenges or OSCP labs which are based on Windows Operating System. Here we do not criticize any kind of misconfiguration that a network or system administrator does for providing higher permissions on any programs/binaries/files & etc.”

Table of Content

• Introduction
  • What is BITSAdmin?
• Configurations used in Practical
• Working with BITSAdmin
  • Downloading using /transfer Switch
  • Downloading using /addfile Switch
  • Downloading using PowerShell Cmdlet
  • Downloading using One-liner
• Penetration Testing using BITSAdmin
  • Compromising using Malicious Executable
  • Compromising using File-Less Payload
  • Compromising with Malicious Executable inside ADS
• Persistence using BITSAdmin
• Detection
  • SC Query
  • QMGR Database
  • Verbose Switch
  • Event Logs
• Mitigation
• Conclusion

Introduction

What is BITSAdmin?

Background Intelligent Transfer Service Admin is a command-line tool that creates downloads or uploads jobs and monitors their progress. BITSAdmin was released with the Windows XP. At that time, it used the IBackgroundCopyJob as its interface. The Upload option of the BITSAdmin was introduced with the release of Windows Server 2003. With the release of Windows Vista, we had some more additional features like Custom HTTP headers, Certificate-based client authentication, IPv6 support. Subsequent year was the release of the Windows Server 2008, it introduced the File Transfer Notification Method (which we use it to run an executable in Practical #5). Windows 7 introduced Branch Cache Method for the BITS Transfer. When BITS downloads a file, the actual download is done behind the svchost.exe service. BITSAdmin is used to download files from or upload files to HTTP web servers and SMB file shares. It takes the cost of the transfer into account, as well as the network usage so that the user’s foreground work is not influenced. BITS has the ability to handle network interruptions, pausing and automatically resuming transfers, even after a reboot.

Configurations used in Practical

Attacker:

• OS: Kali Linux 2019.4
• IP: 192.168.1.13

Target:

• OS: Windows 10 (Build 18363)
• IP: 192.168.1.11

Working with BITSAdmin

As we discussed in the introduction that BITSAdmin is used as a download client. Now we will see the BITSAdmin in action. There are 2 switches to download a file in BITSAdmin, first one is ‘/transfer’ and ‘/addfile’. The working of both these parameters is quite identical. But the way these switches present the progress and completion feedback is different. BITSAdmin downloads files in the form of jobs. A job has to be defined before moving forward. After downloading we can work on the jobs using the various switches.

Practical #1: Downloading using /transfer Switch

The /transfer switch is a short and quick way to download any file from the remote server to the Host Machine. To begin the transfer, we need to define the Display Name of the transfer. It can be anything the user wishes.

Here, we named all our transfers as “hackingarticles”. Now after defining the name, we need to enter the location with the name of the file from the remote server. For the Test Environment, we have a sample image file named ignite.png at the remote server. We mention it and we also mention the Local Location and Name of the file. After providing all this information we hit Enter key and the transfer begins.

We can see that we can see the State as Transferred and we also get a confirmation “Transfer complete”. We perform a directory Listing to check the file and we are assured that the file was indeed transferred successfully.

Practical #2: Copying Files Locally

BITSAdmin works on the principle of File Transfer. Hence, we can also use it as a glorified copy and paste command. This means that BITSAdmin will also be able to transfer from one location to another on the same machine. Let’s give it a try.

As we already know that the BITSAdmin deals with jobs. So, we will first declare a job. We named it hackingarticles.

The file that is supposed to be transferred should be added to the job. We use the /addfile switch to complete this task. We will be transferring the file.txt from “C:\” to “C:\Users\Victim\Desktop\”.

Now to initiate the transfer we will be using the /resume switch. This will sound different but the /resume switch does, in fact, initiate the transfer.

Now, when the transfer initiated. It transfers the file in the form of a temporary file. To actually get the file fully we will need to run the /complete switch. And as we can see that file is successfully transferred to the Destination.

We can see that the intended file is successfully downloaded on the Target System.

Practical #3: Downloading using PowerShell Cmdlet

The practicals that we showed just now can be performed on Windows Command Prompt (cmd.exe) as well. With the release of the Windows Server 2016, Microsoft has released a cmdlet specifically for the PowerShell to manage the BITS Jobs using BITSAdmin Client. It is named as Start-BITSTransfer.

For the transfer using this cmdlet, we don’t have to mention the name of the Job. We can just define the Source and Destination as shown in the image given below.

Note: If while penetration testing, we get an environment that is strictly PowerShell and we are not able to use the BITSAdmin normally, we can use this method.

Practical #4: Downloading using One-liner

We can transfer our files using BITSAdmin in one execution. This is a good example when we are in a hurry for a transfer. Instead of declaring the job, add the file to the job, resuming the job and complete the job in different steps we can complete all the steps required to transfer in this one-liner. This method gets the work done in one go. This can also be used to push in a location where we can execute a single instance of command.

Penetration Testing using BITSAdmin

BITSAdmin can perform many more functions (like upload files, etc.) but we will be focusing on Penetration Testing for now.

Practical #5: Compromising using Malicious Executable

It’s time to move on from utility to Penetration Testing. We will be getting a meterpreter session using a payload which will be downloaded and executed using the BITSAdmin. These practical were tested in a lab-controlled environment where we have the same network configuration for the entirety of the Practical. So, we created the payload once and used it multiple times.

To begin the exploitation, we decided to create a payload using the msfvenom tool. We use the reverse_tcp payload with the target to be Windows System and gaining meterpreter. We defined the Lhost for the IP Address for the Attacker Machine followed by the subsequent Lport on which we will be receiving the session from the target machine. We created this payload in the form of an executable and sent this payload to the /var/www/html/ directory.

After the payload creation, we start the apache2 service so that the payload is available to download on the Local Network.

After serving the payload on the web server, we will run the listener which can capture the meterpreter session when it will get generated.

We set the proper configuration of the payload. We set the attacker machine’s IP address as the localhost address and the port that we mentioned while creating the payload as a local port.

In our previous practices, we downloaded a file, now we will download the payload using the same technique. But as BITSAdmin can also execute the payload by itself we will define parameters for it.

Starting with creating a job named “hackingarticles”, then we add the payload file in the job that we just created.

After adding the file, we use the /SetNotifyCmdLine switch to execute the payload. This is done with the help of an action that we scripted. First, it will start the cmd.exe and then, it will complete the download and then it will execute the said command in the background.

After this, we run the /resume switch to get the download started.

After the download completes, it executes the payload and we have ourselves a meterpreter session.

Practical #6: Compromising using File-Less Payload

In the previous practical, we created a payload file and then gained a session from it. This method creates a file that can be detected. In other words, it was traceable. But as BITSAdmin can execute a command directly we can exploit the target without using a file.

We will start this practice with our attacker machine, we will be running Metasploit Framework. After opening it we will use the web_delivery Exploit as shown in the image given below.

Here we choose the target 3 (Regsvr32) as it will generate a small command that can be executed to get the meterpreter session.

We set the attacker machine’s IP Address as localhost address and we run it. It works for a bit and gives us the regsvr32 command that will give us access to the target machine.

On the Target Machine, there is a holdup. BITSAdmin is programmed to run the command only on completion of the download. So, we will be needing to download something. It can be anything that seems harmful. As BITSAdmin is designed to download the Windows Updates, we can use its file as well. Here we will be using a harmless png image file.

After adding the file, we will move on the /SetNotifyCmdLine. Here we will modify the command that was created using web_delivery in such a way that regsvr32.exe creates the session from the target machine to attacker machine.

Finally, we resume the BITSAdmin to get this working.

As shown in the screenshot given below, we grab a meterpreter session from the Target Machine as soon as the command gets executed.

This was a stealthy method as there is no file associated with the session we obtained. But this can get stealthier using the right techniques.

Practical #7: Compromising with Malicious Executable inside ADS

In the previous article of this series, we introduced Alternative Data Stream. So, without going into details about the Alternative Data Stream, let’s compromise the target machine with a payload concealed in the Alternative Data Steam.

We will create a malicious executable payload using msfvenom as we did in Practical #5, as it is the same method, we are not showing it again here.

After creating the payload and starting the listener, we will move to our target machine.

Here, we created a BITS job named hackingarticles using the /create switch.

After creating the job, we will add the file to download using BITSAdmin’s /addfile switch.

After adding the payload successfully, we use the next switch /SetNotifyCmdLine to read the contents of the payload which will be downloaded and transfer to the alternative data stream of a file.txt.

Keeping this configuration, we start the download using the /resume switch.

Here, we list the C:\file.txt contents to find that out payload.exe has successfully being transferred into the ADS of this file.

Now to execute the file that we put in the ADS; we will be using wmic. We will use the create switch followed by the path of the payload as shown in the image.

It says that the Execution was successful.

We went back to our Attacker Machine to see that a meterpreter instance is generated and captured by our listener. We run sysinfo to see the details of the Target System.

Practical #8: Persistence using BITSAdmin

Persistence, it means that the exploited session will be available to you even after the target machine restarts. Let’s see how to achieve this using BITSAdmin.

We will create a malicious executable payload using msfvenom as we did in Practical #5, as it is the same method, we are not showing it again here.

After creating the payload and starting the listener, we will move to our target machine.

Here, we created a BITS job named hackingarticles using the /create switch.

After creating the job, we will add the file to download using BITSAdmin’s /addfile switch.

After adding the payload successfully, we use the next switch /SetNotifyCmdLine to execute the payload. This is done with the help of an action that we scripted. First, it will start the cmd.exe and then it will complete the download and then it will execute the said command in the background.

After this, we use another switch /SetMinRetryDelay. It is used to set the minimum length of time, in seconds, that BITS wait after facing a transient error before trying to transfer the file. Here, if payload that we download gets stuck in a transient error, which is a temporary error. BITS is designed to run continuously if an error of such kind occurs. So, if our download is completed but due to the transient error was not able to execute properly, this switch will make it retry after 120 seconds.

That’s was simply setting up an exploit to gain a session. Now we need to work on it to be a persistence method.  But the BITS can get into an error state and keep the payload in a temporary state without completing the download and in turn stopping the execution of the payload. To solve this issue, we will use schtasks to resume our job at a specific time again and again. This will allow the payload to persist irrespective of any kind of issue.

The /resume switch in the schtasks will restart the BITS job when if, it enters an error state. Using a schedule modifier task (/mo) to make the task gets reactivated every (60, in this case) minute. The BITSAdmin redownloads the payload in case of an error and schtasks take care of the execution of the payload on an event of a reboot of the machine.

We went back to our Attacker Machine to see that a meterpreter instance is generated and captured by our listener. We run sysinfo to see the details of the Target System. In case of failure, we will have to restart the listener with the same configuration and we will have the session again in no time.

Please, note this is a limited demo. In the real-life scenarios, we suggest that rename the payload file to look like a Windows Update and perform all these tasks in the ‘%Temp%’ directory for obvious reasons. We also recommend that we modify the schtasks to delete the task after a particular time with removing the presence by deleting the logs related to this intrusion.

Detection     

Before the official introduction of BITSAdmin in the Windows Defender Real-time Scan, it was quite difficult to detect BITS Transfers. Apart from scanning through logs, there wasn’t any other method. Monitoring the logs for the usage of the BITSAdmin tool (especially the ‘Transfer’, ‘Create’, ‘AddFile’, ‘SetNotifyFlags’, ‘SetNotifyCmdLine’, ‘SetMinRetryDelay’, ‘SetCustomHeaders’, and ‘Resume’ switches) Actually, there is a way to gain the information about the transfers. It is through the QMGR Database.

SC Query

BITSAdmin is deployed as a service. Hence its status can be checked with the SC Query Utility.

This will show if there is an instance of any BITS Transfer Running or not.

QMGR Database

It is an abbreviated form of the Queue Manager Database. This is a record of all the BITS Jobs. There are 2 types of files generated in this database record. A .dat file and a .db file. This database file can be found at this location

We traversed to the said location using the dir command to find ourselves a qmgr.db file. We tried opening the file but it was hex-encoded.

So, we used a Hex-Editor Online tool. Here we scanned through the data and found that we have the IP Address of the file being Downloaded with its path. We followed the complete path and it gives us the temporary file that was downloaded before the /complete switch was used.

It is to be noted that the BITS Jobs will not be shown in autoruns as there is not any way to run BITSAdmin on start-up with Default Configurations.

Verbose Switch

If we are lucky enough to find the BITSAdmin in the act, we can get our hands some very useful information. We ran a BITS Job and ran the following command to gain information about the job.

Event Logs

We have the Windows Event logs which Focuses on the default event logs, it is one of the sources for detection of any download. It is known as the Microsoft-Windows-BITS-Client/Operational log. These logs contain the download state, download source, user and some file information for each BITS transfer job. This event log is strikingly similar across Windows 7 through 10 so it is a good endpoint collection source. There are some limitations here as these logs don’t show the sparse data, as well as the logs, are spread over several EventIDs. Potentially a huge amount of entries in any environment makes it impossible to spot malicious download hiding in plain sight. This log will also not detect the BITS persistence unless there was a network transfer to a suspicious domain as part of the configured job.

This Log can be monitored on the Event Viewer at this Location:

Application and Services Logs > Microsoft > Windows > BITS-Client

Mitigation

Our recommendation for mitigating BITSAdmin is to modify network and/or host firewall rules, as well as other network controls, to only allow legitimate BITS traffic. We can also reduce the default BITS job lifetime in Group Policy or by editing the “JobInactivityTimeout” and “MaxDownloadTime” Registry values in HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\BITS The default maximum lifetime for a BITS job is 90 days, but that can be modified. Lastly, we can limit the access of the BITSAdmin interface to specific users or groups.

Conclusion

This kind of attack is very much happening in real life. There have been multiple incidents targeted to different office environments where the malicious file was detected and deleted but was revived again using BITSAdmin. A special shout out to Oddvar Moe for his help in some tinkering. It was a fun learning experience working with BITSAdmin. We are going to write more articles about other LOLS that we could find. Stay Tuned.

BITSAdmin Operations                   Persistence using BITS    

Living Off Land binaries                  BITSAdmin

Author: Pavandeep Singh is a Technical Writer, Researcher and Penetration Tester. Can be Contacted on Twitter and LinkedIn

In this article, we are going to describe the utility of Certutil tool and how vital it is in Windows Penetration Testing.

TL; DR

Certutil is a preinstalled tool on Windows OS that can be used to download malicious files and evade Antivirus. It is one of the Living Off Land (LOL) Binaries.

Disclaimer

The main objective of publishing the series of “Windows for Pentester” is to introduce the circumstances and any kind of hurdles that can be faced by any Pentester while solving CTF challenges or OSCP labs which are based on Windows Operating System. Here, we do not criticize any kind of misconfiguration that a network or system administrator does for providing higher permissions on any kind of programs/binaries/files & etc.”

Table of Content

• Introduction
  • What is certutil?
  • What is Living off Land?
  • Working with certutil?
  • What is Alternative Data Stream (ADS)?
• Configurations used in Practical
• Working with certutil
  • Encoding
  • Decoding
  • Hashing
  • Downloading
  • Reading Error Code
• Penetration Testing using certutil
  • Compromising using Malicious Executable
  • Compromising with Encoded Malicious DLL
  • Compromising with Malicious Executable inside ADS
• Mitigation
• Conclusion

Introduction

What is Certutil?

Certutil is a CLI program that can be used to dump and display certificate authority (CA), configuration information, configures Certificate Services, backup and restore CA components, and verify certificates, key pairs, and certificate chains. It is installed as a part of Certificate Services.

What is Living off Land?

In simple words, it is an attack that works on the idea of using system tools as backdoors. File-less attack is another example of LOL attack. Attackers who use this tactic works with trusted, in most cases, preinstalled system tools to carry out their attack. Attackers use these tactics to hide their malicious activity in plain sight among the other general activity inside the network or system. As these kinds of attacks operate without triggering any alerts, it is almost impossible for investigators to determine who is behind the said malicious activity even if they discover it.

What is Alternative Data Stream (ADS)?

The NTFS file system consists of the ADS feature. This is an inconspicuous feature that was included, to provide compatibility with files in the Macintosh file system. ADS enable files to incorporate more than one stream of data. In any instance, each file consists of at least one data stream. This default data stream in Windows is recognized as :$DATA.

Windows Explorer can’t see what ADSs are in a file (or a way to erase them without actually discarding the original file) but they can be created and accessed with ease. Because they are challenging to detect, thus often used by hackers to hide files on machines that they’ve compromised. Executables in ADSs can be executed from the command line but without showing up in Windows Explorer.

Some of the CTF Challenges over HackTheBox where certutil can be used are:

Access, Arctic, BigHead, Conceal, Ethereal, Fighter, Giddy, Hackback, Jerry, Rabbit.

Configurations used in Practical

Attacker:

• OS: Kali Linux 2019.4
• IP:192.168.1.10

Target:

• OS: Windows 10 (Build 18363)
• IP: 192.168.1.11

Working with certutil

Practical #1: Encoding

Certutil contains an encode parameter. It could help to encode file content into Base64. This is a Windows equivalent to the base64 command in Linux.

When working with an executable file, we came across a scenario. In it, the uploading of the executable file was not smooth. We can use certutil to encode the executable file. Then transfer the encoded data, then decode it on the recipient machine.

In the following practical, we first created a text file named “file.txt” and wrote the “This is a plain text” line in it. We did this with Add-Content cmdlet in PowerShell. We can see that it worked when we checked the file using type command. To convert, we will use certutil with encode parameter. We will provide the text file and the file that it should write the encoded data.

Certutil adds two segments “BEGIN CERTIFICATE” and “END CERTIFICATE”. The converted contents of the file are between these two segments. We can check the encoded text using the type command.

We can use the parameter -encodehex to convert data into Hex encoded files.

Practical #2: Decoding

Certutil can decode the data encoded in Base64. Let’s show you a quick method from which you can decode the data. We will be using the file that we encoded in the previous practical. We will use certutil with -decode parameter. Then provide the encoded file and the file it should write the decoded data. We can check the decoded text using the type command.

We can use the parameter -decodehex to decode the Hex encoded files.

Practical #3: Hashing

Hashing means taking data and giving out an output string of a fixed length. Using the cryptography hashing algorithms — e.g., MD5, SHA-1, SHA-256, you can verify if two files are identical or not. The checksum is a hash value used for performing data integrity checks. It’s a kind of signature for a file. By comparing checksum, we can identify duplicate files.

Time to generate some hashes. We will use the file.txt we created earlier. First, we will generate the MD5 hash using certutil parameter -hashfile. With the parameter, file path and algorithm we can hash the file.

NOTE: While working with Systems like Windows 7, keep in mind that the hash algorithms are case-sensitive. Be sure to type, for example, “MD5”, not “md5”.

Practical #4: Downloading

In scenarios, where wget, BITSAdmin or any other convention method is blocked. Certutil can be used to download files from the internet. We will be downloading 7zip.exe from the 7zip server as shown in the image.

-URLCache	Display or delete URL cache entries
-split	Split embedded ASN.1 element & Save to files
-f	Force Overwrite

Practical #5: Reading Error Code

Suppose you got a system error code without any message. You don’t have any source to look up the meaning of the error. This is a common scenario. Certutil can help to look up the message text for system error codes.

NOTE: Certutil can perform many more functions related to CA Certificates but we will be focusing on Penetration Testing for now.

Penetration Testing using certutil

Practical #6: Compromising using Malicious Executable

During our initial assessment, we saw that the certutil was actively downloading files from the internet without any kind of verification or assessment. This is an instance that is part of the MITRE | ATT&CK Remote File Copy Tactic.

Certutil can be used to copy a file from one system to another to stage some attacking tools or other files throughout an attack. Files can also be transferred from an outer attacker-controlled system through a Command and Control Channel to bring tools or scripts into the target network to support Lateral Movement.

In the previous practical, we downloaded a file from a remote server. Let’s see how we can compromise a Windows System using a Malicious Executable.

We started our attack with Exploit Development. We used the msfvenom tool to generate a Payload for a Reverse TCP Connection to our attacker machine. We provided the msfvenom with the appropriate LHOST and LPORT. The format of the payload was set to an Executable(.exe) File. We named it “shell.exe”. After successful execution, the file was created in our “/root” directory. Now to transfer the newly generated we decided to use the HTTP Server generated by a Python One-liner.

Now that the payload is hosted on the server, before executing the payload on the Target Machine, we need to start a Listener on Attacker Machine to capture the meterpreter session that would be generated after the execution of the payload.

After successfully starting a listener on the Attacker, its time to move to Target Machine. Here, we have a PowerShell Terminal. We need to download the payload to this machine. We will use certutil to fetch it. Certutil will make two connections to the remote web server using two different User-Agents. They will be named “Microsoft-CryptoAPI” and “Certutil URL Agent”.

NOTE: During our assessment, we found that upon execution the above command an Access Denied Error is notified. Using -verifyCTL instead of -URLCache will let you bypass this error.

After the successful transfer of the Payload to Target Machine. We executed the payload as shown in the image.

We went back to our Attacker Machine to see that a meterpreter instance is generated and captured by our listener. We run sysinfo to see the details of the Target System.

We have successfully Compromised the Target Machine using a combination of Certutil and a Malicious Executable.

Practical #7: Compromising with Encoded Malicious DLL

As seen earlier Certutil encodes file content into Base64. This opens up a lot of possibilities. This is an instance that is part of MITRE | ATT&CK Deobfuscate/Decode Files or Information Tactic.

Attackers can use Obfuscated (Difficult to detect/find) Files to conceal evidence of an attack from the analysis. Afterward, they may Deobfuscate (Unhide) those files. This is where certutil comes into the picture. It can decode the data and help bypass Antivirus, IDS/IPS Software. Certutil can also be used to decode a portable executable file that has been hidden inside a certificate file.

Payloads may be compressed, archived, or encrypted to avoid detection. These payloads may be used with Obfuscated Files or Information during Initial Access or later to mitigate detection. Sometimes a user’s action may be required to open it for deobfuscation or decryption as part of User Execution. The user may also be required to input a password to open a password protected compressed/encrypted file that was provided by the attacker. Now onto our Practical.

We started our attack with Exploit Development. We used the msfvenom tool to generate a Payload for a Reverse TCP Connection to our attacker machine. We provided the msfvenom with the appropriate LHOST and LPORT. The format of the payload was set to a Dynamic-Link Library(.dll) File. We named it “dll.txt”. We can name it any other name which is less suspicious. We use the text file so that it doesn’t rise any unnecessary flags. After successful execution, the file was created in our “/root” directory. Now to transfer the newly generated we decided to use the HTTP Server generated by a Python One-liner.

Now that the payload is hosted on the server, before executing the payload on the Target Machine, we need to start a Listener on Attacker Machine to capture the meterpreter session that would be generated after the execution of the payload.

After successfully starting a listener on the Attacker, it times to move to Target Machine. Here, we have a PowerShell Terminal. We need to download the payload to this machine and we need to do this discreetly. We run certutil with a combination of URLCache and encode separated by the pipe (|). Now the file will be downloaded as a text file and gets encoded as another text file which we named “edll.txt” for encoded DLL.

Now to execute the payload to compromise the target, we need to decode it. We use the decode parameter in certutil to decode the payload and saved it as “exploit.dll”. Now to execute this DLL we decide to use regsvr32. It executes DLL directly into memory.

We went back to our Attacker Machine to see that a meterpreter instance is generated and captured by our listener. We run sysinfo to see the details of the Target System. We have successfully Compromised the Target Machine using a combination of Certutil and an Encoded Malicious Executable.

As we talked about evading Antivirus Software. Let’s inspect the files that we generated and used in the attempt to compromise the target. We use VirusTotal for this analysis. We first inspect the “dll.txt”. Upon successful upload and analysis of the dll.txt, we see that it was detected by 54 out of 67 Antivirus Engines. That can’t be good.

So, the inspection of the dll.txt file was not acceptable. Now let’s test the file we encoded using certutil. We uploaded the edll.txt. Upon analysis of the edll.txt, we see that it was detected by 4 out of 56 Antivirus Engines. It is not perfect but it is a huge difference. 

Another flavour of this attack can be as depicted below:

We create a payload in the form of an executable(payload.exe). Then we use certutil to encode it to a specific binary. For example, “payload.enc”. Then post the output of the encoding process on Github, Pastebin or other alternative services. The purpose of this procedure is to separate the encoded payload from the stager to avoid detection. Now use the certutil on the target machine to download the content from the remote server (Github/Pastebin). Finally, decode the malicious payload into an executable extension using Certutil and execute it to compromise the Target.

Practical #8: Compromising with Malicious Executable inside ADS

We started our attack with Exploit Development. We used the msfvenom tool to generate a Payload for a Reverse TCP Connection to our attacker machine. We provided the msfvenom with the appropriate LHOST and LPORT. The format of the payload was set to an Executable(.exe) File. We named it “virus.exe”. After successful execution, the file was created in our “/root” directory. Now to transfer the newly generated we decided to use the HTTP Server generated by a Python One-liner. 

Now that the payload is hosted on the server, before executing the payload on the Target Machine, we need to start a Listener on Attacker Machine to capture the meterpreter session that would be generated after the execution of the payload.

This time we will use a different approach altogether. We are going to use the Alternative Data Stream. Alternative Data Stream (ADS) was created by Microsoft to supporting compatibility with Apple McIntosh’s file system. In the Mac, files have a huge amount of metadata in addition to regular data. To save the exe file into ADS, we need to specify the name of the file in whose ADS we want to save another file, then (:) followed by name and extension of another file. As shown, we saved the virus.exe inside the ADS of harmless.txt file.

Here, it can be observed that there is no file named virus.exe in the directory and the size of harmless.txt is 0 as well as it contains nothing as it was an originally an empty text file.

Now to execute the file that we put in the ADS; we will be using wmic. We will use the create flag followed by the path of the payload as shown in the image. It says that the Execution was successful.

We went back to our Attacker Machine to see that a meterpreter instance is generated and captured by our listener. We run sysinfo to see the details of the Target System.

We have successfully Compromised the Target Machine using a combination of Certutil and a Malicious Executable concealed in Alternative Data Stream.

Mitigation

As tools like certutil can be used by an attacker with physical access to the machine or by malicious code unknowingly downloaded by a user after a phishing or other social engineering attack.

Certutil usage should be monitored, particularly if detected it being used with -decode or -decodeHex options where that would not normally be expected in your network. It is paramount not to depend on tools that simply whitelist built-in or signed code as obviously these will be bypassed by such Living Off the Land (LOL) techniques.

Conclusion

This kind of attack is very much happening in real life. There have been multiple incidents targeted to different office environments as well as banks. It was a fun learning experience working with certutil. We are going to write more articles about other LOLS that we could find. Stay Tuned.

Certutil Operations

Living Off Land binaries

Author: Pavandeep Singh is a Technical Writer, Researcher and Penetration Tester. Can be Contacted on Twitter and LinkedIn

Recently I had the pleasure and honour to be asked for adding my review for the Hands-on Red Team Tactics– A Red Team Edition book. As this book is published in September 2018 thence it covers all latest track of evasions and attacks.

I appreciate the great effort has been done by “Himanshu Sharma” who is an Indian Ethical Hacker and has already achieved fame for finding security loopholes and vulnerabilities in Apple, Google, Microsoft, Facebook, Adobe, Uber, AT&T, Avira, and many more with hall of fame listings. And, “Harpreet Singh” who has more than 5 years experience in the field of Ethical Hacking, Penetration Testing, and Red Teaming. Harpreet is an Offensive Security Certified Professional (OSCP) and Offensive Security Wireless Professional (OSWP).

Adding Especial Thanks to “Raj Chandel” and “Aarti Singh” for assisting me to comprehend the concept of red team operation in a most effective way.

While reading this book I found it has covered some very advanced and useful tools for performing red team practice that I generally use while performing red team operation, therefore, I feel this book is virtuous resource for those who wish to enhance their skills from traditional VAPT.

Book Overview

Red Teaming is used to enhance security by performing simulated attacks on the organization in order to detect network and system vulnerabilities. Hands-On Red Team Tactics starts with an overview of pentesting and Red Teaming, before giving an introduction of few of the latest pentesting tools. You will then move on to exploring Metasploit and getting to grips with Armitage. Once you have studied the basics, you will understand Cobalt Strike basic, usage and how to set up a team server of Cobalt Strike.

You will discover some common lesser-known techniques for pivoting and how to pivot over SSH, before using Cobalt Strike to pivot. This comprehensive guide demonstrates the advanced methods of post-exploitation using Cobalt Strike and introduces you to Command-and-control servers (C2) and Redirectors. All this will help you achieve persistence using Beacons and Data Exfiltration, and will also give you the chance to run through the methodology to use Red Team activity tools like Empire during a Red Team activity on Active Directory and Domain Controller.

By the end of the book, you will have learned advanced penetration testing tools, techniques to get reverse shells over encrypted channels and processes for post-exploitation. In addition to this, you will explore frameworks such as Empire which include maintaining persistent access, staying untraceable, and getting reverse connections over different C2 covert channels.

 Key Features

• Target a complex enterprise environment in a red team activity
• Detect threats and respond to them with a real-world cyber-attack simulation
• Explore advanced penetration testing tools and techniques

Who this book is for?

Hands-On Red Team Tactics is for you if you are an IT professional, pentester, security consultant, or ethical hacker interested in the IT security domain and wants to go beyond Penetration Testing. Preliminary knowledge of penetration testing will be beneficial.

What you will learn

• Get started with red team engagements using less common methods
• Explore a variety of post-exploitation techniques
• Get acquainted with all the tools and frameworks included in the Metasploit framework
• Discover how you can gain stealth access to systems via red teaming
• Understand the concept of redirectors to add further anonymity to your C2
• Work through a range of uncommon data exfiltration techniques

What this book covers?

Chapter 1: Red-Teaming and Pentesting, helps you understand about different standards of pentesting followed across the industry, and we went through the seven phases of the PTES standard in detail.

Chapter 2: Pentesting 2018, introduces you to MSF Payload Creator (MSFPC). We will also look at the use of resource files which were generated by MSFPC besides the payload file.

Chapter 3: Foreplay – Metasploit Basics, illuminates about team server and the Armitage client, including the setup and usage of Armitage.

Chapter 4: Getting Started with Cobalt Strike, starts by exploring the red-team exercise as well as the concept of the cyber kill chain, which can be used for an attack plan. The chapter then introduces you to Cobalt Strike, the tool that is used for red-team operations.

Chapter 5: ./ReverseShell, explores what a reverse connection and reverse shell connection is using various tools. Furthermore, we will endeavour different payloads to get reverse shell connections using Metasploit.

Chapter 6: Pivoting, dives into port forwarding and its uses. We will also learn about pivoting and its uses, followed by methods of port forwarding via SSH.

Chapter 7: Age of Empire – The beginning, introduces you to Empire and its fundamentals.

We will also cover the Empire’s basic usage and the post-exploitation basics for Windows, Linux and OSX.

Chapter 8: Age of Empire – Owning Domain Controllers, delves into some more advanced uses of the Empire tool to get access to the Domain Controller.

Chapter 9: Cobalt Strike – Red Team Operations, enlightens about the listener module of Cobalt Strike along with its type and usage.

Chapter 10: C2 – Master of Puppets, provides an introduction to command and control (C2) servers and discussed how they are used in a red team operation.

Chapter 11: Obfuscate C2s – Introducing Redirectors, introduces you to redirectors and the reason why obfuscating C2s are required. We have also covered how we can obfuscate C2s in a secure manner so that we can protect our C2s from getting detected by the Blue team.

Chapter 12: Achieving Persistence, dives into achieving persistence using Armitage’s inbuilt exploit modules, then we will learn how to do the same via Empire on Windows, Linux, and macOS machines.

Chapter 13: Data Exfiltration, exhibits some basic ways of transferring data using simple tools like Netcat, OpenSSL and PowerShell. Next, we jumped into transforming the data using text-based steganography to avoid detection, as well as looking at the usage of the CloakifyFactory tool.

This book is available on Amazon you can buy this from the link given below :

https://www.amazon.in/s?k=B077LW1T22&i=stripbooks&_encoding=UTF8&shoppingPortalEnabled=true

Author: Geet Madan is a Certified Ethical Hacker, Researcher and Technical Writer at Hacking Articles on Information Security. Contact here

In this post you will get to know all about RED TEAM Operation and Practice, idea for this article came from the SANS SEC564 by Joe Vest and James Tubbervile.

Introduction to Red Team

Red Teaming comes under the level of assessment in the information security domain. Red Teamers have to identify the risk to the network infrastructure of an organisation as a measure of pre-evaluation so that the execution of engagement can be carried properly. In order to determine such risks, it is the primary responsibility of Red Team operators to recognise potential threats or vulnerability. Various tools, whether open-source or commercial, can be used by Red Teamers to acknowledge vulnerabilities and to exploit them to their advantage. However, the Red Teaming approach is more in-depth than what most potential attackers follow because they are attempting to find a single vulnerability, whereas security professionals need to find all possible vulnerabilities for a given infrastructure in order to assess the associated risk. Attackers typically only target a single vulnerability for a specific exploit because to do otherwise would increase the possibility for detection. Nevertheless, Red Teaming should test for all types of attacks to provide a complete security assessment. Appropriate situational awareness of security infrastructure is a result of detailed Red Team research. But the process of Red Team will not be sufficient in identifying risk; the organization should continue maintaining the security measures from their end in order to appropriately manage risk and provide security protection.

What is the Red Team?

Red Team is a group of highly skilled pentesters that are summoned by an organization to test their defence and improve its effectiveness. Basically, it is the way of utilizing strategies, systems, and methodology to simulate real-world scenarios so as to prepare and measure the security defences of the organisation. The objective of the Red Team is to simulate the real-world attacks in order to measure the organization’s defences and their incident response Team. Red Team follows the Roles of Engagement (RoE).  

What are the aspects of the Red Team?

• Threat Emulation
• Operational Impacts
• Comparing Red Team Engagement to other security testing types
• Red Team Operator Traits

Threat Emulation: This is the process of mimicking the TTP’s of a specific threat. Emulation can be done of various attacks such as – zero attacks, script kiddie to the advanced adversary or a specific threat like botnets, ransomware, DDOS, etc. No matter what the scenario, the TTP outline by the scenario drive the rules a Red Team must follow to perform an engagement. When creating the threat emulation scenario, that threat’s key component should be defined. When in Practice it can be difficult to simulate the real-world scenario in an exact manner. Therefore, the main focus of the Red Team is should be on the key component and then use their own TTP to fill in the gaps. The biggest challenge in threat emulation is simulating the threat to a level where an analyst believes the threat is real, Approaches range from using real malware to developing custom malware that models a real threat, to using tools that generate the indicators of compromise (IOCs) an attack from a real threat leaves behind. In any case, effective planning and determination of the critical components of a threat will lead to better threat emulation design.

Operational Impacts: Operational Impacts are actions or effects performed against a target designed to demonstrate physical, informational or operational weaknesses in security. These effects can be as general as performing a denial of service attack or more specific such as using high jacked ICS equipment to control a city’s power grid. It is operational impacts that distinguish Red Teamer from others. Operational Impacts can be very effective in demonstrating realistic impacts against a target. The level of depth and of the impact can be as ‘painful’ as an organization is willing to explore. These impacts are typically performed against live production systems to have the highest level of fidelity but can be executed on test and development environments if they are representative systems.

Comparing Red Team Engagement to other security testing types

Difference b/w Pentesting and Red Team: Pentesting is used to monitor control and identify vulnerability in order to secure them along with testing the efficiency of the vulnerability management process. It further helps to lay the foundation for security policies. Basically, Pentesting is testing the security environment of infrastructure in order to find and patch vulnerabilities in a limited span of time, so that we can eliminate the false positive scenarios. In comparison to Red Team, Pentesting is the most rigorous and methodical testing of a network, hardware or application. During Pentesting, the pentesters search for vulnerabilities, analysis them and exploit them. Penetration tests are well defined and usually takes up to one to two weeks for the whole process.

Red Team includes tactics, techniques and procedures (TTPs) by adversaries. Red -Team is just like Pentesting in many ways but it is more targeted. A Red-Team overall accesses and evaluates various areas of security through a multi-layered approach. The mission is to present real-world scenarios and hard facts in an attempt to improve the company’s response. Every area of security defines how the target will respond or how it is accessed. It follows the concept of defence in depth; therefore, the target must be tested on each layer. The goal of the Red Team is to not find as many vulnerabilities as possible but to test the detection and response capabilities of infrastructure along with their security environment.

Difference b/w Read Team and Vulnerability Assessment: Vulnerability assessment is the process of analysing of a system that focuses on finding the vulnerability and prioritizing them by risk. Validation or exploitation of a vulnerability is not performed during while vulnerability assessment. When compared to Red Team engagement vulnerability assessment doesn’t take priority. A Red Team may not use any vulnerabilities. They may generate an operational impact that any insider can perform to test the response of an insider attack. Red Teams rarely if ever run common vulnerability assessment tools as they are loud and generate more traffic than a typical Red Team engagement is willing to accept.

Difference b/w Red Team and Blue Team: Red Teams are the attackers whereas Blue Teams are the defenders. Red Team members are adept at all forms of digital attack, as well as social engineering and other methods to find ways to break into the systems of a company – but they are bound by employment agreements or legal contracts to not disclose what they find to anyone but the company that is being tested. While Team almost always works as employees of the company that is undergoing the testing, and are usually members of the IT Security or Data Security divisions of the company’s IT group. Blue Teams have two major areas of operations. Their only focus is to find the vulnerability and patch them as it seems fit. They can also keep providing security during the Red Team engagement.

Red Team operator traits

An effective Red Team is comprised of a team of individuals who can contribute the overall success. Diversity is crucial, but the Team as a whole must be comprised of the core operator traits. A Team can be even more successful when multiple Team members contribute in multiple areas.

Core Operator Traits :

Red Teams are given opportunities to touch and manipulate target networks in ways typically only done by real threats. Full-scale Red Team operations can allow Red Team operators to really put on their bad guy hats, engagement can be very intellectually stimulating and enjoyable for an operator, but operators must respect target organizations. A great deal of trust is placed on an operator. It is common for a Red Team to position themselves to do serious damage or embarrassment to an organization. And with all this, each Red Team operator should comply the following:

• Executes engagement requirements as directed
• Complies with all laws, regulations, policies, programs, and Rules of Engagement
• Implements the Team’s operational methodology and TTPs
• Identifies and has input to target environment deficiencies
• Researches and develops new exploit tools and tests tools for functionality
• Performs Open Source Intelligence as required for the engagement
• Identifies and assesses actions that reveal system vulnerabilities and capabilities
• Assists the Red Team Lead in development of the final engagement report
• Performs Physical Assessment support under the direction of Red Team Lead

Why do we need Red Team?

To challenge the extend of an organisation’s defences so that when and if a real attack happens then they stay protected or come up with a counter measure. For example, a group of hackers has a goal of stealing critical data from a target. A targeted phishing attack tests the end user’s awareness of the attack. The payload of the attack tests the network and host defences against delivery of malware and ultimately code execution, If the attack does trigger a defence, the response tests the defender’s actions in identifying, responding or stopping the attack. In any case, the entire scope of security defence is analysed. A highly skilled Red Teamer can tune their attacks to identify where the failure points are by turning up or down that ‘volume’ of an attack.

Red Teams are able to execute custom threat as part of their engagement. It can test a subset of security of new threat type or validate the effectiveness of security controls against a new or specific threat types. Threat emulation scenarios are a valuable distinguisher of Red Teaming from other types of security assessments and can be used to understand how an organization stands up to new zero-day attack.

Working of Red Teamers?

Red Team tactics contains a full scope, multi layered diverse attacks to simulate real world attacks to measure the security alignments that are applied. Assessments of Red Team starts with reconnaissance to collect as much information as possible about the target in order to determine the way best way possible to exploit it. This collecting of information also helps to build attacking environment and selection of tools. Most of the working of Red Team is on offensive side rather than defensive. Once the remote access to exploited system is managed and stabilised, the actual attacking takes action.

What is the specialization of Red Teamer?

Red Teamers must understand and be an expert in a diverse set of technologies such as :

• Different operating systems and software packages
• Diverse networking protocols
• Custom applications and protocols
• Physical security defences
• Social interaction
• Custom or specialized technologies
• System Engineering
• Networking
• Software Development
• Physical Attacks

Red Teaming Operations Modules

Methodology of Red Team

What are the Pre-Engagement Data Requirements?

The pre-engagement data requirements are :                                                                                              

• Target POC list
• Notification Requirements
• Threat level
• ROE
• OSINT
• Analysis of Potential Attack Vectors and Tools

What is a Red Team Standard Attack Platform?

A standard attack platform is the common set of tools and hardware used by a Red Team to perform an engagement. The term standard is critical. Using a standard platform allows for:

• Better Logging: A common platform shares the same base build, directory structure, and built-in data capture capability.
• Easier Deconfliction: A common set of tools and payloads, along with standard logging, can help an organization quickly work through the deconfliction process.
• Common Baseline: A common base provides a stable, functional environment for a Red Team to operate.

• Access to Better Toolset : A shared platform is built from the knowledge of many people. The best tools, references, and guidelines can be contributed from multiple senior Red Team members to include their expertise in the toolbox.
• Custom Tools Work Across Attack Platforms : Red Teams often build tools. If these tools are built to work on a standard attack platform, they will work for all Red Team operators.
• Tool Vetting : In some cases, a Blue Team or customer requires tools to be vetted as threat faithful. When using a standard attack platform, a tool vetting process is often required before including a tool. This way, all tools are managed and validated before use. Tool validation is often due to a fear the Red Team tools may cause damage to a system.
• Consistent Processes : Using a common baseline help enable a common set of processes. A common set of processes can allow the skills and knowledge of senior operators to be used by junior operators. This can greatly enhance an engagement’s success and better use limited resources.

What are Red Team engagement roles and responsibility?

White Cell : A white cell basically enforces the rules of the engagement to ensure neither Red Team nor defender activities cause unexpected alerts or problems on the target environment. It helps to co-ordinate activities to ensure engagement goals.

Engagement Control Group : It represents the management of target environment as well as provides required information that is necessary for constructing valid scenarios. Also, it helps to establish blacklist if its needed.

Physical Access Team :  The sole purpose of Physical Access Team in Red Team is to enter gates, buildings, offices, server rooms, etc. along with demonstrate physical access to systems and network in order to gain access to devices or anything desirable.

General Guidelines for Red Teaming :

• All Red Team members are responsible for safeguarding all customers data. This said data includes Personally Identifiable information (PII), Industry BBP.
• Red Teamers should work under Privacy Act Information.
• They should avoid data mining of files containing privacy act, medical, justice, worship or religious pursuit or any other protected or privilege information.
• Red Team is normally authorised to exploit files, e-mail and/or message traffic stored on the network or communications transiting the network including everything else. However, each Red Team member should ensure that all the information exploited is necessary and within the scope of engagement.
• Red Team should not be modifying the data found or conduct DDOS unless it’s specifically requested. As it is required of the Red Team to not otherwise intentionally degrade or disrupt normal operations of targeted system being exploited.

How to handle client data?

Client data should be handled with extreme care. The information collected during an engagement can be misused if fallen in wrong hands.

Permission :

The ROE should identify permissions for Authorization :

• Actions
• Data Collection
• Data Leverage
• Target Space
• User Groups

Policy Controls :

It is implemented by the Red Team and it includes :

• A Red Team non-disclosure agreement
• Data training which means identifying and avoiding PII, PA data, etc.
• Ethics training
• Individual Background Checks

Physical Controls :

There should be multi-layer of physical controls applied to protect the engagement tools and operating system from any kind of loss. Therefore, Red Teamers should be accustomed with physical controls that are in place. Such security mechanisms include :

• Tools, computing systems and costumer data be stored inside isolated room secured with cipher lock and controlled only by Red Team.
• Minimize contact between the Team and external entities.
• When not in use, all data and equipment should be removed and placed into lockable cases, safes or storage cabinets.
• During travel, laptops, and hard drives are secured at all times.
• All visitors to Res Team space should be escorted and signed in and out.
• Customer data should only be handled by Red Team personnel with need to know.
• During off-site engagement, data should be encrypted for transmission.

Software Controls :

The following software controls are designed to ensure the confidentiality, anonymity and safety of information should always be employed in whatever context :

• Each host and guest operating system should be encrypted and protected with a strong password.
• Each host and guest operating system should be employed with a host-based firewall specific to the engagement.
• Data and tools utilized during an engagement should be stored in an encrypted container and moved to the working directory only when needed.
• All Red Team tools and software should be removed from the target environment at the end of the engagement.
• All access, movement and use of data and tools should be added to the OPLOG (Operations Logs).
• If a tool is not needed then it should be removed from the environment.

Common repository :

• A common repository should be made available to all the Red Teamers assigned to engagement.
• It should be stored within an encrypted volume
• It should always be encrypted volume lives on centralised server/NAS/file share
• It should be mountable or accessible only after authentication
• Repository layout should be in Hierarchy.

Data Collection

Data collection is the core of every engagement. Data collection is directly proportionate to the success of engagement. in other words, the collection of data drives the value of the engagement. Data collection should be complete with the enabling of replication of activities and results. It should also help you to identify the items of significant interest to the operators. Final Data sets should include :

• Pre-event data
• Execution data
• Operator logs
• Automated data collection and logs
• Screenshots
• Post event data (data archive, closeout brief, final report)

Execution data requirements

Under this, the Team has to make sure that all data that is being handled is safely logged. All activities related to Red Team operations should be logged as the engagement begins and only terminates after all the activity related to the engagement is completed. The events that should be logged are :

• Scanning activities
• Exploiting events
• Stimulation efforts
• Deconfliction discovered
• Target information discovered
• Target acquired and lost
• System events
• Login attempts
• Credentials captured
• Credentials used
• File system notifications
• Modification or disabling of security controls
• Modifications or suppression of security alerts or logs
• Methods of persistence employed
• Methods access
• Methods of access
• Methods of persistence employed
• Command and control channels established
• Request to increase, decrease, pause activity
• ROE conflicts, request and modifications

Operator Logs

As stated earlier, all the activity should be logged accurately and concisely. at the very least, the following information must be collected and logged for each action performed :

• Start Timestamp (UTC Recommended)
• End Timestamp (UTC Recommended)
• Source IP (Attack/Test System IP address)
• Destination IP (Target IP Address)
• Destination Port (Target Port)
• Destination System Name
• Pivot IP (if applicable, list IP of any system used as a pivot, port forwarder, etc.)
• Pivot Port (if applicable, list send and receive ports leveraged in pivot system)
• URL (Note, it is important to capture the FULL URL of the Target instance)
• Tool/Application
• Command (Full command)
• Description (why or for what purpose was the action was performed)
• Output
• Result
• System Modification (Modified file, dropped binary location, enabled functions, etc.)
• Comments
• Screenshot
• Operator Name

Also, when creating log entries, documenting actions, uploading/downloading files, dropping binaries, etc. It is recommended to document this in the YYYYMMDDHHMM_IPDescription format.

Automated Data Collection

Where ever the chance, the Team should use tools and scripts available to capture and consolidate engagement data. Data collected by automated tools will never be enough for Red Team. However, if employed properly, complements the Red Team workflow and enables the operator to continue operations with the manual capture of data pertinent to the activity performed.

Terminal logs

All Red Teams engagement systems should have automated collection of raw terminal data. Each command should be prefixed with operator’s IP and UTC timestamp. It is more important that data is accurately captured rather than being captured in a novel way.

Commercial tools

Most tools used for Red Team have some level of logging the activities, but the location of logs that will be maintained is different depending on the tool and many of them requires for the operator to trigger log generation. In any case it is quite handy to use commercial tools.

Consolidation

Daily transfer of these logs to the engagement repository is recommended. Preference should be to create a backup script that copies each set of logs to the repository when executed at the end of the day.

Screenshots

Details concerning Red Team actions are often met with disbelief. Even when the Team has undeniable evidence of access to a highly restrictive network or physical area, target personnel sometimes have issues conceding access was obtained. And so, provide the proof whenever required.

What is Red Team Engagement flow?

The Red Team engagement flow is a dynamic process but can be managed through distinct steps. the flow of Red Team includes 

 

Engagement planning starts when first contacted by the customer and realistically doesn’t end until the day of execution. Engagement determines the objectives of the working of the Team. Engagement planning includes :

• Rules of engagement
• Management risk
• Threat Planning
• Deconfliction Process
• Costs and Funding

Rules of Engagement : The rule of Engagement establishes the responsibility, relationship and guidelines between the Red Team, the customer and the system owner. This Rules of Engagement drives the whole process of execution. Rules of Engagement includes :

• Authorised Actions
• Explicitly Restricted Actions
• Authorised Targets and Target Space
• Restricted Items
• Engagement Objectives

The Rule of Engagement document consist of Red Team methodology with detailed description of activities and execution process along specification of the hardware and software to be employed. It also includes deconfliction process with the mention of threats available and their comparison. It also must include identification and references to appropriate legal requirements along with the legal responsibility disclaimer. Task of each Red Teamer must also be documented along with the whole information of the target. This information of the target has organization name, address, specific groups or divisions, organizational identifiers, senior management contact info. 

Pre-coordination is the base of successful engagement. To construct an effective plan, the Red Team must understand the target environment, all stakeholders, and any addition legal and contractual requirements of the target environment.

Management Risk : It is a process of identifying, accessing and controlling that risk that comes from the engagement factors. The main aim of managing risk to remove unnecessary risks instead of eliminating all of them, along with implementing efforts that are outlined in ROE without causing any irreversible damage to target environment. It is the responsibility of Red Team to implement risk management and accepting all the risks at an initial stage. Risk Management is important to Red Team engagement as it helps to conserve resources, avoid unwarranted risk, making alternative decision when required and taking effective control measures. The Risk management process includes :

• Identify potential issues
• Assess each risk to determine the direct impact to the target environment
• Develop controls designed to mitigate risks
• Make a risk decision
• Identify Residual risk
• Continually assess

Risk Evaluation under Management Risk

Evaluation is often visualized by constructing a Risk Assessment Matrix. This matrix is commonly used to estimate the degree of severity and probability for each potential vulnerability.

Standard 3×3 Vulnerability Risk Matrix Example:

Probability: The likeliness that an event will occur

• Low — Unlikely
• Medium — May result in
• High – Likely

Impact: is the expected result of an event (degree of injury, property damage or other mission impairing factors) measure as:

• Low — Restricted Impact on Operations
• Medium — Measurable impact on Operations
• High — Important Impact on Operations

Standard 5×4 Vulnerability Risk Matrix Example:

Probability: The possibility of occurrence of an event

• Frequent – Occurs often
• Likely – Occurs several times in x period
• Occasional – Occurs sporadically
• Seldom – Unlikely, but could occur
• Unlikely – Probably will not occur

Severity: is the expected result of an event (degree of injury, property damage or other mission impairing factors) measure as:

• Catastrophic Direct impact, Rustically long duration if not permanent
• Critical —Significant Impact, Stops or Halts operation
• Moderate — Noticeable loss, Reduces/Slows Operation/Production
• Marginal — Limited loss, noticed but does not halt operation
• Negligible — Some loss, Unnoticed if not monitored closely

The key in the above matrix construct is vulnerability; however, Red Teaming is not vulnerability focused. Given that thought process, the Red Team’s alternative risk matrix should be constructed to determine the risk of potential threat actions.

Threat Planning

It is a major factor in Red Teaming engagement. In this stage following information is obtained from the customer and OSINT:

• Threat Information (Landscape TTPs)
• Threat to the Target Environment (OSINT)
• Threat to the Target Environment (Customer Issues, Previous Grievances)
• Real world example of threat
• Threat in Engagement condition
• Level of Threat
• Target Data

The realism of threat must be taken under consideration by the Red Team. It is the job of Red Team to select attack types and strategies to simulate realistic threats even if the organization decide not to unleash the full capabilities of the threat. Defining threat-based attacks will provide a viable mechanism for training the target audience and strengthening the target environment. In order to outline the initial list of attacks the Red Team to carefully weigh the different options in regard to the engagement.

The end goal of threat planning is to portray the threat as real as possible in order to protect the organization from the real attack.

De-confliction process

De-confliction allows Red Team to clearly identify which activity is to be and not be generated by them. The said activity includes both network and physical activities. In this stage of engagement is to be able to distinguish between Red Team activity and real-world attack as quickly and as correctly as possible. deconfliction process includes :

• Ensuring trusted agents understand the actions and impacts of activities as they occur.
• All OPLOGS are accurately and thoroughly completed.
• Providing OPLOGS and activity list to the ECG as requested
• Exchanging periodic situation reports with the white cell.

When the De-confliction is requested it is the duty of the Red Team lead to assess the information and isolate the information from Red Team activity. This includes:

• Halting all activities in the area of the incident
• Reviewing the ROE for limitations, objectives and dc-confliction instructions
• Reviewing OPLOGS to determine activities the Team was conducting at the time indicated
• Confirming or Denying Red Team activities for each deconfliction incident
• Confirm findings with the ECG, White Cell, and TA.
• Ensure findings are relayed by e-mail as well as by telephone
• Maintaining records of de-confliction information, actions, assessment and findings
• If assessment indicates the Red Team is the originator:
• Determine and isolate the specific activities and scripts employed
• Determine and isolate the specific logs supporting the timeframe of the incident
• Notify the Engagement Control Group

The engagement planning process should include the estimate amount of time required to properly execute the De confliction process and when to use it.

Free play is an excellent concept to greatly enhance the results of A Red Team engagement. This concept allows the time to deviate from plan in order to explore for interesting operations. A Red Team lead can always provide guidance to freely explore as time allows them to.

Engagement Execution

Halting an engagement simply means pausing current actions for a certain span of time. It is important to decide and plan the conditions where a pause is required. In following conditions, a HALT is required:

• Deconfliction request are received
• Real-world issues impact the target environment
• Key personnel suddenly become unavailable

A SITREP (Situation Report) is generally performed by Red Team lead. It is to be maintained at all times. And it should contain the following information:

• Current location of operation (systems/networks for network Teams or buildings/offices for physical Teams)
• Information pertinent to the objectives of the Team
• Information key to the success of engagement impacts
• Updates or modifications to the ROE
• Recent actions of each Team member
• Current action of each Team member
• Intended future actions of each Team member

Detailed methodology of Red Team

• Reconnaissance
• Perform Open Source intelligence (OSINT) against the target
• Search using open unauthenticated sources
• Target websites
• Social Media
• Search engines
• Public Code repositories
• Alternate target sites
• 8 External Enumeration
• Identify external assets
• Perform reverse DNS scan to identify registered hosts
• Identify URLs and other external touch points from scan and OSINT
• Web presence evaluation
• Browse as a normal user through a web proxy to capture intelligence and understanding
• 8 Identify known vulnerabilities and vulnerable conditions
• Do not send attack code at this time
• Execution and Exploitation
• Attempt to exploit targets based on current knowledge
• Perform situational awareness on target
• Attempt Local Privilege Elevation
• Attempt Domain or other system level Privilege Elevation
• Post-Exploitation
• Continue internal and Domain enumeration
• Identify domain user/groups/memberships
• Identify IP space
• Identify file shares
• Establish persistence
• Use persistence plan to place agents on target systems
• Move Laterally
• Operational Impact
• Perform realistic stimulation against target systems
• Does not need to be highly complex
• Does not need to leverage known or traditional vulnerabilities
• Does not always require administrative (local/domain) privileges
• Does require actual impact to the target environment
• Does require input from the ECG and TA (during planning)
• Do notify the ECG and TA when the operational impact is executed to avoid unwanted (possibly
• catastrophic) defensive actions
• Does need to exercise the target’s detection, incident response, continuity, and recovery plans and procedures at a minimum.

How to End the Red Team Engagement?

After the execution of engagement is done, it is very important to systematically end the Red Team Engagement. Some of the important things to remember when ending the Red Team engagement are reverting modifications, executive out brief and tech on tech sessions.

Once the execution of Red Team is done with, all the tools, artefacts, exploits and persistence mechanisms should be auto destroyed by a self-destruct code written as both time-based and target-based; for it to be able to prevent execution outside the engagement window or to prevent exploitation outside the target environment. And for all the things that could be self-destroyed, it is the responsibility of Red Team to essentially remove it from the environment.

In the event that target system security controls were disabled:

• Restore the controls as soon as possible
• Test the control to ensure restoration
• Notify the TA of any security control that does not effectively restore

In the event that target system modifications were made:

• Revert file system modifications
• Remove access mechanisms and/or backdoors
• Remove C2 and persistence mechanisms
• Terminate C2 Channels

For all restoration actions:

• Ensure file artefacts generated by the mechanism are removed
• Examine entire system to confirm the mechanism was not inadvertently copied or moved
• Remove or restore registry keys if used
• Restore modified files
• Remove or replace launch files with original
• Examine start-up scripts if used.
• Remove execution mechanisms
• Remove installation mechanism
• Copy log files generated by the mechanism to the Red Team repository and remove them from target system
• Continue connection monitoring for stray or missed mechanisms
• Repeat process for strays
• Provide a list of all artefacts, names, hashes, locations, and clean-up status to TA

Executive out brief is a meeting dedicated towards impact of Red Team engagement on the organization and how to protect it. In this meeting, Red Team lead has to highlight critical observations made during the engagement along with additional information security or technical staff. Legal staff and critical system information’s can also be included with the observation of ‘where the organization is vulnerable’.

A tech on tech briefing can be extremely valuable to the organization as it provides bi-directional exchange of information between Red Team and blue Team. During this exchange, both the Red and defensive elements provide a highly detailed step-by-step technical review of the actions and results (including all associated detail) of the engagement.

The role of Red Team during tech-on-tech:

• Explains Red TTPs and intended lOCs
• Their initial thought process for meeting engagement objectives
• Steps through Red actions and associated activity/commands (This occurs simultaneously to defender walk through)
• Describes why those actions were executed (What lead the RT to that specific action)
• Provides the results of each action and how that action enabled the next
• Provides recommendations or techniques that would limit each threat action

The role of Defensive Team tech-on-tech:

• Has the opportunity to ask the how and why
• Explain the process for securing and defending their environment
• Identify any alerts, triggers, or anomalies within the environment during engagement
• Step through blue actions in response to Red Team activity (this occurs simultaneously to Red Team walk through)
• Identifies how Red Team activity could have been detected, prevented or leveraged
• Provides feedback to Red Team actions and recommendations
• Uses tech-on-tech information to perform post engagement analysis prior to receipt of official report

Report Writing

Reporting is a critical aspect of Red Team Engagement. Reports are major form of evidence that can be analysed and used to provide a base for improving security. Reports are important as they confirm the existence of engagement. Reports not only document the activity that occurred during a specific engagement, but provide an excellent reference that can be used to plan and design other engagements. Many engagements can share similar approaches and goals. Reports can provide a roadmap to design and plan future engagements. Reporting a Red Team engagement can be quite different than reports generated in penetration tests or vulnerability assessments. Red Team engagements are highly scenario focused. This leads to a report that is story driven. Penetration testing or vulnerability assessment reports focus on findings. security tests. Rather than discover that an out-of-date patch can cause successful exploitation of a workstation, a Red Team may use the exploit to deploy a command and control agent. This agent can be used to explore an organization and ultimately steal proprietary organizational data. The Red Team is driven by goals intended to stimulate or measure not only technical flaws but security operations as a whole. This includes people, processes, and technology. A Red Team report will use a story-based format where observations instead of findings are listed.

Report includes various perspectives such as attack narrative. The Attack Narrative section of the report contains the observations made during a Red Team engagement. These are typically written in a chronological format. Key observations that a Red Team uses to achieve goals must be documented. This includes any step Red Team takes to achieve a goal. Threat profiles or other lOCs that Blue can use during post analysis should be included. The end of a Red Team engagement is can be the beginning of post forensic analysis. Blue Teams who take advantage Red Team lOCs by performing post analysis can use this information to find blind spots or tune security tools to better protect against threats.

Report Outline

Types of observation that should be documented:

Key actions that led from initial access to the final goal

• Initial access
• Lateral movement
• Privilege escalation
• Command and Control (C2) description
• Include network information (IP addresses, Domain name, Ports, Protocols, etc.)
• Include agent information (Binaries, Scripts, Locations, Registry Changes)
• Include persistence methods
• Reconnaissance actions and results
• Other interesting observations that assisted the Red Team during the Engagement
• Other interesting observations that may be of concern but not directly related to the engagement

An observation should include the following elements

• Narrative description
• Technical details
• Source/Destination I P addresses
• Tools or techniques
• Results
• Screenshots

Author: Yashika Dhir is a passionate Researcher and Technical Writer at Hacking Articles. She is a hacking enthusiast. contact here