See No Evil, Hear No Evil: A Quest for Zero Detection Spyware
Dr. Glenn Nor
PhD i Datateknologi | Sjefingeni?r | Leder av Intelligent Automasjon & Dataanalyse | Forfatter
1. Background
Back in 2016 I did an experiment to see if I could design and create spyware that would be undetected by popular antivirus software. It began as a question: "how hard can it be?" and escalated into "challenge accepted". Since this research paper is from 2016, you will find references, such as "windows 8.1", and you might think it's outdated, but bear with me, as I believe the discussion, design and results are still relevant.
On this journey, I found other curious minds that became part of the experiment and the discussion: Prof. Iain Sutherland, Assoc. Prof. Tom Drange and Assoc. Prof. Mikhaila Burgess. So before we begin, I just want to give them a thanks!
2. Abstract
Information is money, and the theft of information has quickly become comparable to theft of money. As one of the primary threats for such theft, spyware is an ever-growing problem and has become more aggressive over the years. Today’s spyware rely heavily on the end-user not having certain Antivirus installed and updated, to avoid detection. In this paper we are going to explore ways to avoid detection up to a goal of one hundred percent; be it visual cues from the spyware detectable for the end-user or AV/firewall system detection. Using only Python programming we will create a spyware named “Thanos” and infect multiple machines running different antivirus, and through trial and error programming attempt to reduce detection down to zero.
3. Introduction
There is constant battle between antivirus companies and malware programmers, where new methods are introduced only to be identified and incorporated into the antivirus structure later, and then a new adapted version is created to bypass antivirus; so the process repeats. The time period before antivirus companies can incorporate the signatures into their databases is the timeframe malware can steal information undetected. What we are going to attempt in this paper is to find a way to create a zero detection spyware that does not use a conventional method, so that we can expect AV companies not to find it in the near future. Since we are going to use unconventional methods it will not have the normal signatures as normal spyware.
This experiment is meant to simulate real world industrial espionage, so the zero tolerance detection is important. If the spyware is detected by an antivirus, or by the end-user in some way, it will be considered a failure. To make the experiments as realistic as possible we will only use popular and most used Antivirus software (OPSWAT, 2015) per 2014-2015 and we limit the total number to twenty:
The reason for why we are using such a large variety of antivirus software is because we are simulating espionage in general, meaning it must for example address industrial espionage in China as well as in America.
In order to create spyware, or any computer virus, we have to use certain system functions like “hooks” to monitor keyboard/mouse activity (Yin, Liang & Song, 2008) or “LoadLibraryA” (SANS, 2010) to load a DLL into memory. Since most spyware wants to accomplish the same thing, steal information, they have to share a common behavior, which causes a large number of patterns. These patterns are primarily what antivirus hunt for when running file scans. Finding new ways to do the same thing also results in variation of the same patterns, which antivirus are good at identifying. Methods such as EXE encoders, packers, obfuscation (JPCERT/CC, 2015) or shellcode with hijacked entrypoint (IOActive, 2012) are popular ways to try and conceal these behavioral patterns from antivirus scans. However the methods have become rather obsolete over the years due to antivirus companies catching up and incorporating the necessary identification and decoding procedures (Czumak, 2015).
Antivirus software is dependent on analyzing a file before allowing execution (Xue, 2008), if it does not raise any red flags, it will be allowed to run. If the antivirus does not recognize the source file i.e. does not have a procedure for it in its database, it will treat it much like a text document, running through the code/text and allowing it to pass. Source code files are an example of such files that is not flagged by antivirus. They are not viewed as a threat because they cannot run independently on a computer, and therefore even a malicious source code file would be allowed to pass through an antivirus scan. To weaponize a source code file would then allow it run undetected from any antivirus.
4. Methods
To perform the weaponization process of raw source code we used the follow tools and procedures:
4.1. Tools
Software
Python Modules
4.2. Modifying Python Portable into Python “Ultra” Portable
Python portable is a self-sufficient version of the Python framework, being able to run on any windows machine without any dependencies. The portable version used in this project was a little over 1000 MB in size once extracted to a folder. Our ultra-portable version would need to be at least in the area of one percent of that size, meaning roughly 10 MB for it to be a viable and injectable spyware.
Using a mixture of trial-and-error and python knowledge we then simply started to delete sections we did not need. We only wanted the absolute bare minimum, just enough to allow python to run.
Furthermore, there were many sections that are not mandatory:
After this we had to go into the library section (“Lib”) and manually delete several modules at the time to reduce it. With the exception of ctypes, encodings, logging and site-packages, all folders inside Library were deleted. Last section to minimize, which just happens to be the largest is site-packages inside Library (“Lib”) at a starting size of approximately 860 mb. Leaving the files in this folder, we deleted all folders as they are only addon modules and not dependencies. The new “ultra” portable python was now 22.6 MB.
It is important to remember that we still had to add spyware specific dependency modules, so the total size did increase slightly.
4.3. Creating the Spyware Thanos
For this paper, only a small alpha version of Thanos was created in order to be used as a test. It was a very low-end spyware with only two functions: A keylogger, and data stealer with Secure Copy (SSH) function. In later papers, Thanos could be built more advanced with more high-end functions such as self-replication. Since we were more interested in testing a new approach to running spyware, than the spyware itself, it did not matter how primitive the spyware was, as long as it was able to run undetected. The spyware itself worked like this:
Keylogger
1. PyHook grabs keyboard and buffers keystrokes in chunks of 128 bytes
2. Chunks of 128 bytes keystrokes are encrypted using AES 256-bit cipher
3. Keystroke file “temp.txt” is updated with new chunk of encrypted keystrokes
Data Stealer
1. Test parameters are set to “dropbox” and “PDF”
2. A “search engine” function scans users dropbox file for all PDF files and creates a list
3. Based on the size of the list, it divides the list into groups
4. For every 30 seconds a new group of PDF files from the main list is encrypted and stored in temp folder
Thanos exit function
1. After two cycles of 30 seconds (60 seconds total), the entire temp folder is selected for SCP (SecureCoPy) via SSH to remote site
2. The temp folder is deleted
3. Thanos executes an exit python file; deleting itself
4.4. Testing Compiled Version of Thanos
Since Thanos is a small spyware with only two functions, we were not expecting it to be detected by that many antivirus software. In fact in its compiled form it was only detected by three from our selected list of antivirus:?
Four other malware samples were added to increase the accuracy of the proof of concept (Vermifuge, 2012; Deque, 2013; PrimalSecurity, 2014; Seitz, 2009):
4.5. Preparing Python for Weaponization
Before we could start the weaponization process we had to integrate Thanos into the “ultra” portable python framework and make it injectable. We had to add the modules required by the malware, which in the case of Thanos was: Win32, PythonCom, pyHook, Paramiko, SCP, Shutil and Crypto. This added roughly 8 MB to the total size, making the total new size 30 MB. Our goal was one percent of the original portable python size, and the final step in the preparation stage got us much closer by using WinRAR to compress.?
However before we compressed the file we had make a small adjustment to help conceal the malware during runtime on victim computers. Since we are relying on the malware running in its own process, meaning not injected to another legitimate process, we have to make the malware look good in case someone decides to take a look at task manager or if a firewall prompts the end user. To do this we did some simple executable manipulations, where we wanted our python.exe to look like adobe acrobat update manager:
Step 1: We fetched the original icon to acrobat update by opening the following source file in Resource Hacker:?
C:\Program Files (x86)\Common Files\Adobe\ARM\1.0\AcrobatUpdater.exe
Step 2: We replaced the python.exe icon with the acrobat update icon:
Step 3: We then saved this new executable as “Adobe Reader and Acrobat Manager.exe”?. When running our disguised python.exe we can now compare it in task manager to the real acrobat update process side by side:?
The real process running acrobat update is “Adobe Reader and Acrobat Manager (32 bit)”, process number three from the top. We can see that our python framework is running almost identical in appearance just below it. If a firewall were to ask the end user for permission to connect to the internet now, it would not look that suspicious because the original software would indeed have to do it as well.?
Step 4: Compress the entire folder using WinRAR. The compressed file was now 11.4 MB, making it 1.08 percent of the original.
4.6. Weaponizing Python Source Code
Before we could do anything at this stage, we had to secure a way to allow extraction of the RAR file without the end user having WinRAR installed. We had to use WinRAR Unplugged, a portable version of WinRAR. The total size of WinRAR unplugged is 4.51 MB, which is too big for what we want to do. Fortunately for us, there are separate executables for compression and extraction, and they are both independent in nature. We therefore only required the “UnRAR.exe” file, which is only 241 KB.?
To make this into an injectable and auto-executable file we used “iexpress”. This is a self-extracting / self-installing package creator. The best part of this package creator is that it allows for an install command and a post-install command. In addition to making an executable capable of injecting python to a victim, we also had to make sure the final executable looked legitimate enough for people to run it without suspicion and perhaps most important; the misleading final executable had to work as if it was the original. We did all of this in?“iexpress” leveraging the install and post install commands, and using a legitimate Firefox install file.
The most important thing to notice from figure 10 is step 3:?
Install command:?
UnRAR.exe x THANOS~1.rar?
Post Installation command:?
cmd.exe /c Firefox.exe && timeout 30 > NUL && cd Thanos-Source && "Adobe Reader and Acrobat Manager.exe" MainKey.py
This means the executable will perform five things during runtime:?
领英推荐
1. Extract Thanos-Source.rar to a folder named “Thanos-Source”?
2. Execute Firefox.exe?
3. Wait 30 seconds after Firefox is done?
4. Change current directory to the new extracted folder “Thanos-Source”?
5. Run “Adobe Reader and Acrobat Manager.exe” with argument “MainKey.py”?
Both the WinRAR extraction and the command line window is set to “not visible” from the “iexpress” wizard, so to the end user they will only experience step 2, which is a legitimate Firefox installer wizard. Since we are using the double ampersand command “&&”, each step waits for the previous to finish. This means after firefox is installed or canceled, the thirty?second waiting period begins. The waiting period would be much larger in a real-world implementation because it is meant to remove the correlation between the acrobat update and the firefox install. Starting a firefox installation, that causes an acrobat update is very suspicious, so step 3 would realistically be somewhere in the range of minutes to hours.?
In the same way we altered “python.exe” to use the same icon as acrobat update, we also had to alter the final executable “Firefox.exe” to use the same icon as the original firefox installer file.
Now that the file looks like the original, we had to test to see if it also behaved like the original:
The malware runs identical to the original, with the only exception being that thirty seconds after firefox is done, Thanos is executed as Acrobat Update. For the end user however they seem identical.
5. Results
5.1. Initial Overview
Five executables were tested on five different machines running different antivirus. The files tested were:?
Before the live tests however, all five malware executables were scanned by all twenty antivirus in our list:?
5.2. Live test
In this test we used five computers with the following setup:?
Computer 1
Computer 2?
Computer 3?
Computer 4?
Computer 5?
All five malware files were then copied from a memory stick onto the computer, and executed.?In the following section we will gather the results from each live test computer from the USB being plugged in, to the exit function of the malware.?
Computer 1 - AVG?
Computer 2 - F-Secure?
Computer 3 - ESET-NOD32
Computer 4 - Avast
[1] Program Analysis in AVAST:
Computer 5 - Kaspersky
[2] Autos Scan USB in Kaspersky
Both [1] and [2] successfully passed without incident and the malware was allowed to execute normally.?In the example below we can see how the malware completed its tasks from Computer 2 running F-Secure antivirus:?
After the malware was done and had successfully deleted itself, we could go to the receiving server to see if we managed to steal information from Victim B:?
We can see that all PDF files from Victim B was captured and encrypted, along with an extra file named “shadowdata.txt” which was an encrypted file containing all keystrokes from Victim B’s computer. If we decrypt “shadowdata.txt” we can see if it worked:?
The malware was successful in capturing both dropbox PDF files and keystrokes from all computers (1-5).?
6. Discussion
As new malware is created, antiviruses hunts for its signatures and distributes it to all antivirus clients. In an attempt to survive without modifying the source code of malware, techniques like packers and obfuscation (Smith, 2008) are used. This tug of war between “the good guys” trying to defend its clients, and the “the bad guys” trying to infiltrate with malware, gives most malware a limited timeframe to roam free. After detection those malware will need advanced packers to attempt another infection.?
In this paper we have seen another way of looking at malware; one in which we try to solve the problem of malware limited timeframe by not compiling the source code to an executable. Antiviruses are dependent on malware being in some kind of compiled form in order to detect it. Having a portable and independent IDE (Integrated Development Environment) to run source code directly from memory?means there is no malicious code touching the hard drive. Therefore the antivirus has nothing to analyse, no signatures, no threats to detect.?
We saw earlier in this paper an example of how Thanos could be integrated and hidden in a Firefox installation executable using a few simple techniques. Similarly, but more dangerous, it could easily be integrated onto a BadUSB chip. This would allow automatic infection with administrative rights as soon as the USB is plugged into a computer (Anthony 2013). While it is true that it is difficult to create a BadUSB by exploiting firmware weaknesses like the one found in Phison based USB drives, there are companies providing readymade versions (Hak5, 2016).?
7. References
Anthony, S., BadUSB returns: Hackers publish code that could infect millions of USB devices, 2013, extremetech.com)?
Czumak, M., peCloak.py – An Experiment in AV Evasion, 2015, https://www.securitysift.com/pecloak-py-an-experiment-in-av-evasion/?
Deque, Basic Virus Infection and Polymorphism,2013, https://evilzone.org/forums/topic/321-python-source-basic-virus-infection-and-polymorphism/+&cd=2&hl=no&ct=clnk&gl=no?
Hak5, RubberDucky, 2016?
IOActive, Reversal and Analysis of Zeus and SpyEye Banking Trojans, 2012, https://www.ioactive.com/pdfs/ZeusSpyEyeBankingTrojanAnalysis.pdf?
JPCERT/CC, Understanding Malware, 2015, https://www.jpcert.or.jp/present/2015/seccamp2015_13D_14D_understanding_malware.pdf?
OPSWAT, Antivirus and Compromised Device Report: January 2015, 2015, https://www.opswat.com/resources/reports/antivirus-and-compromised-device-january-2015, [accessed February 18th 2016]?
PrimalSecurity, 0xC Python Tutorial: Python Malware, 2014, https://www.primalsecurity.net/0xc-python-tutorial-python-malware/?
SANS, Getting Owned By Malicious PDF – Analysis, 2010, https://www.sans.org/reading-room/whitepapers/malicious/owned-malicious-pdf-analysis-33443, [accessed February 18th 2016]?
Seitz, J., Gray Hat Python: Python Programming for Hackers and Reverse Engineers, No Starch Press, 2009, Page 44-45?
Smith, S., Revealing Packet Malware, Security Systems, Trend Micro, 2008?
Vermifuge, T., DLL and Code Injection in Python, 2012, https://brindi.si/g/blog/dll-and-code-injection-in-python.html?
Xue, F., Attacking Antivirus, 2008, https://www.blackhat.com/presentations/bh-europe-08/Feng-Xue/Whitepaper/bh-eu-08-xue-WP.pdf?
Yin, H., Liang, Z. & Song, D., HookFinder: Identifying and Understanding Malware Hooking Behaviour, 2008, https://www.internetsociety.org/sites/default/files/yin2.pdf, [accessed February 18th 2016]?