Steam Community phishing attacks continue unabated

Phishers are still using look-alike domain names to steal Steam credentials from unsuspecting victims, which suggests that this approach is proving rather successful for the criminals. These types of attack are particularly effective if carried out within Steam's own browser, which lacks the protective features seen in most mainstream browser software.

Since Netcraft first highlighted this issue in June last year, nearly a third of all phishing attacks against Steam users continue to make use of look-alike domains. Some of these domain names, such as "steamcornmunity.com", look practically identical to the real steamcommunity.com domain, particularly when displayed in the address bar of the built-in Steam browser:

This is not steamcommunity.com

This is not steamcommunity.com

Look-alike domains play a particularly important role in Steam phishing attacks, as victims are often tricked into visiting these phishing sites by fraudsters sending messages through Steam's own chat client or by enticing them to visit links in forum posts. These spearphishing attacks are obviously more likely to succeed if a victim believes the link is going to take him to the genuine Steam Community website.

First seen more than a year ago, the look-alike domain steamcomrnunity.com is still being used for Steam phishing attacks today. After stealing a victim's credentials, it redirects the browser to the genuine Steam Community website.

First seen more than a year ago, the look-alike domain steamcomrnunity.com is still being used for Steam phishing attacks today. After stealing a victim's credentials, it redirects the browser to the genuine Steam Community website.

It is very unusual for such a high proportion of a target's phishing attacks to make use of custom paid-for domain names. The vast majority of phishing attacks against other targets, such as banks, are typically hosted on existing compromised websites (where the domain name obviously cannot be changed), or make use of specially crafted subdomains on free hosting platforms.

Many of the other attacks against Steam users fall into the latter category, attempting to mimic the Steam brand by using less-convincing subdomains that are cheaper or free to obtain. Examples of these have included stempowered.16mb.com, steamsupportcom.esy.es and steamcomnunity.besaba.com.

Netcraft has blocked a total of 2,000 unique Steam phishing URLs in the past three months alone. Interestingly, more than 600 of these URLs were used by attacks carried out on Christmas day. This is often thought to be a good time for these types of attack, as many technical support and customer services representatives are generally unavailable during this period. This gives the fraudsters additional time to monetize stolen accounts, as it is likely to be a few days before anyone can respond to a victim's compromised account enquiries.

Steam Trading makes it possible to monetize stolen Steam accounts, and provides an obvious incentive to go phishing on Steam. This in turn explains why many users have opted to increase the security of their accounts by enabling Steam Guard, which is essentially a two-factor authentication mechanism. Even if the phisher manages to steal a victim's Steam username and password, he will not be able to log into the account without also submitting a special access code.

The special access code is sent to the victim via email, so in order to fully compromise the Steam account, the fraudster must also compromise the victim's email account, trick the victim into disabling Steam Guard, or trick him into submitting the access code on behalf of the fraudster. Many of the previous attacks enticed victims to download and run a SteamGuard.exe executable, which was actually malware designed to steal a special authentication file from the victim's computer. This allowed the Steam Guard protection to be bypassed whilst also paving the way for instant trading by eliminating the new-device time delay protection which would have applied if only the access code was stolen.

2% of the domains used in these attacks make use of the .ru top-level domain (steamsommunlty.ru, for example) rather than the more intuitive .com. This choice of TLD is perhaps no coincidence, as some of the fake Steam Guard binaries point to a website called SteamComplex, which also uses a .ru top-level domain.

Hosted on the CloudFlare content distribution network, steamcomplex.ru is written in Russian and appears to be selling the Steam malware used in these attacks. Many of the Steam phishing attacks, such as the one shown in the screenshot above, are also clearly aimed at Russian speakers.

Is Steam doing enough to protect its users?

The ongoing recurrence of these attacks suggests that Steam might not taking the appropriate action to deal with these phishing sites, or if it is, its actions are ineffectual. For example, the steamcomrnunity.com look-alike domain has been serving the same Russian phishing content for around a month. It is hosted at a place which is usually responsive to takedown requests, which strongly indicates that no effort has been made to take it down.

Additionally, when victims are redirected from a known phishing site to the real Steam site, the location of the phishing site is revealed in the HTTP Referer header (shown below). This would allow the Steam Community website to recognise that the user's credentials may have just been phished, but it does not take the opportunity to display any warnings in the victim's browser.

