Threat Analysis Unit - Threat Intelligence Notification
Source: https://blog.virustotal.com/2019/01/distribution-of-malicious-jar-appended.html
Summary
Application whitelisting provides environments with access controls to stop unauthorized software from executing. This is accomplished by utilizing file and folder attributes including but not limited to file path, filename, digital signature, publisher, cryptographic hash and product name. Utilizing different attributes allows organizations to achieve the right balance between security and administrative overhead. Organizations should carefully choose which attributes to trust as a compromise in the trusted attribute could compromise the application whitelisting technology.
VirusTotal publicly disclosed a new technique that allows adversaries to abuse this trust by leveraging existing approval to circumvent application whitelisting. This is due to how Microsoft Windows keeps a valid authenticode after additional content is appended to an MSI file. At this time Microsoft has decided not to address this issue in the current versions of Windows. Due to this adversaries are capable of distributing malicious content embedded within signed MSI files.
NOTE: This is not a vulnerability in Cb Protection, it's a feature built into Windows that when abused can lead to unauthorized code execution bypassing code signing checks
TAU has recreated a threat scenario for the purpose of research. This threat emulation consisted of:
- Using a Meterpreter payload in jar format to call back to our C2 server
- Microsoft Remote Desktop Managers msi file as our target signed and trusted binary
Leveraging the above tooling, we’re able to demonstrate how one can create an approved malicious jar file via this newly discovered technique.
In order for organization to overcome the administrative overhead of approvals for vendor with a large footprint in their environment, many rely on the publisher attribute as the trusted entities. In order to impersonate a typically customer environment, Microsoft Corporation has been approved as a publisher. Due to this approval when this file is dropped and discovered by the CBP agent, its approved due to its Publisher being Microsoft Corporation.
Executable JAR Files
JAR files consist of ZIP archives as defined by PKWARE, There are no Beginning of File or End of File markers within the ZIPspecification, identification occurs by reading the End of Central Directory Record located at the end of the archive. This means that tools that correctly read ZIP archives must scan for the End of Central Directory Record, and must not scan for entries from the top of the ZIP file because scanning from the top of the ZIP file could lead to False Positive entries. Because Java is a tool that follows these guidelines it will being reading the content from the last byte forward.
Although the file created is a MSI file with jar content appended when the extension is changed it will be executed by Java. This is because by default on Windows the Java 2 Runtime Environment (JRE) will register a default association for JAR files so that double-clicking a JAR file on the desktop will automatically run it with javaw -jar
Together these conditions allow the appended JAR contents of the MSI file to execute by double-clicking on the file. Once the file is executed, java will successfully execute the embedded payload calls back to our controlled C2 server.
The meterpreter session allows for post exploitation interaction with compromised system potentially allowing adversaries persistence into the trusted network.
CbR shows that this is executing as expected, like all other JAR files leaving detection difficult in environments that heavily rely on java. See CbR section for Watchlist information to detect this attack vector. Beyond watchlist, creating a yara signature that catches java embedded MSI files, seems to be the most efficient way to detect/mitigate this attack vector.
Yara Identification
Yara allows classification based on strings and binary patterns, before digging into the binary data goals should be defined in order to create a precise rule. In this case there are two goals and they both need to exist within the file.
- Identify MSI files
- Identify Java content
Digging into MSI
MSI files are archiving format from Microsoft that are based on Compound File format, these files begin with the file signature of D0 CF 11 E0 A1 B1 1A E1 In addition to this signature, MSIs Root storage CLSID of {000c1084-0000-0000-c000-000000000046}. This allows the creation of a basic template to identify MSI files. This attack vector also relies on signed MSI Files, when the MSI is signed it will have a MSI Digital Signature.
In order to validate this signature across the VirusTotal database used the following yara rule to search VTI. This ended with over 10,000 matches providing confidence in adding this signature to part of the final version.
|
rule Signed_MSI |
yara footer: Signed_MSI Rule
Digging into JAR
In order to identify JAR files we can begin by looking at the headers. As stated earlier JAR files consists of a ZIP archive defined by PKWARE. This allows identification with the following hex values {50 4B (03 04 | 05 06 | 07 08)}.
Since there is no difference between JAR and ZIP files within these bytes we’ll have to look at other common patterns of JARfiles. After reviewing the JAR file Specifications we can see that a META-INF directory is typically present and .class files are typically compressed.
In order to identify the META-INF directory we can simply use the string, “META-INF” in our yara rule, and the following regex for any class files \/.{1,256}\.classPK
The final piece to this yara rule will be identifying the End of Central Directory Record with the following signature of 0x06054b50 or 0x07064b50 for Zip64. This signature marks the end of the zip file and as stated before its the first entry that is read. Even empty zip files will contain an End of Central Directory Record
Putting it all together - MSI+JAR
With the detection mechanisms defined for MSIs and JAR identifications they can be added together into the yara rule achieves the goals defined.
|
rule Evasion_Java_2019_Q1 |
yara footer: Envasion_Java_2019_Q1 Rule
Running the yara rule locally allows for verifying there are no syntax errors and detections are working as expected. The yara rule created was ran against the same folder as the MSI rule shows that it's only detecting the malicious JAR file.
The final step in verifying the yara rule is searching VirusTotal. After searching 464.4 TB of data the yara rule matched 7 files. Of these 7 matches, all 7 seem to have malicious indicators associated with this attack vector verifying successful identification.
|
dd71284ac6be9758a5046740168164ae76f743579e24929e0a840afd6f2d0d8e |
Data footer: VTI retrohunt hash results
