NetWitness Community

KevinStear1 · ‎2017-08-18

By far most of the bank-related phishing campaigns described in security advisories and reports consist of bank customers being targeted for their online credentials. Much less common is a phishing campaign targeting the banks themselves. Perhaps fraudsters know that there are a lot more bank customers than there are banks, and generally banks have a more hardened security posture than the average bank’s customer.

Target: multiple bank offices in Russia

But still, payoff potential for a successful bank compromise might be considerable. In this threat advisory, we describe a Russian-language phishing campaign active during the second week of August 2017, targeting not the usual banking customers, but the Russian banks themselves. And in an unusual reversal of typical bank phishing social engineering tactics, the phishing emails purport to be from the bank’s customers. Consider the following phish delivered to the email address displayed on the bank’s website. In the email screenshot with our added machine translation from Russian, notice the subject line and message body text reflecting a “business customer upset about extra charges on his credit card” social engineering theme (Figure 1).

Figure 1 Phishing email targeting Russia bank #1, machine translation in red boxes

Figure 2 is a screenshot of another phishing email obtained by RSA FirstWatch, targeting “Russia bank #2.” While this email is part of the same campaign, note that the body text, subject lines, file name, and @mail.com sender email is different from that targeting Russia bank #1, suggesting at least some manual actor modifications to the phishing email construction.

Figure 2 Phishing email targeting Russia bank #1, machine translation in red boxes

RSA FirstWatch identified 23 such attachments in this campaign, all using what appeared to be the exact same EPS exploit. The disgruntled banking customer was consistent throughout; illustrated below are a few attachment examples:

Exploit attachment #1 was deployed with the following names in Russian:

Выписка по счету.docx ("Account statement")

Выписка по карте.docx ("Card statement")

Персональные данные.docx ("Personal information")

Exploit attachment #2 was deployed with the following names:

Выписка по карте.docx (or “Card statement”)

Выписка по карте клиента.docx (or “Customer card statement”)

Exploit attachment #3 was deployed using the following name:

Выписка.docx (or “Statement”)

Note: Hashes of all samples will be included in the Appendix of this analysis.

As of 10 August 2017, RSA FirstWatch has high confidence that multiple individuals at many Russian banks were targeted with these malicious attachments, and believe this campaign was subsequently brought to the attention of the Central Bank of Russia’s FinCERT by one or more of the banks being targeted. On 17 August 2017, the day we were finishing up this analysis, a new sample was discovered being deployed, with a different C2 node and slightly different communication.

An exploit in someone else’s wrapper?

Before we get to details about the exploit used in this campaign, we should cover some history on EPS exploits in docx files. FireEye discovered a malicious docx exploiting a zero day vulnerability in Microsoft’s Encapsulated Postscript (EPS) filter, in the summer of 2015. This EPS exploit was assigned CVE-2015-2545. In March 2017, FireEye observed both nation state and financially motivated actors using EPS zero day exploits assigned as CVE-2017-0261 and CVE-2017-0262, prior to Microsoft disabling EPS rendering in its Office products with an update in April 2017. So it is likely one of these three EPS exploits is being employed with the perpetrator activity under investigation, perhaps hoping that their targets haven’t applied the April patch that would make every EPS exploit futile.

Since docx files are just a Zip-compressed container, comparing them with a file tree view might be a quick way to assess similarity on a high level. In fact, all 23 known docx files used in this campaign are very nearly identical, with the same 12 component files. Varying checksums might have to do with build artifacts, perhaps even intentionally so, in order to generate a unique hash with each build.

Figure 3 Tree view of docx container file used to target Russian banks last week

Interesting enough 10 of these 12 docx component files (everything but the image1.eps and document.xml files) are dated April 18^th. This is no coincidence; in fact, those same docx component files were found in the attachment used by nation-state actors in their email targeting of an Eastern European Ministry of Foreign Affairs, back when this EPS exploit was still a zero day (Figure 4).

Figure 4 Eastern European Ministry of Foreign Affairs targeted by suspected nation state actors

So if we compare the tree view of that older docx container (Figure 5), we see that 10 of the same component files appear identical, and we can confirm that using cryptographic hashing.

Figure 5 Tree view of "Trump" exploit docx container, with 10 of 12 files identical to 23 recent RU bank targeting samples described in this investigation

Of special note is the common app.xml file, which comes directly from the decoy document in the “Trump” exploit file. This app.xml file contains the same URL to the California Courier website (www[.]thecaliforniacourier[.]com), where the text was copied from “Trump’s Attack on Syria: Wrong for so Many Reasons” as described by ESET in their exploit analysis.