GET / HTTP/1.1
Host: steamcommunity.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://steamcomrnunity.com/ 
Cookie: [removed]
Connection: keep-alive

Finally, while all mainstream browsers deny access to known phishing sites like the ones shown above, Steam's own built-in browser does not. This lack of blocking, coupled with the easily-spoofed address bar, makes the Steam browser remarkably vulnerable to these attacks.

The "steamcomrnunity.com" phishing site is blocked natively within Internet Explorer. The domain in the address bar is also displayed more clearly, allowing sharp-eyed users to identify it as fake.

The "steamcomrnunity.com" phishing site is blocked natively within Internet Explorer. The domain in the address bar is also displayed more clearly, allowing sharp-eyed users to identify it as fake.

In mitigation, some users have noticed that the Steam chat client has started removing some of these malicious links in recent days, which will hopefully limit the effectiveness of the chat-based attack vectors.

A malicious link removed from a Steam chat message (highlighted).

A malicious link removed from a Steam chat message (highlighted).

Netcraft's phishing site feed is used by all mainstream browsers. For more information about this and our phishing site takedown service, please contact us at sales@netcraft.com.

Student Loans Company advice makes phishing easier

Anticipating a surge in phishing attacks over the festive period, the Student Loans Company warned students in Britain to be on the lookout for suspicious emails. Unfortunately, some of its anti-phishing advice could have backfired, potentially increasing the risk of students falling for phishing attacks.

Warning students to be on the lookout for fraudulent emails attempting to impersonate the SLC, it told The Telegraph and Money Saving Expert that any official correspondence would come from the email address notifications@slc.co.uk. However, this advice is rather dangerous because the slc.co.uk domain has not been configured to prevent spoof emails being sent from this address.

In particular, slc.co.uk does not have a Sender Policy Framework record. SPF rules can be used to describe who can send email on its behalf, and the lack of any policy means there are no restrictions on who can send emails appearing to come from notifications@slc.co.uk.

If students infer from the SLC's advice that all emails from notifications@slc.co.uk will be legitimate, then fraudsters will be able to carry out much more convincing phishing attacks simply by spoofing emails from this address.

The domain also lacks a DMARC record, which means the SLC cannot choose what happens to forged emails that appear to come from the slc.co.uk domain. If correctly configured, such emails could not only be blocked by some email providers, but SLC would also be able to view the contents of forged emails and receive statistics to see how many are being sent.

Preventing forged emails is an important part of mitigating phishing attacks, as many attacks are initiated via email. A typical phishing email will play on the victim's sense of urgency — for example, by warning the student that his next payment may be lost or delayed if he does not update his records at the fraudster's "secure" website that masquerades as a real SLC website.

Once the victim has been tricked into visiting the phishing site, he will be prompted to enter a multitude of information which can be used to steal the loan money as soon as it arrives in his bank account. Most student loan phishing sites blocked by Netcraft usually ask for far more information than a conventional online banking phishing attack would do, capturing not just the victim's bank account details and card number, but also details about the student's university course and term time address.

Frozen phish

Despite the SLC warning of an increase in phishing attacks, it is fortunate that the fraudsters instead put an unexpected freeze on their phishing activity over the Christmas holidays. In fact, not a single student loan phishing site has been blocked by Netcraft since before Christmas day.

During 2014, Netcraft blocked more than 180 phishing URLs that impersonated the Student Loans Company or the Student Finance England service (which is run by the SLC), while SLC's fraud team took down around 150 phishing sites. Over the past three years, it claims to have prevented almost £3 million being stolen.

student-loan-phishing

The calm before the storm that didn't happen: Most student loan phishing attacks occurred at the start of the academic year (September), and all of those carried out in December took place before Christmas day. Despite the second loan instalments being sent out this week, no attacks have taken place since.

New students make particularly attractive targets for fraudsters, as many will have no previous experience at managing their own finances. Research by the British Bankers' Association suggests that one in six of those aged 18 to 25 could be vulnerable to money transfer scams; a higher proportion than any other age group.

Student loans in the UK typically consist of a tuition fee loan – which can be up to £9,000 per year and is paid directly to a student's university or college – plus a maintenance loan of up to £7,751, which is paid into the student's own bank account, making the latter component an obvious target for phishing fraudsters.

