Thanks to Graham Chantry of SophosLabs for his help with this article.
Here’s an interesting phishing trick with a lot to teach us.
Microsoft tweeted about it last week:
Note the bit about how this trick was “giving phishers virtually unlimited phishing URLs”, a detail that caught our eye.
Here’s our take on it.
Imagine you’re a crook
If you’re a crook who wants to run a web-based phishing attack to harvest account passwords, you usually do something like this:
- Set up a web server that looks just like the account’s regular login page. You can copy the images, rip off the HTML and the bits of JavaScript you need from the genuine site, or use carefully-taken screenshots, so that a regular user will think it looks like the real deal.
- Send out an email or instant message advising, asking, cajoling or demanding the recipient to login right away. For verisimilitude, you can copy text and logos from a recent email from the brand you are targeting.
- Include a handy link in the email that goes straight to the fake login page. You need to use your own server name and URL, but you may be able to come up with links that are legitimate-looking enough to trick a hasty user.
The hardest bit in all of this is getting hold of a server to use in the first place.
You could set up your own server, but in today’s cloud-centric world, that’s expensive, time-consuming and might leave an enticing trail for law enforcement to follow.
Nevertheless, if you control the server completely then you can make it do whatever you want.
You are stuck with the server name, e.g. example.com, but you can program it to respond to any URL you like, so that example.com/brandrip7/login is as easy to arrange as, say, example.com/account/reset?user=jimbo.
That means you can use the same server to phish several different brands at the same time.
You could hack someone else’s server, or buy access to a hacked server, but that might leave you with a weird and improbable web link – a purported email login that goes to an online clothing store, for example, which doesn’t really add up.
You can bask in the existing reputation of the hacked server, which is often advantageous, especially if the domain name is a few years old and the site hasn’t been hacked before – that means it’s probably not yet on anyone’s blocklist.
But you might not get much flexibility in the URLs you can use – for example, if the hack relies on a security hole in the site’s image gallery, you might be stuck with example.org/media/files/thumbs.php or similar.
Or you could create a free (or trial) account on a web hosting service, giving you a trusted platform – together with a handy TLS certificate that will put a padlock in your victim’s browser.
Although you end up with a server name that is clearly not the site you want to look like, such as hosted.example, the service may add your username, or a nickname you can choose, at the left-hand end.
So you might end up with something like this, which looks surprisingly realistic despite the shouldn’t-be-there domain name at the end:
https://well-known-credit-card-company-name-com.hosted.example
https://webmail.service.name.rippedoffvendor.com.hosted.example
Left-stuffed domain names
By stuffing a domain name with additional components at the left-hand end, you push the true domain name – often an obvious giveaway that the site is not what it claims to be – off to the right.
On a mobile device, or a laptop with limited screen space, browser windows often end up truncating URLs in the address bar so that you only see the start of the URL.
In other words, the giveaway that the page is hosted on a popular cloud service is hidden away, while the implication that the page is an official page belonging to a completely different brand is clearly visible.
Here’s an example of how you may end up seeing less than the truth, but enough to look real.
The real Naked Security site looks something like this, viewed in a slighly cramped browser window:
Firefox has turned the nakedsecurity part of the server name grey, to remind you that it’s not the final, officially registered part of our domain name – that is, of course, sophos.com, which won’t fit in the address bar here.
If you’re cautious, you can click on the padlock to reveal more details about the web certificate sent back by the site:
Interpreting the certificate you see here isn’t easy, but you can at least see which web certificate company vouched for us, and how much detail about our address they were prepared to attest to.
My home site (these images have been retouched to change the domain name to acme.example), in contrast, looks like this:
The certificate is issued by a different authority – in this case, it’s a free Let’s Encrypt basic validation certificate, vouching only for the fact that I can login to my own web server and edit its content. (Basic validation, as the name suggests, does a minimum of automated checking to see whether you have access to the relevant server, but doesn’t try to verify that you have the authority to access it.)
So, if I create a subdomain of my own called nakedsecurity.sophos.com.acme.example then I can serve up a vaguely passable fake of the real site, like this:
There’s a lot wrong here, notably that the text sophos.com is greyed out by Firefox to remind me that it is part of the server name but not the actual domain name, which won’t quite fit in the address bar.
Also, the site is a bit iffy – I used a poor-quality screenshot instead of real HTML, for a quicker but less precise result, and you can just see the text acm... in the address bar.
Even though it’s faded out at the far right end, the darker a nevertheless acts as a handy indicator that there is a domain name at the end of the address, and therefore something is not what it seems.
Bringing up the certificate is a dead giveaway, because it’s clearly isssued for a domain that does not end in sophos.com, and this certificate says nothing about the site owner’s connection with, or authority over, any sophos.com web properties:
You could also click in the address bar and scroll to the right to expose the left-stuffing trickery going on here.
In other words, with a bit of care, even passable fake websites are often easy to spot.
Phishing in the cloud
In the example mentioned in Microsoft’s tweet above, the crooks decided not to run a server of their own.
Instead, they created a number of server instances on Google’s web.app platform, a web hosting service based on Google’s Firebase product.
If you visit the main web.app page, you will see:
By creating a web presence on this platform, you can easily acquire a site name that is a subdomain of Google’s cloud property, complete with Google’s own HTTPS certificate derived from the top-level site.
In fact, all (or at least most) subdomains automatically seem to resolve via DNS, produce default responses from the Firebase servers, and are covered by the master web.app certificate, as you can infer from these screenshots.
A randomly-chosen set of web.app subdomain names all produce the same two IP numbers when looked up using DNS:
Picking any of the random subdomains from this list leads to a default “holding page”, commonly seen when you visit a hosting server and try to acess content that hasn’t been created or domain names that no one has claimed yet:
Clicking on the padlock and drilling down to view the web certificate details shows that Google has taken responsibility for all subdomains of web.app, using what’s known in the jargon as a wildcard certificate.
The * (asterix) character is known as a wildcard and is commonly used in filenames and domain names to denote that ‘any legal text can go here’.
The Subject Alternative Name in a web certificate allows the owner of a domain to use the same certificate to cover a number of different domains, as well as covering all possible subdomains of those various names by use of the wildcard character, as you see here:
Failure used for success
The crooks apparently created a whole slew of similar but different web.app domains.
We examined 56 different ones that were reported via Google’s VirusTotal service, a site through which users and researchers can submit (and the cybersecurity industry can automatically share) suspicious programs and websites.
Of those, four domains gave HTTP 451 errors, a web return code that denotes ‘blocked for legal reasons‘:
The remaining 52 domains gave HTTP 404 errors, denoting ‘page not found’, but only 43 produced a ‘Site not found’ holding page (as shown in the screenshot above), which is what you might expect for a page that supposedly denotes a page that doessn’t otherwise exist.
Nine of the 52 ‘page not found’ domains had indeed already been set up, and were configured so that their default ‘page not found’ content was a phishing page:
Note that although HTTP 404 means ‘page not found’, the web traffic that reports the offending error code is itself a regular HTTP reply, and can include a web page in its reply body.
For a user looking at a browser window, a ‘page not found’ page shows up in just the same way as a reply that’s flagged with an HTTP 200 code, which means ‘OK’.
In other words, and the irony is not lost on us, a ‘page not found’ is reported by means of a page that was found.
The Apache web server even has a special 404 page to tell visitors that your official 404 ‘page not found’ page wasn’t found. We don’t know what happens if the ‘page not found page not found’ page itself suffers a ‘page not found’ error.
In case you’re wondering, the look that the crooks have come up with on their phishing site is surprisingly close to the real thing.
Here’s what the official Microsoft website looked like in the same browser at the same time as the fake screenshot above was taken:
Why use a holding page as a phishing page?
As Microsoft mentioned at the start, using a HTTP 404 as a genuine page is a neat trick for the crooks, because it means that any URL that lands on the phishing site will work, without the need for the crooks to go into their various web.app accounts and set up a new URL for each new phishing campaign.
Sure, the domain names, so far anyway, are limited to the nine that are already active (with 43 left up the crooks’ sleeves for later, it seems), but each of these nine domains can be combined with any sort of URL path – that’s the stuff in the URL that follows the slash that follows the domain name.
Any of the following URLs would work without needing each URL to be configured separately, and therefore without needing any advance planning:
https://outlookloffice365userxxxxxxxx.example/ue10kfsuja8ur/hee8rjmn1il5ngeg159
https://outlookloffice365userxxxxxxxx.example/t7f95d225an169lousbhfk1ocp72vigg
https://outlookloffice365userxxxxxxxx.example/2019/08/19/important-note.html
https://outlookloffice365userxxxxxxxx.example/v5a5eflkm6vhglru
https://outlookloffice365userxxxxxxxx.example/login.aspx
https://outlookloffice365userxxxxxxxx.example/reactivate-your-account?user=dpk6n69
(Actually, we concocted these URLs following RFC 6761, so they aren’t real.)
Simply put, the crooks have found a way of using an uncomplicated web hosting platform to serve up as many different phishing URLs as they like, with no programming or complex configuration scripting needed.
By the way, if you were to fill in the fake login page and submit it, then the web form, containing your username and password, would be uploaded via a hacked page on a hotel website in East Africa.
The hotel’s server uses HTTPS, as you would expect these days, so your browser won’t produce a warning to tell you that you are about to send a password over insecure HTTP.
With both the web.app landing page and the hotel’s data exfiltration page using encrypted connections, the crooks have wangled themselves HTTPS servers without needing to apply for certificates themselves, simply by sticking to the cloud and using servers that were already encrypted.
Fortunately, it looks as though the ‘upload server’ that’s been co-opted by the crooks was compromised via a vulnerability that hijacked a specific server-side script in a specific directory.
In other words, for all that the crooks have 52 different domain names prepared for the phishing links themselves, and a practically unlimited supply of URLs to use with each of those 52 domains…
…they’re stuck, in this attack anyway, with a single, inflexible, easily blocked URL to use for exfiltrating your passwords.
That makes the final part of this scam – the last click without which the crooks come away with nothing – comparatively easy to protect against.
A chain, as they say, is only as strong as its weakest link, and that adage works to help us keep the crooks out as much as or more than it helps them sneak in.
Sophos products block access to the booby-trapped phishing pages
and to the hacked site where stolen data gets uploaded.
What to do?
- Avoid login links that arrive in a messsage. If you need to login to one of your online accounts, use a link that you figured out yourself. Reputable services may ask you to login, but they generally avoid sending you a link simply because they wouldn’t expect you to click it, and indeed would advise you not to.
- Consider a password manager. In an attack like this, your password manager wouldn’t put your Outlook password into the East African hotel website because it would have nothing to relate the two services.
- Use 2FA on every account you can. 2FA codes are usually sent to or generated on your phone every time you login, making your password alone much less useful to a crook. Even if a phishing site asks for a 2FA code and you have one ready to supply, the extra step gives you a chance to stop and think before you connect.
- Use an anti-virus with built-in web filtering. A product like Sophos Home, for example, not only blocks malware that tries to infect your computer but also keeps track of the websites you are about to send data to. Therefore it can stop you leaking your password in cases like these, as well as alerting you to the danger.
- Pay attention to the telltales in your browser. Sometimes, even the most carefully concocted phishes are obvious if you take the time to check the indicators that your browser provides. The greyed-out part of a URL in the address bar can help you spot a left-stuffed domain, and stopping to examine web certificates helps you rumble fake or hacked sites.
- Know where your cloud assets are. Cloud servers are easy to set up in a hurry, and just as easy to forget about afterwards. A product like Sophos Cloud Optix can help you keep track of your cloud usage, so you aren’t putting data where it shouldn’t be, and you aren’t inadvertently providing free ‘cybercrime hosting’ for sneaky crooks.
- Keep your users informed. Phishing pages like the one shown here are easy to fall for because of their elegant simplicity – by copying distinctive pages from well-known brands, the crooks keep your suspicions low. Sophos Phish Threat lets you train and test your users using realistic but safe phishing simulations.
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/YJwPC_v71rM/
