New Wave of Malicious Excel 4.0 Macros
2020-12-08 22:32:08 Author: perception-point.io(查看原文) 阅读量:326 收藏

IT develops really quickly, so it seems unbelievable that a piece of technology from 26 years ago could be posing a cybersecurity threat, but that’s exactly what’s happening. We recently saw a large-scale attack that leveraged the XLM macros (aka Excel 4.0 Macros) technique to infect computers with malware.

Overview

As security vendors are becoming aware of this kind of attack, adversaries try to hide it and break security products’ detection engines to pass through the gates to infect end users’ computers.

In this attack, the threat actors tried to evade the email security measures by using a very old excel file format. In general, the Excel file format had several iterations and improvements throughout the years. The most recent one is XML-based, and its file extension is xlsx.

The End of Binary

Previous formats were binary and had several variations over time. Files of these formats carry the xls extension (without the ‘x’ at the end). Excel 97-2003 was the last binary format. It’s documented here by Microsoft.

The binary formats are a type of Compound Document File and contain several streams of data. The main one holds the entire workbook information. The data inside the stream gets formatted in the BIFF file format, which varies according to the specific version. In Excel 97-2003, the stream is “Workbook” and contains BIFF8 data. In the Excel 95 format, it’s called “Book” and contains BIFF5 data.

The Change

Usually, XLM macros attacks get stored in Excel 97-2003 file format (BIFF8, stored in the Workbook stream). In the recent campaign, we see that attackers chose to craft the malicious files as Excel 95 file (BIFF5, stored in the Book stream). As said, this is probably an attempt to fail security products file parsers, rendering them blind to the malicious payload of the attack.

Recent campaign Excel 95 file exhibiting the ‘Book’ stream
Example of an Excel 97-2003 file exhibiting the ‘Workbook’ stream

The attack itself, except for the ancient excel file format, is like the other XLM macros-based attacks. (empty cells have get deleted, changed text color to black)

The XLM macros download a DLL file from the following URL: hxxp://angeshemaria.com/gwyzlymd/923753.jpg.

The DLL is then saved to C:\AutoCadest\AutoCadest2\Fiksat.dll and is being executed by using rundll32.exe.

This is Where Things Get Interesting

We noticed that the server serves different DLLs when surfing to that URL. Some of these DLL files were actually digitally signed, and according to Windows, with a valid signature (at least to the date of the check – 2020/11/25). The certificate issuer was Sectigo. We contacted them and informed them of the issue. (See the timeline at the bottom).

Signed Fiskat.dll file with a valid signature.

Output of trailofbits/uthenticode: A cross-platform library for verifying Authenticode signatures (github.com) signature validation tool by Trailofbits


C:\src\svcli\Release>svcli.exe malware
This PE is verified!
malware has 1 certificate entries
Calculated checksums:
MD5: 8382d44559d017c153f5a92af3c93d6
SHA1: 4d63e05a5af2528514277c52ea2bd5dc07094d8
SHA256: 481a9e78c41ecfb51aeeab52456b99d59388b9d16aa3e16739e3d4174dda75
SignedData entry:
Embedded checksum: 4d63e05a5af2528514277c52ea2bd5dc07094d8
Signers:
Subject: /C=CZ/postalCode=500 03/L=Hradec Kr\xC3\xA1lov\xC3\xA9/street=V\xC3\xADta Nejedl\xC3\xA9ho 1161/1b/O=\xC5\xA0kolab s.r.o./CN=\xC5\xA0kolab s.r.o.
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Code Signing CA
Serial: B8B58B6CFE395E338F3476D121E78139
Certificates:
Subject: /C=CZ/postalCode=500 03/L=Hradec Kr\xC3\xA1lov\xC3\xA9/street=V\xC3\xADta Nejedl\xC3\xA9ho 1161/1b/O=\xC5\xA0kolab s.r.o./CN=\xC5\xA0kolab s.r.o.
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Code Signing CA
Serial: B8B58B6CFE395E338F3476D121E78139
Subject: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
Serial: 01
Subject: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
Serial: 3972443AF922B751D7D36C10DD313595
Subject: /C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Code Signing CA
Issuer: /C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
Serial: 1DA248306F9B2618D082E0967D33D36A
This SignedData is valid!

Six Variants of DLL

We examined six variants of the DLL. Three were signed (with two different valid certificates) and three were not. Two of the DLLs were exactly the same, but one was signed and the other was not. This tells us that the attackers were probably being cautious with the certificates and perhaps signed the DLLs on the fly from a pool of certificates they have.

Loading one of the DLLs into Ghidra revealed very few functions and strings after the initial analysis. This hints that the DLL is probably packed in some way.

A lazy unpacking attempt was done using x64dbg and its Scylla plugin. We just run the DLL (using the following commandline: rundll32.exe

“C:\AutoCadest\AutoCadest2\Fiksat.dll”, DllRegisterServer) and let it run for a few seconds, hoping that it will unpack itself in memory for us. We then use the plugin, pick the Fiksat.dll, and dump it.

We then open the resulted Fixat_dump.dll in Ghidra and reveal much more information. We see a lot more functions and strings, allowing us to better understand the malware at hand.

Of particular interest, is the highlighted string that seems like a WMI Query for installed AV products on the system.

Overall, we note that attackers take great measures to infect the victims. They utilize old file formats—Excel 95 file in this case, and even sign their malicious DLLs with valid digital certificates (!) in an attempt to keep their attacks undercover for as long as possible.

Solution

We provided seven layers of detection. The following ones are aimed specifically for the prevention of malware:

  • HAP. Perception Point’s core IP is the HAP (Hardware-assisted Platform) and truly differs the company from others. The HAP is composed of three main algorithms, all meant to provide a complete protection against any zero-day exploit (i.e. without any prior knowledge and the attack), N-day attacks, and any kind of attempt to execute malicious code—including JavaScript inside PDF files or a VB-Scripts inside a word document.
  • Recursive Unpacker. This extracts all files transferred, thus uncovering and thwarting evasion techniques.
  • Threat Intelligence. This includes best-in-class intelligence sources coupled with internally developed engines scans all content to identify any “known” malware.
  • Anti-virus engines. These combine best-in-class signature based anti-virus engines to identify malicious attacks with Perception Point’s Signature Analysis engines for highly complex malware.

IOCs

Calculation-2093160141-11202020.xls - 33ca67cee276cda1ad53989d2088c76bfe56476bb240e5a44a198746895731db
Fixat.dll (various versions) -
680187a2a4393d176e490200f98bef8199785554f8190a53220e4ac50752ddef
0e6e339b06e39d141539d3161d4ace07084e4f2530f1d23656f01de675768e0c
494b877b2bd69f9a0867e5d29927e99c007a38ec25eb497b68c2d0c7b2dfa52b
5cd0408982dfb0d73e5ed44e70fa93ad3013f92ad2257cec487a22a72329c40c
c26e1912c17609ca7912fe67586d6067f4bcde6c5eb8fce66f7cdaf4696d6be4
d58292ecad4d6aec84c53d670b76903dad0a1c72c4fd49134156b7bced236692

Timeline

  • 2020-11-24 – Perception Point platform prevents malware email campaign
  • 2020-11-25 – Perception Point research team investigates the incident
  • 2020-12-02 – Vendor notified via email
  • 2020-12-02 – Vendor requests more information
  • 2020-12-02 – Vendor provided with the above research
  • 2020-12-03 – Vendor responds

文章来源: https://perception-point.io/new-wave-of-malicious-excel-4-0-macros/
如有侵权请联系:admin#unsafe.sh