Organisations concerned about email impersonation attacks can use Netcraft's Fraud Detection service, which processes DMARC (Domain-based Message Authentication, Reporting and Conformance) reports on your behalf. These reports are sent by ISPs and e-mail receivers when they see any emails which claim to be from one of your own domains. A web interface shows the status of all of your own domains, any configuration changes required, and highlights unprotected domains being used by fraudsters attacking your customers. Netcraft can also provide real time alerts of phishing sites targeting your company, and our takedown service can be used to remove phishing sites.

Moonpig breach highlights need for app and API testing

A severe vulnerability in the API used by Moonpig's Android app has highlighted the need for organisations to apply greater scrutiny to the security of their apps and endpoints. Through its apps and website, the custom greetings card company sends out more than 12 million cards every year and turned over £53 million last year.

By enumerating an easily predictable sequence of user ID numbers, anyone could retrieve various information about millions of Moonpig customers, including names, addresses, and some credit card details. Because there was no authentication mechanism for the API, an attacker could also have placed orders on other customers' accounts.

Unlike with traditional web applications, much of what goes on beneath the glossy facade of an app is hidden from the user — but with the right tools and the right knowledge, it can be trivial to identify and exploit any vulnerabilities that might affect it. The Moonpig vulnerability exemplifies this, as the problem was not only easy to spot, but could be exploited simply by pasting a modified URL into a standard web browser.

The Moonpig vulnerability stemmed from the fact that the API trusted data sent from the app, without considering that it could have been altered or fabricated by a malicious party. This type of vulnerability fundamentally compromises the security of the application and the data it handles, and would likely be quickly identified in a third-party security test of the API.

The danger posed by this vulnerability was compounded by Moonpig's failure to react promptly — Moonpig purportedly knew about this issue 17 months ago after it was reported by one of its own customers. However, Moonpig failed to shut down or fix the vulnerable service until after the vulnerability was publicly disclosed last night.

Moonpig issued the following statement on its website today:

You may have seen reports this morning about our Apps and the security of customer details when shopping with Moonpig. We can assure our customers that all password and payment information is and has always been safe. The security of your shopping experience at Moonpig is extremely important to us and we are investigating the detail behind today's report as a priority. As a precaution, our Apps will be unavailable for a time whilst we conduct these investigations and we will work to resume a normal service as soon as possible. The desktop and mobile websites are unaffected.

Netcraft offers Mobile App Security Testing services and traditional Web Application Security Testing, both of which include testing of relevant APIs and other endpoints that may be commonly overlooked. Contact us at security-sales@netcraft.com to discuss your requirements.

Proxy auto-config attacks defeat 2-factor auth, hide using country specific content

Fraudsters have been using proxy auto-config (PAC) scripts to steal online banking credentials for several years, but as with most phishing techniques, it is inevitable for these attacks to evolve and become more effective. The latest spate of PAC attacks has achieved this by using geolocation technology to evade detection and select which targets to attack.

pac-attack

PAC attacks typically channel online banking traffic through rogue proxy servers, allowing fraudsters to gobble up unencrypted usernames and passwords when forms are submitted, or to hijack already-authenticated sessions by stealing session cookies. Being able to view and modify this traffic also allows two-factor authentication mechanisms such as one-time passwords to be easily defeated.

PAC scripts used in these attacks inevitably look suspicious, which highlights the fact that fraud is taking place. Consequently, it is in the fraudster's interest to stop these scripts being found by law enforcement agencies, or indeed anyone else who might be tasked with investigating or preventing the fraud.

The latest attacks use a PAC script which is hosted on a web server in the Netherlands. This server has been configured to refuse TCP connections from certain countries or locations, which could be sufficient to put an investigator off the scent – if the server simply does not appear to exist, they may not bother investigating further. Meanwhile, the remaining unblocked users will continue to fall victim to the PAC attack.

Where the server can be accessed, geolocation is also used to customise the contents of the PAC script. For example, a completely benign PAC script is returned to clients in Australia, which simply tells the victim's browser to connect directly to all websites; no proxying takes place:

Deobfuscated JavaScript from the benign PAC script

Deobfuscated JavaScript from the benign PAC script

Conversely, requesting the PAC script from Japan causes the following JavaScript to be returned:

PAC attack against Japanese banking customers (contents  deobfuscated for clarity)

PAC attack against Japanese banking customers (contents deobfuscated for clarity)

The FindProxyForURL function specifies which hostnames should be proxied through the fraudster's server. Anyone using this proxy script will be giving the fraudster an opportunity to observe or modify all unencrypted traffic flowing between his browser and each of the specified Japanese online banking websites.

