ESET’s Security Research Lab details a malware-spreading campaign leveraging the deadline for tax returns in Slovakia and examines a case of infection where a bank’s two-factor authentication prevented financial loss.
ESET’s Security Research Lab has been monitoring a malware-spreading campaign based around the March deadline for tax returns in Slovakia. Whilst this was mostly a local attack, the case demonstrates how effective and dangerous such social engineering attacks can be in general when trending topics, or other credibility-adding-tricks, are used.
The Spreading Campaigns
The attack vector in the two campaigns that we discovered were e-mails purporting to be from the Slovak Tax Office (equivalent to the Internal Revenue Service in the US, or the UK’s HM Revenue and Customs). Screenshots of the HTML-formatted e-mails used are shown below.
The translated subject of the emails read: Notification of real estate tax changes and the text, written in proper Slovak, states that payment instructions are to be found in the included attachment. It is interesting to note that this social engineering approach was made more credible by the fact that each taxable entity in the Slovak Republic must use a unique bank account for tax payment. The attacker was not just fluent in Slovak but also well-enough acquainted with local tax legislation to devise such a believable scam.
The attacker modified the delivery method slightly in between the two spam campaigns, but the malware served up in the campaign remained the same.
The first wave of emails offered the “attachments” as download links (on a popular file-sharing service) to one of two files, each in a different format: an RTF file that masqueraded as a Microsoft Word document or an executable file. The RTF file contained an exploitation of CVE-2010-3333 which, if successful, also delivered the malicious executable. The good news was that, according to the file-sharing download statistics, the success rate of the exploit downloading the malware was less than 10%. Unfortunately, many people still opted to download the executable directly from the second (backup) link in the email, perhaps after seeing a garbled-looking document.
The second campaign was more straightforward and, according to download statistics, more successful. The hypertext link in the email pointed to an executable file (with a .SCR extension), without explicitly mentioning the file format.
The malware used in these attacks was an ordinary credentials-stealing Trojan, which was already detected prior to these campaigns. ESET’s software detects it as Win32/Sazoora.A.
Win32/Sazoora.A is designed to steal a victim’s logon credentials from web browsers. Specifically, the Trojan contains libraries for injecting into Internet Explorer, Mozilla Firefox or Google Chrome. Win32/Sazoora implements several data-stealing techniques:
- Intercept any information entered into HTML forms in the aforementioned browsers
- Extract stored credentials from the browsers
- Inject fraudulent HTML code into webpages in order to steal credit-card related data
The stolen data is then periodically sent to a remote server (the URLs of which are hard-coded in the binary). The following screenshots show the HTML web-injects used to lure the victim into entering his credit-card credentials.
The last screenshot – of a payment form for Microsoft Windows Updates – is particularly interesting. Note that none of the above mentioned techniques are novel at all, and are commonly used by banking Trojans such as the infamous Zeus and SpyEye families. But unlike those families, Win32/Sazoora.A features configuration options that are less dynamic as regards both the Command & Control server addresses and the web-inject HTML hard-coded in the analyzed binary.
ESET LiveGrid® detection rates for Win32/Sazoora indicate that the Trojan was mostly seen in Slovakia (over 60% of all detections), undoubtedly as a result of these campaigns. The country with the second highest number of detections is Switzerland, but it is important to note that Sazoora is a generic information stealing Trojan, not customized in the Slovak attacks in any way, except for the C&C server address, so the Swiss detections may just indicate that the actual author of the malware has sold it to multiple clients.
Our telemetry indicates that many of the targets successfully infected through malware-spreading emails weren’t accidental or purely random. The emails were mass distributed using a generic list of hopefully-Slovak e-mail addresses. And as it turned out, some of the victims identified so far include physicians, accountants and several institutions. These were considerably more likely to click on the links, as the content of the e-mail was relevant to their profession (and also the upcoming tax deadlines made it even more likely for them to check the content).
We have also performed a detailed analysis of one victim’s infected computer at their request after they noticed suspicious activity relating to their bank account. It turned out that they received one of the aforementioned emails, were infected by Win32/Sazoora.A and had their online banking credentials stolen. The most interesting thing about this infection, however, was the fact that the attacker was prevented from stealing any money from the victim’s account by the bank account’s grid-card protection, a kind of multifactor authentication. The attacker then sent the victim a phishing email passed off as some kind of client verification by the bank, in which they asked for a specified code from the grid-card. The victim was not fooled by this attempt.
Other victims may not have been so fortunate. This case again confirms the necessity for employee education with regard to phishing (and information security in general), especially when the employees handle sensitive corporate or customer data.
Kudos to Peter Košinár, David Gabriš and Miro Babiš for their work on the case.