Yoroi security firm uncovered a targeted attack against one of the most important companies in the Italian Naval Industry leveraging MartyMcFly Malware.

Targeted Attack found and dissected by Today I’d like to share an interesting analysis of afound and dissected by Yoroi (technical details are available here ). The victim was one of the most important leaders 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 analyzed email presented two attachments to the victim:

A company profile, aiming to present the company who was asking for spare parts

A Microsoft.XLSX where (apparently) the list of the needed spare parts was available

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. At 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 the 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 another way, if the victim opens the document and he/she is not aware of “secret key” how can he/she get infected? And why the attacker used an encrypted payload if the victim cannot open it?

Stage1: Encrypted Content

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?

even if encrypted. Microsoft excel asks 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 Well, on Microsoft Excel there is a common way to open documents called “Read Only”. In “Read Only” mode the file could be openedMicrosoft excel asks 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: “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.

Stage2: OleOBj inclusion (click to expand it)

A quick analysis of 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.

Stage2: extracted Payload

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).

Stage3: Equation Editor Spawned and connecting to Dropping URL

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 has a double target: (a) old school or un-configured IDS bypassing (b) hiding malicious software an into well-known and trusted folder structure in order to persist over website upgrades.

Introducing Stage4. PE file dropped and executed

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.

Stage4: According to Virus Total

Looking into GEqy87 is quite clear that the sample was hiding an additional windows PE. On one, hand it builds up the new PE directly on memory by running decryption loops (not reversed here). On the other, hand it fires up 0xEIP to pre-allocated memory section in order to reach new available code section.

Stage5: Windows PE hidden into GEqy87.exe

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 behavior while if the current date is, for example, 2018, it runs its behavior by calling “0xEAX” (typical control flow redirection on memory crafted).

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

Assuming there were no hash collisions over years

Assuming VirusTotal: “First Seen in The Wild” is right (and not bugged)

We might think that: “we are facing a new threat targeting ( as today ) Naval Industry planned in 2010 and run in 2018″.

The name MartyMcFly comes pretty naturally 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.

Further details on the MartyMcFly malware are reported in the original analysis published by Marco Ramilli on his blog. Yoroi also launched his a new blog where it is possible to find several interesting analysis, including the one on the MartyMcFly malware. About the author: Marco Ramilli, Founder of Yoroi I am a computer security scientist with an intensive hacking background. I do have a MD in computer engineering and a PhD on computer security from University of Bologna. During my PhD program I worked for US Government (@ National Institute of Standards and Technology, Security Division) where I did intensive researches in Malware evasion techniques and penetration testing of electronic voting systems. I do have experience on security testing since I have been performing penetration testing on several US electronic voting systems. I’ve also been encharged of testing uVote voting system from the Italian Minister of homeland security. I met Palantir Technologies where I was introduced to the Intelligence Ecosystem. I decided to amplify my cybersecurity experiences by diving into SCADA security issues with some of the biggest industrial aglomerates in Italy. I finally decided to found Yoroi: an innovative Managed Cyber Security Service Provider developing some of the most amazing cybersecurity defence center I’ve ever experienced! Now I technically lead Yoroi defending our customers strongly believing in: Defence Belongs To Humans Edited by Pierluigi Paganini (Security Affairs – MartyMcFly, malware)

Share this...

Linkedin Reddit Pinterest

Share On