An IRS tax refund phishing scam illustrates the widespread failure of hosting and antivirus providers' security measures
Scams focused on stealing tax refunds remain highly profitable, despite the fact that they are well known and understood by security professionals and the general public, and have been for years. A variety of distribution methods are used, with the common threads being the use of IRS logos and bureaucratic-sounding language to convince users to click a link, download and execute a file and/or send personally identifying information like a Social Security number. A recent example of one such a scam that I came across is a damning illustration of the failure of online service providers to protect users from obvious and simple malware distribution methods.
In the example I wish to discuss today, the distribution method was a spammed email that on a small ISP's installation of SpamAssassin (note: I am not an admin or employee of this system; I'm a customer) received an X-Spam-Status score of 5.3 after being flagged with the following variables:
While the default SpamAssassin threshold for marking a message as spam is 5.0, few admins leave this default value. SpamAssassin itself recommends that admins of multiple user mail servers use a threshold of 8 to 10. I don't have this ISP's spamassassin.conf file, and its obviously been customized. My point here isn't to take issue with SpamAssassin, which I have used for many years, but to demonstrate how this message made its way to mailboxes through pretty solid security software despite these being included in the headers:
Here's another depressing bonus. In addition to SpamAssassin, the recipient mail server had clamav installed. The message had a .ZIP file attachment, and the mail server's clamav install marked it as clean:
One round through Einar Lielmanis' JS Beautifier later, and we have this:
The script creates an EXE file in the %TEMP% directory - usually something like C:\Users\UserName\AppData\Local\Temp - that is named some random string, and fills it with a bunch of garbage that it retrieves from one of the three domain names listed: dickinsonwrestlingclub.com, syscomm.smartlanka.net or les-eglantiers.fr.
There are a number of domains and hosts associated with this scam.
Taking a look at the hosts involved in this scam provides even further disappointment. abitindia.com, whose email is managed by Gmail, is providing the return-path for the spam messages but not the reply-to. Replies, incredibly, go directly to the IRS support email address. The reply-to header is commonly forged so that backscatter goes to some random sucker. In this case, abitindia.com is affiliated with the sender domain netspaceindia.com:
In other words, in many circumstances backscatter recipients are innocent victims. That is not the case here - the sender is managing the backscatter recipient address, likely to keep their mailing lists updated. As such, Google could play a role in putting a stop to this scam - a review of the backscatter would make the relationship between sender and backscatter recipient obvious, and in an ideal world would precipitate the suspension of the Google Apps account for "abitindia.com".
To be fair, Google's responsibility here is minimal - particularly when compared to the role that every other hosting provider plays in this. The Planet and Digital Ocean are providing the infrastructure for the spam campaign, while Bluehost, Cogeco and Consolidated Telcom are providing the infrastructure for hosting the malware. Its likely that the accounts for these providers were created using fraudulent/stolen payment information, or legitimate accounts were compromised. This sort of thing is an everyday occurrence for hosting providers; for providers who do not invest in abuse response, these types of scams can use the same accounts with the same hosting providers for months if not years. When I come across this sort of scam, I do my best to inform the hosting providers involved using the abuse contact information that is required to be associated with IP/DNS registrations, along with enough evidence for the provider to confirm Im not a nut. It is unusual to receive a response and even more unusual to receive a non-automated response. It is just as unusual for hosting provider staff to review their abuse@ contacts, let alone resolve the issues they receive.
Hemming and hawing over the need for state intervention to prevent "cyber-attacks" (vomit) and scams like the ones described here are all over the place. Many of those who support such a view make it a point to justify government intervention because of the incredible sophistication and technical complexity of the scams that plague internet users. However, the overwhelming volume of the scams I have encountered over the course of my career involved well known techniques and software. There is significant room for improvement in security practices with applying what we already know: like how to prevent (or rapidly stop) a 30 year old scam using 20 year old spam techniques to circulate 10 year old malware.
In the example I wish to discuss today, the distribution method was a spammed email that on a small ISP's installation of SpamAssassin (note: I am not an admin or employee of this system; I'm a customer) received an X-Spam-Status score of 5.3 after being flagged with the following variables:
X-Spam-Status: No, score=5.3 required=10.0 tests=AM_TRUNCATED,CK_419SIZE,
CK_KARD_SIZE,ENV_FROM_DIFF,ENV_FROM_DIFF0,FROM_SECURITY,HAS_REPLY_TO,
HEADER_FROM_DIFFERENT_DOMAINS,JUNKE_IXHASH,LINK_NR_TOP,MAILPHISH_REPLYTO,
PSTOCK_PART,TO_NOREAL,XPRIO,ZIP_ATTACH shortcircuit=no
autolearn=disabled version=3.4.0
While the default SpamAssassin threshold for marking a message as spam is 5.0, few admins leave this default value. SpamAssassin itself recommends that admins of multiple user mail servers use a threshold of 8 to 10. I don't have this ISP's spamassassin.conf file, and its obviously been customized. My point here isn't to take issue with SpamAssassin, which I have used for many years, but to demonstrate how this message made its way to mailboxes through pretty solid security software despite these being included in the headers:
From: "Internal Revenue Service" <office@irs.gov>
Reply-To: "Internal Revenue Service" <office@irs.gov> Return-Path: <servers@abitindia.com>
Here's another depressing bonus. In addition to SpamAssassin, the recipient mail server had clamav installed. The message had a .ZIP file attachment, and the mail server's clamav install marked it as clean:
X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
X-Virus-Status: Clean
The attachment does in fact have a javascript nasty-ware. And clamav is not alone in its failure to pick up the file. According to Virustotal, 31 out of 56 AV platforms failed to detect this file - including Symantec, TrendMicro, Panda, Malwarebytes, Avast and Avira. In defense of these AV heavyweights, the file used a single basic obfuscation function to disguise its purpose - which at the moment is apparently enough to fool these AV packages.One round through Einar Lielmanis' JS Beautifier later, and we have this:
The script creates an EXE file in the %TEMP% directory - usually something like C:\Users\UserName\AppData\Local\Temp - that is named some random string, and fills it with a bunch of garbage that it retrieves from one of the three domain names listed: dickinsonwrestlingclub.com, syscomm.smartlanka.net or les-eglantiers.fr.
There are a number of domains and hosts associated with this scam.
| Domain | IP | Host | Registrant | Contact | DNS IPs |
|---|---|---|---|---|---|
| dickinsonwrestlingclub.com | 72.20.64.58 | Consolidated Telcom | Perfect Privacy, LLC | N/A | 72.20.64.11, 72.20.64.12 |
| syscomm.smartlanka.net | 69.89.31.73 | box273.bluehost.com / Bluehost / Unified Layer | Dilhan Seneviratne | prabhath247@gmail.com | 74.220.195.31, 69.89.16.4 |
| les-eglantiers.fr | 76.74.242.190 | hp92.hostpapa.com / Peer 1 Network / Cogeco | John Huisman / Camping Beau Rivag | huisman.huisman@orange.fr | 69.90.36.133, 204.15.193.53 |
| Domain | IP | Host | Email Provider | Contact | DNS IPs |
|---|---|---|---|---|---|
| abitindia.com | 54.165.102.41 | Amazon EC2 | Gmail | accounts@abitindia.com | 50.23.136.229, 50.23.75.96, 162.251.82.118, 184.173.150.57 |
| mail.netspaceindia.com | 74.54.133.186 | The Planet | N/A | help@netspaceindia.com | 205.251.196.41, 205.251.192.135, 205.251.199.124, 205.251.195.214 |
| netspaceindia.com | 104.131.68.147 | Digital Ocean | N/A | help@netspaceindia.com | 205.251.196.41, 205.251.192.135, 205.251.199.124, 205.251.195.214 |
Taking a look at the hosts involved in this scam provides even further disappointment. abitindia.com, whose email is managed by Gmail, is providing the return-path for the spam messages but not the reply-to. Replies, incredibly, go directly to the IRS support email address. The reply-to header is commonly forged so that backscatter goes to some random sucker. In this case, abitindia.com is affiliated with the sender domain netspaceindia.com:
Domain Name: ABITINDIA.COM Updated Date: 2014-11-24T05:21:07Z Creation Date: 2006-11-23T19:31:19Z Registrar Registration Expiration Date: 2015-11-23T19:31:19Z Registrar: PDR Ltd. d/b/a PublicDomainRegistry.com Registrar IANA ID: 303 Registrant Name: Netspaceindia Registrant Organization: Netspaceindia Registrant Street: Hall no 3, Wing B, Parshuram apt Above Woodlands Showroom College Road Nashik Registrant City: Nashik Registrant State/Province: Maharashtra Registrant Postal Code: 422005 Registrant Country: IN Registrant Phone: +91.9975444464 Registrant Email: accounts@abitindia.com Name Server: dns1.netspaceindia.com Name Server: dns2.netspaceindia.com Name Server: dns3.netspaceindia.com Name Server: dns4.netspaceindia.com
In other words, in many circumstances backscatter recipients are innocent victims. That is not the case here - the sender is managing the backscatter recipient address, likely to keep their mailing lists updated. As such, Google could play a role in putting a stop to this scam - a review of the backscatter would make the relationship between sender and backscatter recipient obvious, and in an ideal world would precipitate the suspension of the Google Apps account for "abitindia.com".
To be fair, Google's responsibility here is minimal - particularly when compared to the role that every other hosting provider plays in this. The Planet and Digital Ocean are providing the infrastructure for the spam campaign, while Bluehost, Cogeco and Consolidated Telcom are providing the infrastructure for hosting the malware. Its likely that the accounts for these providers were created using fraudulent/stolen payment information, or legitimate accounts were compromised. This sort of thing is an everyday occurrence for hosting providers; for providers who do not invest in abuse response, these types of scams can use the same accounts with the same hosting providers for months if not years. When I come across this sort of scam, I do my best to inform the hosting providers involved using the abuse contact information that is required to be associated with IP/DNS registrations, along with enough evidence for the provider to confirm Im not a nut. It is unusual to receive a response and even more unusual to receive a non-automated response. It is just as unusual for hosting provider staff to review their abuse@ contacts, let alone resolve the issues they receive.
Hemming and hawing over the need for state intervention to prevent "cyber-attacks" (vomit) and scams like the ones described here are all over the place. Many of those who support such a view make it a point to justify government intervention because of the incredible sophistication and technical complexity of the scams that plague internet users. However, the overwhelming volume of the scams I have encountered over the course of my career involved well known techniques and software. There is significant room for improvement in security practices with applying what we already know: like how to prevent (or rapidly stop) a 30 year old scam using 20 year old spam techniques to circulate 10 year old malware.