In my blog posts that I wrote 8-9 years ago (Anti Analiz, Anti Anti-VMWare), I mentioned that malicious individuals who develop malware use various methods to make it difficult for security researchers or systems to analyze their malware on virtual systems.
Nowadays, with the widespread use of Virtual Desktop Infrastructure (VDI) technologies in corporate environments, virtual systems are no longer primarily used by servers or malware analysts, security researchers. As a result, malware developers, and also red team members who perform ethical hacking, aim to design and develop tools that can operate on virtual systems but are not detectable by virtual analysis systems. Knowing that it is impossible to develop a tool that does not work on virtual analysis systems with a realistic approach, malware developers are searching for their malware’s hash values on VirusTotal at certain intervals to understand if they have been detected and to stop their operations. Similarly, red team members who do not want to be caught, use projects like RedELK to ensure the sustainability of their operations.
I have decided to research and share with you how easy or difficult it is to detect these trusted sandbox systems, such as VirusTotal, Any.Run, Hybrid Analysis, Lastline Analyst, VMRay Analyzer, etc. which are commonly used by end-users and security experts to upload files suspected of being malicious.
To do this, I first needed to gather information (reconnaissance) about the sandbox systems. When a software is uploaded to a sandbox system, it is monitored and recorded by the system when it communicates with a target system (C&C) during dynamic analysis. In short, these systems are allowed to have internet connections on them. So, I decided to prepare a Microsoft Office macro that collects information about the target operating system. The easiest way to do this with the macro is to take advantage of the Windows Management Instrumentation (WMI) which is commonly used for lateral movement in targeted attacks (APT). If you do a small research on Microsoft’s website about WMI, you can see that you can collect a lot of information about the target operating system using the Win32 Provider.
To avoid reinventing the wheel, I did a quick search on Google and came across a simple script that collects information via WMI using VBA. After adding 25 classes that are specific to the operating system on Microsoft’s page to this script file, I made it send the information to https://www.mertsarica.com/macro.php. To make sure it cannot be easily detected by antivirus software, I also used the macro_pack tool to hide the macro (obfuscation).
After uploading the Mert-Obfuscated25.xlsm file to Any.Run and VirusTotal, I saw requests coming to https://www.mertsarica.com/macro.php after a short time. When I looked at the incoming requests, I saw that there was quite a bit of information for me to analyze regarding the systems that perform sandbox analysis. :)
While looking at this information, my attention was first caught by the LastBootUpTime value that appeared in the output of the Select * From Win32_OperatingSystem WMI request. This value indicates the date and time when the operating system was last started. Sandbox systems restart the operating system from scratch, in its clean state, before analyzing the malware, so there is a maximum time difference of 30 minutes between the date and time of the operating system’s reboot (LastBootUpTime) and the date and time of the analysis (LocalDateTime). Based on this information, it is possible to assume that the software was analyzed in the sandbox.
As I continued to look at the information I had collected, I came across an output where I noticed a difference of 4 months between LastBootUpTime and LocalDateTime. This raised suspicion since a user system (Windows 7) that hasn’t been restarted for 4 months is quite unusual, so I began to investigate this information more closely. As it is known, most security researchers, malware analysts have an isolated, virtual analysis system. To save time, this analysis system is not restarted each time, but instead, is returned from an instant image (snapshot). An operating system returned from an instant image, LastBootUpTime gradually becomes older, and the time difference between LocalDateTime and it can sometimes be months when a malware is being analyzed. In light of this information, I also checked the WMI section where I suspected that this output had collected information on program groups in the Windows operating system, Win32_LogicalProgramGroup, and this time I saw that the system had tools such as Immunity Debugger, Process Hacker, which are frequently used by security researchers, malware analysts. This gave me the information that my Office file was analyzed by a threat hunter. :)
Lastly, my attention was also caught by the output of the Select * from Win32_SystemBIOS WMI request. When I looked at the information coming from the sandboxes, I saw that one of them was running on the BOCHS emulator and another one was running on the QEMU emulator. Therefore, I understood that these two systems belong to the sandbox system.
Based on the IP addresses that made requests to the macro.php file during the period of time up until October, I can say that these are most likely from VMRay, Lastline, Any.RUN, VirusTotal sandbox systems and a threat hunter’s system.
In conclusion, it does not seem difficult in practice to understand that a developed software, code is running on a sandbox system using the information obtained through WMI, therefore it is important to remember that it is possible for a malicious person or a member of a red team to benefit from this information and the IP addresses, IP blocks of sandbox systems to bypass sandbox analysis.
Hope to see you in the following articles.
Note: Those who are interested can download my presentation file titled “Sandbox Detection” which I discussed this topic in, from the following link, which was presented on November 22nd at the NOPcon International Hacker Conference.