We need many tools for penetration tests and develop our own customized tools. The tools that we will use for Malware Development or Bypassing Anti-Malware products in another approach, without exception, are at the top of these tools. Cyber security is one of the fastest growing industries. The cyber security sector, which is getting deeper and divided into sub-specialties, is developing a number of protection measures for various attack vectors. As a matter of fact, the most important of these developments is that Microsoft Defender is now embedded in Windows 10 and Server 2016 operating systems and in future versions. This is a very important development because Microsoft has embedded Microsoft Defender in operating systems as part of the anti-malware industry. You can access the article we wrote about Microsoft Defender’s success in Gartner Magic Quadran from this link.
Microsoft Defender recognizes all payloads in Metasploit. At the same time, the encryption modules in Metasploit used for encryption of payloads are also recognized by Defender. With a simple example, we can summarize the situation as follows: We have infiltrated several systems using various methods. We also used Mimikatz for Post-Exploitation. We want to use Psexec to leap to other systems by using the account information obtained. Unfortunately, all the payloads we will use at this point will be detected by Microsoft Defender and we will not be able to succeed. For this and many other reasons, we decided to develop tools that we can use in penetration tests and Red Teaming tests. We continue to develop the iSMET tool a long time ago and use it in the tests. We have recently decided to publish this Red Teaming tool, which is still very successful, as open source code.
GitHub: https://github.com/Privia-Security/iSMETv2.0
iSMET is a tool that can use both “asymmetric” and “symmetric” encryption techniques. iSMET is capable of producing a meterpreter agent in application, payload and encryption types in the table below.
As can be seen in the table above, iSMET can produce 8 different encryption techniques and 2 different application types of agents for 12 different meterpreter payloads. iSMET provides encryption support for the most used meterpreter agents. Before going into the details of the encryption modules, we can see the modules used by iSMET in the table below.
| Module Name | Module Detail |
| iSMET | iSMET interface (UI) |
| iSMET.CSharp.Collection | Frequently used function library such as String, Byte, Array |
| iSMET.Encryption | Encryption algorithms library |
| iSMET.Packer | Memory Management and advanced storage function library |
| iSMET.ShellCode | Shellcode library with meterpreter agents |
iSMET needs 4 main modules to work. “ISMET” from these modules is the UI (user interface) that enables the transfer of data from the user to other modules.
The “iSMET.Csharp.Collection” library is used to perform many operations such as randomly generating the password in the “Encryption” library to be used for symmetric encryption at runtime, converting the byte arrays to string type, or creating a random file name.
The “iSMET.Encryption” library provides the use of encryption algorithms such as DES, TripleDES, RC2, Rinjdael, RSA, AES-CBC and Blowfish. The “iSMET.ShellCode” library is a dynamic library containing the meterpreter and shell (cmd) payloads in the table above. Thanks to this library, the IP and port information of the pest we want to create is dynamically changed and transmitted to the Compiler library via the application interface, creating a meterpreter or shell agent.
As seen above, iSMET consists of a simple interface. The interface is a Windows Presentation Foundation project based on “Modern UI”. The IP address section represents the IP address for reverse connection, and the port represents the port number for reverse connection. The section specified as Type indicates which application type the malware to be created should be created. If Console Application is selected, it will create a payload that runs within a classic console application. If Windows Form Application is selected, it will create a payload that runs in Form Application type for Windows. Both techniques have their own advantages and disadvantages. For example, if a payload of Console Application type is created and the application is run on the target, payload will run on a black console screen as if a classic cmd.exe was running. When Form Application is selected, payload will run through an application that hides itself in the background. The probability of both types of applications being caught by anti-malware products will be different.
MeterpreterShellCode class in the iSMET.ShellCode library is the library that contains the main functions that the application needs to create meterpreter and shell agents. In this library, many meterpreter and shell agents such as ReverseTcp, ReverseTcpRc4, BindTcp are stored in both x86 and x64 formats. Each variable in the class is triggered with a string IP and also a string type port information.
IP and port information transmitted to each meterpreter and shell agent is changed dynamically in shellcode and the shellcode is re-created from byte array type and forwarded to the compiler. As you can see in the example above, there is a 283 byte shellcode of the meterpreter/reverse_tcp payload. In this 283 byte array, a calculation is made to dynamically change the IP and port information. 176,177,178 and 179th lines of the 283-byte array created for the Meterpreter agent represent the IP address to which reverse connection will be provided. It is ensured that the dynamically sent IP address is divided into octets and divided into 4 separate parts. Then, the Convert.ToByte method is called to add each octet to its corresponding byte array, converting octets to bytes and changing them in the array. Also, a similar procedure is used for port calculation. The 183th and 184th bytes of the Meterpreter shellcode represent the port. After the port information is dynamically changed in the byte array, the current version of the shellcode is transmitted to the interface from the byte array type.
Note: The string named ReverseTcp in the class named x86ShellString has been added for those who want to develop within the application. The class is not used in any way in the application. It is included in the application so that the developers do not deal with problems such as metasploit and kali confusion and copying every time. Shellcodes created using Non-Encryption, Base64, Rinjdael / AES, DES, 3DES and RSA algorithms are embedded in the executable application (exe) created dynamically by iSMET and sent to the target. The shellcode to be created using RC2, AES-CBC and Blowfish algorithms is written to the file named “Stub.bin”. Separating the Shellcode used by iSMET from the application and writing it to a different file encrypted is a very effective method to bypass anti-malware products.
BuildCode class in the iSMET.Csharp.Collection library consists of 3 separate classes. These classes named Console, Form and Powershell contain codes that allow the creation of C# based exes that will dynamically run the meterpreter malware. The techniques in the Powershell class have not been published publicly, as we currently use them in our Red Teaming tests.
In the example above, there are C # codes belonging to the meterpreter/shell malware that will run using the BlowFish algorithm. iSMET ensures that the dynamically changed and encrypted shellcode data such as password, private key and IV are placed in the C# code, allowing the shellcode to be deciphered in the system where the application is running. The timeOut value in each method in the BuildCode class determines the time out value selected while creating the application.
There is a time out value determined when creating a malware in the iSMET interface. This value is 5000 milliseconds by default. While the application is running on the target system, it suspends the thread that the malicious code will run for 5 seconds at runtime. We can change this value while creating malware. Some anti-malware products consider it harmful for an application to connect to a port or switch a port to listening mode as soon as it is running. The heuristic engines of anti-malware products check this. In addition, we plan to publicize iSMET.Packer and its MemoryFunction modules in another version.
The class named Compiler in iSMET was created to compile the encrypted C# meterpreter codes. The methods named “NetFrameWorkDirectory” and “X64NetFrameWorkDirectory” detect the directory of the C# compiler named “csc.exe” in the .NET Framework. iSMET needs a C# compiler named csc.exe to create malicious software on the system it runs on. The same action can be done with MSBuild. However, we are using the C# compiler named csc.exe. At the same time, csc.exe can be found in many .NET Framework versions, as well as the above methods detect the latest .NET Framework directory and use the compiler in the directory.
After the Compiler directory is detected by the related methods, methods named “Console” or “Form” are used to separate the compiler parameters according to the application type selected over the interface. After both of these methods determine which architecture (x86 or x64) the application to be compiled to compile, C# sends the code to be compiled to the compiler (the method named BuildRunMeterpreter) and transforms it into an executable file (exe).
After the compilation process is completed, it clears the “*.cs” file types created in the working directory by using the “DeleteCsFileInDirectory” method and the application is made ready.
In the class named GlobalVariable, there are constants such as architecture, encryption type and application type that the application needs to run.
The payload named meterpreter/reverse_tcp, which will send a connection to port 4444 of the IP address 192.168.208.128 over the iSMET interface, was created in the Console Application type with the name “oy2a8.exe” using the Blowfish encryption algorithm. The application created has created the shellcode to be run by encrypting it with the Blowfish encryption algorithm into the file named “Stub.bin”. Now let’s examine the virustotal results of both files separately.
The malware we created named “oy2a8.exe” was detected by 6 products. The reason for this is due to the Windows APIs used in the application that enable the shellcode to be loaded into memory.
Calls named VirtualAlloc, CreateThread and WaitForSingleObject are as above. iSMET uses these calls to load the shellcode into memory and run it. Virustotal results are as follows.
The virustotal results of the “Stub.bin” file, which contains the encrypted version of the actual malicious shellcode, are as above. As can be seen, shellcode is not recognized by any product. The virustotal results of the stub file are as follows.