Japanese Banking Trojan "Shifu" Distributed via Malicious Word Documents

<p>
Last week on October 7,&nbsp;Raytheon | Websense&reg;&nbsp;Security Labs&trade; noticed an interesting email campaign distributing what at first appeared to be Dridex botnet 220. In a seven-hour&nbsp;window, Raytheon | Websense stopped over 16,000 malicious email messages&nbsp;from being delivered to customers, all of which appear to have been Japanese targets.</p>

<p>
Raytheon | Websense customers&nbsp;are protected against this threat via real-time&nbsp;analytics with ACE,&nbsp;the Websense&nbsp;<a href="http://www.websense.com/content/websense-advanced-classification-engine.... rel="nofollow" target="_blank">Advanced Classification Engine</a>, at the different&nbsp;<a href="http://www.websense.com/content/seven-stages-recon.aspx?cmpid=slbl" rel="nofollow" target="_blank">stages</a>&nbsp;of the attack detailed below:&nbsp;</p>

<ul>
<li>
Stage 2 (Lure) - ACE has protection against the malicious email sent to targets</li>
<li>
Stage 5 (Dropper) - ACE has protection against the malicious doc files and the malware files</li>
<li>
Stage 6 (Call Home) - ACE has live, real-time protection against the malicious traffic generated by the malware associated with this threat</li>
</ul>

<h2>
Email Infection Vector</h2>

<p>
An example of one of the email lures can be seen below:</p>

<p>
<img alt="" src="/sites/default/files/blog/legacy/1563.shifu_email_lure_07.oct.15.png-550x0.png" style="height:346px; width:550px" /></p>

<p>
The email body text is very generic, appearing to be a message received from somebody within the same organization as the intended target.&nbsp;The attached .doc file (<em>fa71d6430165d810a6ac9d9199d88620534b14e8</em>) named&nbsp;<em>20151007112034511.doc&nbsp;</em>contained a macro that attempted to download a payload from the following URL:</p>

<p>
<em>hxxp://leelazarow[.]com/345gfc334/65g3f4.exe</em></p>

<p>
This URL pattern is typical of what we see in Dridex botnet 220 campaigns; however, in this case, the payload turned out to be the Japanese banking trojan&nbsp;<strong>Shifu</strong>. The macro used to download this payload contains the obfuscated URL:</p>

<p>
<img alt="" src="/sites/default/files/blog/legacy/4452.macro_shifu_7.oct.15.png-550x0.png" style="height:225px; width:550px" /></p>

<p>
This Visual Basic macro is almost identical to the one used in the&nbsp;Dridex botnet 220 campaign of the following day, October 8:</p>

<p>
<img alt="" src="/sites/default/files/blog/legacy/4341.macro_dridex_8.oct.15.png-550x0.png" style="height:224px; width:550px" /></p>

<p>
The email distribution methods of Shifu and Dridex are not similar enough to conclude that the same actor is behind both campaigns; however, it is highly likely that the same macro builder and obfuscation tool is being used in both cases. In fact, we recently blogged on the&nbsp;<a href="http://blogs.websense.com/security-labs/japanese-banking-trojan-shifu-di... target="_blank">shared use of frameworks and infrastructure</a>&nbsp;among malware.</p>

<p>
The Shifu payload, itself, is quite comprehensively detected by our file sandboxing product:</p>

<p>
<img alt="" src="/sites/default/files/blog/legacy/3731.shifu_tscp_report.png-550x0.png" style="height:202px; width:549px" /></p>

<h2>
Checking for a Man-in-the-Middle</h2>

<p>
Interestingly, in our analysis of the Shifu sample (<em>476c8baa551fc5d1d9aad5441c7d1c2c4d502944</em>),&nbsp;it appeared that&nbsp;the&nbsp;malware was&nbsp;trying to determine if a Man-in-the-Middle (MiTM) interception was&nbsp;operating on the connection, and the malware would not contact its&nbsp;command and control (C&amp;C)&nbsp;if it determined an MiTM was taking place. This check was done by verifying HTTPS connections to several hosts that included&nbsp;<em>microsoft.com, dropbox.com, twitter.com, sendspace.com, etrade.com, facebook.com, instagram.com, github.com, icloud.com</em>&nbsp;and&nbsp;<em>python.org</em>.&nbsp;If any of these attempts resulted in a connection that was&nbsp;subjected to an&nbsp;MiTM interception,&nbsp;then the malware did not contact its C&amp;C. However, if no MiTM interception was detected (even if previous requests were) and if it was able to connect through to one of these hosts, then it proceeded to contact its C&amp;C as normal:</p>

<p>
<img alt="" src="/sites/default/files/blog/legacy/4456.shifu_cnc_post.png-550x0.png" style="height:67px; width:550px" /></p>

<p>
This is not typical malware behavior that we tend to see, because a significantly large percentage of organizations do, in fact,&nbsp;employ MiTM interception for HTTPS in order to detect and stop more threats, meaning that Shifu would refuse to attempt a communication with its C&amp;C or domain generation algorithm (DGA) infrastructure in such a scenario.&nbsp;</p>

<p>
Blog contributors: Nick Griffin, Ran Mosessco, Andy Settle</p>

<h2>
Indicators of Compromise (IOCs)</h2>

<p>
Attachment hashes (SHA1):</p>

<p>
<em>27eebb467c0caf35aea15d4a26c865c203426596</em></p>

<p>
<em>7768683584cd0a71d02b89896322099405173fa9</em></p>

<p>
<em>fa71d6430165d810a6ac9d9199d88620534b14e8</em></p>

<p>
<strong>Payload URLs:</strong></p>

<p>
<em>hxxp://www.profes-decin.kvalitne[.]cz/345gfc334/65g3f4.exe</em></p>

<p>
<em>hxxp://rockron[.]com/~rockron/345gfc334/65g3f4.exe</em></p>

<p>
<em>hxxp://leelazarow[.]com/345gfc334/65g3f4.exe</em></p>

<p>
<strong>Shifu payload hash (SHA1):</strong></p>

<p>
<em>476c8baa551fc5d1d9aad5441c7d1c2c4d502944</em></p>

<p>
<strong>Shifu command-and-control (C&amp;C) server:</strong></p>

<p>
<em>hxxps://freewebpj[.]com/news/userlogin.php</em></p>