Anatomy of a simple phishing attackMichael Orlov
26 Mar 2016
When teaching a Software Security course at SCE, I often stress that while cybersecurity measures become more and more sophisticated, gaining access to systems and accounts actually becomes easier, since providers of said systems must make them accessible by clueless users.
Shaltay-Boltay’s breakins are interesting to look into, because in spite of the usual nonsense boasting typical of such groups, this team often releases full dumps of emails, and in this case at least, the breakin details were not removed.
A phishing attack is mounted in order to steal user’s credentials, or to cause him to install a trojan. It is typically achieved by faking an email purporting to originate from a trusted source. In order to avoid being detected as spam, the following properties are desirable for the email:
- Sending MTA is located at a static IP with matching reverse DNS.
- Email must be sent using an encrypted connection.
- The IP passes an SPF check by being listed in a corresponding DNS entry for the sender’s domain.
- Email headers and body pass DKIM signature validation against a corresponding public key in DNS.
- Email validates against DMARC rules in a corresponding DNS entry.
- Email’s content passes anti-spam and anti-phishing heuristic filters.
Of course, there are user-friendly tools for testing the above.
In the inbox, there are two phishing emails. Both indicate usage of Mail.Ru web frontend for sending emails — likely because the attackers lack understanding of SMTP protocol, and use turnkey solutions. There is also a phishing email in spam folder, using a different approach.
Phishing Email 1
The first phishing email,
dated 15/07/2015, originates at IP
belonging to McHost.Ru. A cursory online search indicates
that McHost apparently provided free trial VPS at the time. Such a server is
necessary because it enables a static mail origin IP with reverse DNS record
— a must to avoid being rejected or classified as spam.
Here are the user-visible headers:
From: Gооgle Диск <firstname.lastname@example.org> To: email@example.com Subject: Вам необходимо увеличить объем почтового ящикa. Date: Wed, 15 Jul 2015 15:19:46 +0300 Sender: <firstname.lastname@example.org>
We see that in this crude phishing attempt, a
Sender: header is visible.
From: header is entirely fake and uses cyrillic letters in “Gооgle”;
gmail.content.com does not resolve, and probably never did.
This did not prevent GMail from passing the email through,
since the SPF checks were performed against the
Received-SPF: pass (google.com: best guess record for domain of email@example.com designates 184.108.40.206 as permitted sender) client-ip=220.127.116.11; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of firstname.lastname@example.org designates 18.104.22.168 as permitted sender) email@example.com
The phishing link is
which immediately redirects (at HTTP level) to
The redirect helps the attacker to avoid the spam filter, since
is not a suspicious site. However, the actual redirect is to a legitimate-looking
.gq is a TLD providing free domain registrations.
In an unlikely case that the user glances at the URL bar, it will look familiar,
although even the attacker used a wrong name:
account instead of
The phishing page was probably a clone of the real Google Account page, redirecting to the real thing after a couple of password entries.
Phishing Email 2
A second crude attempt, using a completely different strategy, was attempted five days later on 20/07/2015. Perhaps the attackers tried to hire someone else, or used a different toolkit, since this email (which went straight to spam folder) appears to use a generic, and still functioning, phishing system (observed on 26/03/2016). Here is the link:
It redirects to:
where an authentic-looking Google Account page requests a password for user
After two inputs, the page redirects to a real Google Drive login page.
Both hosts above resolve to
22.214.171.124, a server at Serverius
data center in Netherlands — probably acquired via Kazakh BladeWeb
reseller (Qiwi, WebMoney and Bitcoin accepted as payment). The email itself was sent from
126.96.36.199, a Reg.RU server (WebMoney and Bitcoin accepted).
For some reason (incompetence?), this email used
firstname.lastname@example.org as the
envelope address, which of course caused it to fail SPF checks:
Received-SPF: softfail (google.com: domain of transitioning email@example.com does not designate 188.8.131.52 as permitted sender) client-ip=184.108.40.206; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning firstname.lastname@example.org does not designate 220.127.116.11 as permitted sender) email@example.com; dmarc=fail (p=NONE dis=NONE) header.from=mail.ru Received: from u0087216 by server112.hosting.reg.ru with local (Exim 4.72) (envelope-from <firstname.lastname@example.org>) id 1ZH6RP-0001xF-Ij for email@example.com; Mon, 20 Jul 2015 11:28:51 +0300
Phishing Email 3
The first two crude attempts were thus unsuccessful, and a day later on 21/07/2015, the attackers sent another email. Compared to the first email, this time it was a login prevention warning instead of the tired disk quota warning — a much more viable strategy. The “password reset” link was more elaborate:
and there was no
Sender: header. Instead, a fake DKIM signature was used:
Received-SPF: neutral (google.com: 18.104.22.168 is neither permitted nor denied by best guess record for domain of firstname.lastname@example.org) client-ip=22.214.171.124; Authentication-Results: mx.google.com; spf=neutral (google.com: 126.96.36.199 is neither permitted nor denied by best guess record for domain of email@example.com) firstname.lastname@example.org; dkim=neutral (body hash did not verify) email@example.com Received: by n1.tcphost.net (Postfix, from userid 2967) id 23B431500FF3; Tue, 21 Jul 2015 21:17:16 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gmail.content.com; ...
The use of DKIM signature, although fake, likely pushed GMail’s spam filter to err on the side of (non-)caution, and pass the email through. The server was different as well — a VDS in Netherlands (a less suspicious IP), provided by Hosting.Energy, a Ukrainian hosting provider. Of course, the hoster accepts WebMoney and Bitcoin, and there are free options as well.
The third phishing attempt was successful — another unrelated email arrived to the inbox on the next morning, and that’s the end of the timeline.
It is pretty clear that Tatyana Golikova was a designated target — in other words, Shaltay-Boltay is not a mere side-effect of some other grandiose enterprise, as claimed by the group members.
I am merely guessing, but my impression is that the group is a one or two-man effort, using the same one-trick pony (email phishing) to gain access to sensitive documents. Group’s income is likely exaggerated, which is an understandable tactic. For instance, a doubtless more capable and resourceful, the infamous Hacker Hell does not exactly stand out as a successful entrepreneur.
There is also an interesting twist: in January 2015, half a year earlier, a similar fake email address, with the same originating IP block as in the first phishing attempt (McHost.Ru), was used against a Ukrainian anti-separatist doxxing NGO. There is as yet insufficient data for determining whether the site was an unsuccessful target of Shaltay-Boltay, or someone else was using the same phishing toolkit.
Anyway, such spear phishing attacks, targeting politicians, journalists and dissidents, most of whom are pretty dumb (the politically-correct form is “non-technically minded”, but it means the same thing), and have an inflated ego to match, are nearly impossible to prevent. Methods like two-factor authentication may aid in recovering a stolen account, but they cannot prevent the attacker from gaining access in the first place, since the fishing page can simply pass the authorization token further down the chain in real time.
This post should not be construed as a criticism of group’s activity. Exposing corruption is always laudable. However, I find it disappointing that it is yet another case of technical experts picking the (probably not even that profitable) path of being used as assets in primitive Election Day-style political games. I hope to further explore this subject in another post.