If the victim browses to a site which does not match any of these patterns, his browser will not use the proxy and instead make a direct connection to be site. This serves to reduce the load on the fraudster's proxy server, as well as reducing the likelihood of the victim noticing something is awry. For example, if the victim performs a Google search for "what is my ip?", his browser will connect directly to google.com, causing Google to display the victim's own IP address rather than that of the fraudster's proxy.

Although online banking sites are the clear targets of these attacks, it is notable that many of these scripts, including the Japanese example, also target Facebook. The following PAC script is returned to clients in Switzerland, and proxies traffic destined for *.facebook.com, as well as several Swiss banking websites.

switzerland

It was not apparent why Facebook is being targeted among these banks, but compromised Facebook accounts could be useful for propagating the malicious proxy scripts to other users. For example, users could be tricked into manually editing their proxy settings by following instructions posted from a trusted friend's compromised account, or other social engineering tricks to get the user to download and run malware.

This PAC attack is still active, with Japan and Switzerland being targeted by distinct malicious scripts. Most locations are unable to connect to the Dutch PAC script server, apart from Australia and Poland, which receive an identical benign script which does not proxy any web traffic.

world-screenshot

Poor web application security can contribute significantly to the success of these proxy-based attacks. For instance, if the session cookies used on a bank's HTTPS website are not marked with the Secure attribute, then they will be transmitted unencrypted through the fraudster's proxy if the victim subsequently makes an HTTP request to the same hostname. Such attacks are much less likely to succeed if the targeted HTTPS site uses HTTP Strict Transport Security (HSTS) to prevent the connection being downgraded to HTTP.

Netcraft's Web Application Security Testing service can identify sites that are readily vulnerable to these types of attack. Banks and other organisations can also use Netcraft's takedown service to remove malicious proxy scripts and phishing sites from the internet, while infrastructure providers can use our phishing site feed to protect their users. For more information, please contact sales@netcraft.com.

ICANN hit by successful spear phishing attack

The Internet Corporation for Assigned Names and Numbers (ICANN) has fallen victim to a phishing attack which resulted in the attackers gaining administrative access to some of ICANN's systems, including its Centralized Zone Data Service (CZDS).

In an email alert sent this morning, ICANN said it believes a spear phishing attack in November resulted in several ICANN staff members' email credentials being compromised. The stolen passwords were then used to gain unauthorised access to multiple ICANN systems, which could have resulted in other usernames and passwords being compromised.

Although CZDS passwords are stored as salted hashes, ICANN has taken the precaution of deactivating passwords and API keys used on the compromised CZDS service. ICANN implemented some security enhancements earlier this year, which it believes limited the extent of the unauthorised access, and has implemented further measures since this attack.

The spear phishing emails involved in this attack were crafted to appear to originate from ICANN's own domain, which is a common tactic for phishers as it lends a fair amount of credibility to the emails. This domain spoofing could well have played an important part in the successfulness of the attack, but icann.org still does not feature any Sender Policy Framework records to specify who can send mail on its behalf.

Organisations concerned about these types of attack can use Netcraft's Fraud Detection service, which processes DMARC (Domain-based Message Authentication, Reporting and Conformance) reports on your behalf. These reports are sent by ISPs and e-mail receivers when they see any emails which claim to be from one of your own domains. A web interface shows the status of all of your own domains, any configuration changes required, and highlights unprotected domains being used by fraudsters attacking your customers.

Banks allow phishers to log in using Tor

The Financial Crimes Enforcement Network (FinCEN), a department of the US Treasury that combats financial crimes such as fraud and money laundering, recently released a report stating that "nearly $24 million in likely fraudulent activity" involved known Tor network nodes. The proportion of fraud that involves Tor is increasing rapidly: according to the report, October 2007 to March 2013 saw an increase of 50% in Tor-related fraud reports, whereas the most recent and much shorter period of March 2013 to July 2014 saw an increase of 100%. The report, which is not public, was obtained by computer security journalist Brian Krebs.

