MartyMcFly Malware: Targeting Naval Industry

Today I’d like to share an interesting analysis of a Targeted Attack found and dissected by Yoroi (technical details are available here). The victim was one of the most important leader in the field of  security and defensive military grade Naval ecosystem in Italy. Everything started from a well crafted  email targeting the right office asking for naval engine spare parts prices. The mail was quite clear, written in a great language within detailed spare parts matching the real engine parts. The analysed email presented two attachments to the victim:

The attacker asked for a quotation of the entire spare part list available on the spreadsheet. In such a way the victim needed to open-up the included Microsoft spreadsheet in order to enumerate the “fake customer” needs. Opening up The Excel File it gets infected.

Let’s go deep into that file and see what is happening there. As a first sight the office document had an encrypted content available on OleObj.1 and OleObj.2. Those objects are real Encrypted Ole Objects where the Encrypted payload sits on “EncryptedPackage” section and information on how to decrypt it are available on “EncryptionInfo” xml descriptor. However, in that time, the EncryptionInfo was holding encryption algorithm and additional information regarding the payload but no keys were provided. The question here was disruptive. How Microsoft Excel is able to decrypt such a content if no password is requested to the end user ?  In other way if the victim opens the document and he/she is not aware about “secret key” how can he/she get infected ? And why the attacker used an encrypted payload if the victim cannot open it ?

Using an encrypted payload is quite a common way to evade Antivirus, since the encrypted payload changes depending on the used key. But what is the key ?

Well, on Microsoft Excel there is a common way to open documents called “Read Only”. In “Read Only” mode the file could be opened even if encrypted. Microsoft excel asks to the user a decryption key only if the user wants to save, to print or to modify the content. In that case Microsoft programmers used a special and static key to decrypt the “Read Only” documents. Such a key sees the following value: “VelvetSweatshop” (a nice old article on that). Let’s try to use this “key” to try to decrypt the content! The following image shows a brand new stage where a valid extracted xlsx file wraps more objects, we define it as Stage2.

A quick analysis on the Stage2 exposes a new object inclusion. (as shown in picture Stage2: OleOBJ inclusion). That object was crafted on 2018-10-09 but it was seen only on 2018-10-12. At this time the extracted object is clear text and not encrypted content was find at all. The following image shows the extracted object from Stage2.

It’s not hard to see what the payload does (CVE-2017-11882 ), but if you run it on a dynamic engine you would probably have more chances to prove it. The Payload exploits CVE-2017-11882 by spawning the Equation Editor, dropping and executing an external PE file. We might define the Equation Editor dropping and executing as the Stage3. The following image shows the connection to a dropping website performed by EquationEditor (click to magnify it). 

Evidence of what dissected is shown on the following image (Introducing Stage4) where the EquationEditor network trace is provided. We are introducing a new stage: the Stage4. GEqy87.exe (Stage4) is a common windows PE. It’s placed inside an unconventional folder (js/jquery/file/… ) into a compromised and thematic website. This placement usually have a duplice target: (a) old school or un-configured IDS bypassing (b) hiding malicious software into well-known and trusted folder structure in order to persist over website upgrades.  

Stage4 is pretty interesting per-se. It’s a nice piece of software written in Borland Delphi 7. According to VirusTotal the software was “seen in the Wild” in 2010 but submitted only on 2018-10-12 ! This is pretty interesting isn’t it ? Maybe hash collision over multiple years ? Maybe a buggy variable on VirusTotal ? Or maybe not, something more sophisticated and complex is happening out there.

 Stage5 deploys many evasion tricks such as: GetLastInputIn, SleepX and GetLocalTime to trick debuggers and SandBoxes. It makes an explicit date control check to 0x7E1 (2017). If the current date is less or equals to 0x7E1 it ends up by skipping the real behaviour while if the current date is, for example 2018, it runs its behaviour by calling “0xEAX”  (typical control flow redirection on memory crafted). 

For more technical details, please have a look here. What it looks very interesting, at least in my personal point of view, are the following evidences:

The name MartyMcFly comes pretty natural here since the “interesting date-back from Virus Total”. I am not confident about that date, but I can only assume VirusTotal is Right.

For IoC please visit the analysis from here.