TAU-TIN - Java Embedded MSI files

[#1]

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.

 Image footer: Concatenating the 2 files together and verifying the Windows is reporting this file signature to be valid

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.

Image footer:New File Approved

 Image footer: CBP file metadata with file publisher information

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. 

 Image footer: Successful meterpreter session

The meterpreter session allows for post exploitation interaction with compromised system potentially allowing adversaries persistence into the trusted network.

  Image footer: Interactive meterpreter session

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.

   Image footer: CBR execution of malicious jar file 

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.

1. Identify MSI files
2. 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
{
   strings:
       $msi = { D0 CF 11 E0 A1 B1 1A E1 }  // MSI HEADER
      $MsiCLSID = {84 10 0C 00 00 00 00 00 C0 00 00 00 00 00 00 46 }  //CLSID OF MSI
       $tst = {4D 00 73 00 69 00 44 00 69 00 67 00 69 00 74 00 61 00 6c 00 53 00 69 00 67 00 6e 00 61 00 74 00 75 00 72 00 65}  //MSI Digital Signature     
   condition:
      $msi at 0 and ($tst and $MsiCLSID at (((uint32(0x30)+1)*(1 << uint16(0x1e)))+0x50) and uint8(((uint32(0x30)+1)*(1 << uint16(0x1e)))+0x42) == 5)
}

 yara footer: Signed_MSI Rule

   Image footer: yara execution of Singed_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
{
    meta:
        author = "Carbon Black TAU - Casey Parman"
        date = "2019-01-24"
        description = "Detecting signed MSI files with Java files embedded."
        rule_version = "4"
        yara_version = "3.8.1"
        exemplar_hashes = "5cc0a09c03038cc1621af21faa9c02c45e68aadacd87d7f75c39c4a8f6ed095b"
        priority = "High"
    strings:
        $s1 = /\/.{1,256}\.classPK/
        $s2 = "META-INF/"  // Java META-INF/
        $msi = { D0 CF 11 E0 A1 B1 1A E1 }  // MSI HEADER
        $MsiCLSID = {84 10 0C 00 00 00 00 00 C0 00 00 00 00 00 00 46 }  //CLSID OF MSI
        $pk = {50 4B (03 04 | 05 06 | 07 08)}  // PK (ZIP/Java files)
        $MSI_SIGNED = {4D 00 73 00 69 00 44 00 69 00 67 00 69 00 74 00 61 00 6c 00 53 00 69 00 67 00 6e 00 61 00 74 00 75 00 72 00 65}  //MSI Digital Signature
        $EndOfCentralDirectory = {50 4b ( 05 | 06 ) ( 06 | 07 )}    
    condition:
       $msi at 0 and ($MSI_SIGNED and $MsiCLSID at (((uint32(0x30)+1)*(1 << uint16(0x1e)))+0x50) and
uint8(((uint32(0x30)+1)*(1 << uint16(0x1e)))+0x42) == 5) and
       ($pk and 1 of ($s*)) and $EndOfCentralDirectory in (filesize-0x64..filesize)
} 

 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.

Image footer: yara execution of  Envasion_Jara_2019_Q1 rule.

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
2899bdc77470d0e42c41b16a8e18de0dbb9536221cdb17aa42ef148cd03bac96
76730283d59253b26569de7f3863354634cdea24cca896969b3a5cd66a686cf7
b33a03bcc366823cba3f20e0e345724bb134ae7ac91e5f5f55569ae2f283baea
abf9a96dc12555f21d0641aadac1548e306ea18c0f6d0ce7bbb7092a9cc3cebe
1a9e7c1e944fc1d40cd4f9f27461c613357b45b6c448be8ec96c7d74c5e79fe4
5a6dccd98c868a8e0ab97da7c91e0fc1aae01bc25003a6ebad4e072fd5959065

Data footer: VTI retrohunt hash results

Image footer: VTI retrohunt results

Image footer: VTI results specific hashes matching yara rule.