Last March, Roberto Amado and I (Víctor Calvo) gave a talk at RootedCON 2020 titled Sandbox fingerprinting: Avoiding analysis environments. The talk consisted of two parts, the first of which dealt with classifying public sandbox environments for malware analysis, and the second with demonstrating whether it was possible to identify and even attack the person analyzing our samples. This second part is the one that will occupy this entry.
Introduction
During Red Team exercises it is always important to know who you are dealing with, their security measures and who is managing them. At this point we wondered if it would be feasible to reach the Blue Team and to know if our devices had been identified and if they were still useful in the exercise.
With this approach, we focused on malware analysis websites such as VirusTotal, Any.run, Hybrid Analysis… which are continually consulted by analysts to find information on samples or analyze them. The results are displayed on the web interface of these tools, showing useful information for the analysts such as IP addresses or domains to which they connect, commands executed, payloads introduced and a long list dedicated to making the life of the defenders easier.
With this information in mind, our approach was to find vulnerabilities in the web interface of these services in order to identify users. Cross-site scripting (XSS) was the perfect option for this task.
Testing
To carry out the tests we used XSS Hunter which allowed us to perform more powerful actions than a simple JavaScript alert. The payloads we generated with it allowed us to obtain information about who had executed the JavaScript code, take screenshots or even more advanced options such as injecting arbitrary JavaScript code when the payload was executed.
With XSS we had the vulnerability we were going to exploit, but how to do it? We developed a C# artifact in which we introduced XSS Hunter payloads with different approaches such as PowerShell calls, messages displayed by terminal or registry keys. Our aim was to have these strings represented in the browser’s web interface.
Then we uploaded the sample to VirusTotal and waited for results.
The first sandbox to be analyzed was VenusEye. Although VirusTotal’s integrated interface showed no trace of our payloads, when accessing the “Full report” option in the “Behaviour” section, the web page executed the multiple payloads making numerous requests to our XSS Hunter instance:
A couple of weeks after the first scan the sample was analyzed by another sandbox, Tencent Habo. The result was, as in the previous case, that in the “Full report” section our payloads were executed:
A few days passed and the sample was analyzed again with similar results. This time the analysis was performed by SNDBOX:
A couple of days later we saw that it was being analyzed by another sandbox, VirusTotal Jujubox Sandbox whose results were the same as before:
After this last analysis we had no more news from VirusTotal, so we moved on to another service like Any.run. In this case the vulnerability was in the Processes Graph section. Although a user accessing the page would not find anything out of place, when looking at the resources loaded by the service interface, we could see numerous requests for our XSS Hunter script:
Once the tests on these services were completed, we identified that Google had indexed references to our subdomain in XSS Hunter. Google was linking our sample on Alienvault’s Open Threat Exchange platform. Upon login we noticed that it was also vulnerable like the previous ones as it also made requests to our subdomain in XSS Hunter.
With the tests performed, we notified all concerned to implement the solutions as quickly as possible. It is worth mentioning the very fast response times of Any.run and Alienvault.
Results
Once the tests were finished, while we were collecting the information for the Rooted talk, we identified in XSS Hunter’s logs thousands of requests coming from the execution of our samples with some interesting nuances.
An example of this are the following captures associated with Chinese companies in charge of analyzing and classifying all the samples found in services such as those analyzed:
As for the requests, the following graphs show the results. The first one shows the totals, while the second one groups them to show more realistic results (since the sample has several XSS payloads). They show a great advantage of Chinese connections with respect to the rest of the world, demonstrating the amount of resources that country invests in cyber security.
In summary, in this post we see a potential vector to identify and perhaps attack analysts, despite the fact that the samples are analyzed and hosted by third party services.
The following diagram shows a scenario in which a Blue Team intercepts an artifact from a Red Team. The defenders analyze it in an external (or internal) service that has (or does not have) access to the Internet, and the vulnerabilities described in this entry would be exploited by representing the results of such an analysis in the analyst’s browser (most likely in the Blue Team’s internal network). At that point it would be viable to attack the defenders (tools such as BeEF would be interesting in this environment).
And this finishes this entry. For more information, check the links below to the video of the talk and the presentation:
- Link to the talk: https://www.youtube.com/watch?v=AyVgIttiUpQ
- Link to the presentation: https://github.com/Aetsu/Presentaciones/blob/master/Sandbox%20fingerprinting%20-%20Evadiendo%20entornos%20de%20analisis.pdf