Tor is a piece of open-source software that attempts to provide online anonymity using a technique known as "onion routing". Messages sent by the user, such as HTTP requests from the user's web browser, are sent across the Tor network, instead of being sent directly to the destination server. Before a user sends a message, it is encrypted several times, along with information describing how the message should be routed through a virtual circuit across the Tor network. Circuits consist of a series of three randomly-selected Tor nodes: an entry node, a middle node and an exit node. The user's traffic enters the Tor network at the entry node. Each successive node is able to remove a single layer of encryption, which also reveals the next node to send the message to – akin to peeling the layers of an onion. When the message reaches the exit node, the final layer of encryption is removed and it is sent out across the Internet to its final destination. A similar procedure applies to messages travelling in the opposite direction back to the user, such as HTTP responses.

A diagram showing the nodes and the links between them in a Tor circuit. Although Tor does not encrypt the communication between the exit node and destination itself, it can be encrypted by the applications using Tor – for example, the user's web browser could use HTTPS instead of HTTP.

At no single point in the circuit are the source IP address, destination IP address and contents of the message all known to an eavesdropper simultaneously. To reduce the chance that users can be de-anonymized, Tor attempts to avoid picking nodes that share the same operator when creating circuits. This makes it difficult, but perhaps not impossible, for the identity of a particular user to be discovered. For example, an attacker who can observe a user's traffic as it both enters and leaves the Tor network can carry out a traffic confirmation attack, in which they correlate characteristics such as the timing or volume of the user's traffic, to link the user to the destination server.

Unsurprisingly, the anonymity provided by Tor makes it an attractive tool for fraudsters. For example, a phisher who has tricked users into handing over their online banking credentials might use Tor to log in to the bank's website with the compromised credentials. The bank's log files will show the IP address of the Tor exit node, rather than the phisher's own IP address, making it more difficult for the bank and law enforcement agencies to trace the fraud back to the phisher.

The report from FinCEN examined 6,048 suspicious activity reports (SARs) filed by banks and other financial companies between 2001 and 2014. Of those, 975 involved Tor, totalling $24 million of "likely fraudulent activity". The report goes on to state that "in the majority of the SAR filings, the underlying suspicious activity – most frequently account takeovers – might have been prevented if the filing institution had been aware that their network was being accessed via Tor IP addresses." Even if blocking Tor does not deter phishers from committing fraud entirely, it may cause them to switch to using services that are easier for the authorities to trace, such as open proxy servers or anonymous VPN services.

According to FinCEN's report, banks were only aware that Tor was involved in 3% of cases. Netcraft has visited the websites of the ten financial companies most targeted by phishing in the last six months, using a variety of Tor exit nodes located around the world, to check if any of the companies block Tor.

Position Company Blocks Tor traffic
1 PayPal No, but Tor users must solve a CAPTCHA
2 USAA No
3 AXA Banque No
4 SFR No
5 Wells Fargo No
6 Bank of America No
7 Chase No, but Tor users must use two-factor authentication
8 Lloyds Bank No
9 Banco do Brasil No
10 Cielo No

As shown in the table above, none of the login pages we visited blocked Tor traffic outright. For example, the following screenshot shows the appearance of PayPal's login page fetched from a variety of Tor exit nodes:

Screenshots of PayPal's login page fetched from several Tor exit nodes located across the world.

However, some of the websites we tested do treat Tor users differently during or after the login process – instead of blocking Tor users outright, they use Tor as an indicator for performing more stringent anti-fraud checks. (It is also possible that some companies perform additional checks that are not visible to end users.)

For example, Chase forces the use of two-factor authentication – by either email, text message or phone call – over Tor. PayPal requires Tor users to solve a CAPTCHA during the login process, which protects against automated attacks such as brute force login attempts, but would not prevent a phisher from manually logging into a victim's account. On the other hand, Lloyds Bank does not appear to visibly treat Tor users any differently to normal users.

A screenshot of the CAPTCHA that PayPal displays to users who attempt to log in over the Tor network.

The Tor Project considers services blanket blocking Tor traffic due to abusive and illegal behaviour by a proportion of its users to be a "threat to Tor's success". It advocates a range of other measures for sites to tackle abusive Tor traffic, including CAPTCHAs, two-factor authentication and establishing trust on a per-user rather than a per-IP basis. However, with the exception of two-factor authentication, most of these measures are targeted at abusive behaviour such as spam and are unlikely to prevent fraudsters from logging into compromised accounts.

Netcraft provides a wide range of countermeasures against phishing to many customers, including two of the world's top ten banks, as well as some smaller institutions at the sharp end of Internet crime – such as three of the largest Bitcoin exchanges and four Nigerian banks. For more information, please contact sales@netcraft.com.