Clearly there was some “borrowing” going on between this current bank-targeting campaign and the previous nation-state espionage campaign. Does this suggest that these campaigns and actors are in any way complicit/related? No. On the contrary, national interests seem to imply that those particular espionage-focused actors (i.e., from the “Trump” campaign) would almost certainly NOT be involved in broadly exploiting Russian banks a few months later. That being said, an alternative hypothesis is that these bank-targeting actors purposely purloined the older espionage related docx files to introduce uncertainty and/or mis-attribution, or even to send a message to defenders or researchers. As we'll see shortly, the attackers also interestingly signed (commented) their malware with lyrics from Slipknot's Snuff.

Screen Shot 2017-08-17 at 2.29.51 PM.png

Figure 6 Google result with Slipknot Snuff lyrics

Which exploit is this?

Obfuscation is important for exploits, especially when a campaign that is broad as this one is up against a gamut of financial institutions with AV’s that have had plenty of time to add detection for known EPS exploits. With initial AV coverage of these two dozen or so attachments in the single digits out of more than 50 AV vendors, RSA Engineering’s Kevin Douglas jumped at the chance to flex his deobfuscation skills, and here steps us through our exploit assessment.

Step 1. Unzipping the sample DOCX file, reveals the following embedded EPS Image file

unzip ./2c86a55cefd05352793c603421b2d815f0e1ddf08e598e7a3f0f6b1d3928aca8

Archive: ./2c86a55cefd05352793c603421b2d815f0e1ddf08e598e7a3f0f6b1d3928aca8

inflating: [Content_Types].xml

inflating: docProps/app.xml

inflating: docProps/core.xml

inflating: word/document.xml

inflating: word/fontTable.xml

inflating: word/settings.xml

inflating: word/styles.xml

inflating: word/webSettings.xml

inflating: word/media/image1.eps

inflating: word/theme/theme1.xml

inflating: word/_rels/document.xml.rels

inflating: _rels/.rels

Step 2. Examining the app.xml file, we can see a suspicious URL artifact

cat docProps/app.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<Properties xmlns="http://schemas.openxmlformats.org/officeDocument/2006/extended-properties" xmlns:vt="http://schemas.openxmlformats.org/officeDocument/2006/docPropsVTypes"><Template>Normal.dotm</Template><TotalTime>1</TotalTime><Pages>2</Pages><Words>958</Words><Characters>5462</Characters><Application>Microsoft Office Word</Application><DocSecurity>0</DocSecurity><Lines>45</Lines><Paragraphs>12</Paragraphs><ScaleCrop>false</ScaleCrop><HeadingPairs><vt:vector size="2" baseType="variant"><vt:variant><vt:lpstr>Title</vt:lpstr></vt:variant><vt:variant><vt:i4>1</vt:i4></vt:variant></vt:vector></HeadingPairs><TitlesOfParts><vt:vector size="1" baseType="lpstr"><vt:lpstr></vt:lpstr></vt:vector></TitlesOfParts><Company></Company><LinksUpToDate>false</LinksUpToDate><CharactersWithSpaces>6408</CharactersWithSpaces><SharedDoc>false</SharedDoc><HLinks><vt:vector size="6" baseType="variant"><vt:variant><vt:i4>4456521</vt:i4></vt:variant><vt:variant><vt:i4>0</vt:i4></vt:variant><vt:variant><vt:i4>0</vt:i4></vt:variant><vt:variant><vt:i4>5</vt:i4></vt:variant><vt:variant><vt:lpwstr>hXXp://www[.]thecaliforniacourier[.]com </vt:lpwstr></vt:variant><vt:variant><vt:lpwstr></vt:lpwstr></vt:variant></vt:vector></HLinks><HyperlinksChanged>false</HyperlinksChanged><AppVersion>15.0000</AppVersion></Properties>

Step 3. Examining the image1.eps file, we can see:

A likely multibyte XOR key (<7a5d5e20>)
Quoting lyrics from Slipknot's Snuff in the comments (%%Myheartisjusttoodarktocare, %%Icantdestroywhatisntthere)
A likely XOR encoded hexadecimal payload (<017d71681f3128450e343d415a3b374e1e3b314e0e7d6f104a7d2d431b313b4615332a0009382a4615332a001d3131421b313a491
9297e421f3a…>)
A likely XOR decode loop: (0 1 A1 length 1 sub { /A5 exch def A1 A5 2 copy get A2 A5 4 mod get xor put } for A1 })
A likely execution of the payload once it is decoded (exec )
Repetitive obfuscated comments translating to “kasper-pidor kasper-pidor kasper-pidor kasper-pidor” scattered throughout to make the code that make it harder to read. These are highlighted in green... and possibly speak to something more personal between the actors and Kaspersky possibly? (e.g., %%6b61737065722d7069646f72206b61737065722d7069646f72206b61737065722d7069646f72206b61737065722d7069646f7220)

Dump of image1.EPS code:

%!PS-Adobe-3.0 EPSF-3.0

%%BoundingBox: 31 24 51 654

%%Page: 1 1

/Times-Roman findfont globaldict