Targeted credential theft attack uncovered by Senseon
Senseon recently detected a credential theft attack via a spear phishing email campaign during a Value Assessment with a global manufacturing company. Senseon detects these types of attacks frequently but very rarely do the attackers leave their source code available for all to see. So I thought I’d take their mistake and use it as an opportunity to share insights and to remind you what to look out for.
In this blog post I will provide an in depth analysis of the phishing pages created by the attackers to encourage the entry of their credentials. I will highlight what to look out for to spot phishing campaigns, and dive into the source code to show some of the techniques that the attackers used in an attempt to evade detection. I will also explain how the Senseon platform and its unique AI Triangulation is able to detect such attacks.
Senseon’s automated threat detection witnessed several suspicious Observations and automatically raised a Case for the attention of an analyst in the UI. This detection was not spawned from previous intelligence, rules, or signatures from a known attack. This organisation’s security team used this attack as an opportunity to reinforce the importance of vigilance in regards to phishing campaigns, ensuring password resets for the impacted individuals and also reviewed their 2FA practices.
Upon first inspecting the site created by the attackers to obtain credentials, it was quickly evident that this was a spear phishing attack directed specifically at the company. The attackers had left their directory listings on and it included a folder named after the company being targeted as well as archives of the source code for the website. As well as this the URL contained the word ‘Fattura’, which is Italian for Invoice. This could have been a rouse to trick the global target company that they were being sent an important document for review.
This phishing campaign was running on a domain which was registered with namesilo.com and used Cloudflare. This site is no longer active due to Senseon submitting a takedown request to Cloudflare. Whilst “.top” was number six of the top ten most suspicious top level domains (TLD’s) published by Spamhaus in 2018, with 43.8% of all “.top” domains being suspicious at the point this study was published. Despite this TLD being more suspicious than, lets say a .com, it was detected as this highly anomalous connectivity was seen not just by 1, but by 18 different machines (meaning that 18 members of staff had clicked on the malicious link) throughout the network within a short period of time.
Convincing enough to fool your organisation?
Analysis of the Phishing pages
In this section we will look at the pages built by the attackers and designed to deceive the victim when clicking the phishing link.
When the user first clicks the link in the email they are taken to a what appears to be a OneDrive login page (seen above), which allows the users to login via three different services in order to phish as many users as possible. The first two options both take the user to the same Microsoft login page. The landing page pulls in a number of assets from Imgur rather than self hosting them. This is fairly strange as it relies on third parties keeping their images live, as we will see later a number of the images linked have been removed.
Another mostly convincing login page
Here we can see the real login page (right), and the phishing page (left). Whilst they look incredibly similar and could easily deceive many individuals there are a few key giveaways that this indeed a front for malicious purposes. Firstly, it's generally uncommon for a login page not to include a signup link. We can also see the real page doesn't ask for a password on the same page but instead takes the user to a second page after checking the username is valid. Although quite trivial for an attacker to emulate, some corners have been cut in this campaign. For example the “Other Mail” login page was meant to emulate the login page for cPanel Webmail (image below). However, resources were being pulled from external sources rather than hosted by the attacker. Because these pulled sources have since been removed, these assets are missing from the attackers page - which really arouses suspicion.
Easier to spot the fake cPanel login
Here we see the real cPanel Webmail login page (Left) and the spoofed page (Right). Other than the missing assets this is another fairly low effort attempt at copying the pages design. For example the assets that did load have a very low resolution and making them appear blurry. The attackers page is also missing the reset password text and cPanel logo. The Webmail logo was stored on Imgur which has since been removed.
Once the victim has submitted their credentials via any of the three options, they are then directed to Verify.php. This collates the submitted information as well as details gathered from the site about the victim and emails it to the attacker. The user is then redirected to another page emulating a Google Apps login in an attempt to obtain the users phone number. Again, this page is missing assets (Google Logo) and therefore should arouse suspicion. There are a few other key differences to look out for here. Firstly, the real Google page will show you your email address when asking for information as well as providing links for more information. Whilst the phishing page does actually have some help links at the bottom, they all just redirect back to the same page.
Real (left), fake (right) Google Apps login
Source Code Analysis
Let's take a deeper look at the source code we were able to obtain from this spear phishing campaign. Typically in these scenarios we do not have access to the source code so this form of analysis is impossible, however in the case the attackers were kind enough to both leave directory listings on, as well as uploading an archive of their source code and notes. Most of the files in the archive are of little interest to us as they are just basic HTML and CSS that have been scraped from the legitimate sites they are imitating.
One of the interesting files is blocker.php. This coupled with the sites .htaccess file (used to restrict access to sites and is commonly used to stop web crawlers from indexing the site) have been specifically created to block a number of domains from accessing this site. These pages look for a number of keywords, IP address ranges, TLDs, referrers and user agents which if found, would direct the visitor to a 404 page. This is likely an attempt to evade detection and to stop online services marking the domain as a phishing site. The image below shows that even with these measures in place the automated Google system still managed to flag the site as malicious. Interestingly one of the IP ranges that was blocked belongs to the USA’s department of defence.
| Category | Blocked Items |
|---|---|
| Keywords (If the hostname of the device connecting container any of these it would be presented with a 404 page) | "Above" "Google" "Softlayer" "Amazonaws" "Cyveillance" "Phishtank" "Dreamhost" "Netpilot" "Calyxinstitute" "Tor-exit" "paypal" “Chrome” “Kaspersky” “Avira” “yahoo.com” “search.com” “bing.com” “lloyds” “crawl” “phishingsite-collector” “Spam”“phish” |
| IP addresses (If the source IP matched anything in the range it would be presented with a 404 page) | Google: “66.102.*.*” “66.249.71.179” ISPs “124.176.210.234” Telstra “125.18.56.109” Bharti Airtel “198.25.*.*" USA Department of Defence “64.106.213.*" (DataPipe, Inc.) Universities: “128.232.110.18” University of Cambridge “137.108.145.10” Open University “137.110.222.77” University of California “138.26.64.54” University of Alabama Other: “202.73.*.*” “202.75.*.*” “209.147.*.*” “209.59.*.*” “64.127.*.*” “65.110.*.*” “66.135.*.*” “66.16.*.*” “66.179.*.* ”“66.194.6.*.*” “80.178.*.*” “79.182.*.*” “87.69.*.*” “87.70.*.*” |
| User Agents (If the connecting host had a user agent containing any of these strings it would be presented with a 404 page) | “google” “msnbot” “Yahoo! Slurp” “YahooSeeker” “Googlebot” “bingbot” “crawler” “PycURL” “facebookexternalhit” |
| Referrer (Any requests coming from a host with the referer containing any of these strings will have their connection denied) | “Castlecops.com” “Internetidentity.com” “Phishfighting.com” “Phishtank.com” “spamcop.net” “spam“ “Phish” “Bezeqint.net” “yahoo.com” “search.com” “bing.com” “barak-online.com” “phish-inspector.com” “netcraft.com” “veritas.com” “verisign.com” “googlebot.com” |
| TLDs(Any requests coming from a host with the following TLDs will have their connection denied) | “.co.uk” “.gov.uk” “.edu” “net.il” “com.il” “co.il” “org.il” |
Another interesting file was Verify.php, which takes in the information from the login pages seen above and crafts it into a message to send to the attackers. Here we can see the attackers have included the email addresses to which the credentials will be sent to. Interestingly they have used both a Yandex and a Gmail account. Yandex is a popular email client in Eastern Europe and Russia so this provides us with some intel as to the origins of this attack. From the source code below we can see that not only is the username and password sent but also some identifying information about the victim, including their IP address and user agent. This page also calls the open source php class geoplugin which uses a number of methods to obtain location information about the victim which is then sent to the attacker.
The attackers have exposed their email addresses by uploading the source code to the site.
There function in this page used to obtain the visitors IP is particularly interesting. It contains the IP address of a “trusted proxy” which again exposed more information about the attackers. This function is particularly strange as obtaining the visitor's IP address via php is relatively trivial which could indicate that this function may be left over from a previous phishing campaign. The IP addresses included in the file was “94.74.81.174” which is located and owned by a Ukrainian ISP.
As detailed above, once the information has been sent to the attackers the Google phone verification page is loaded. The source code for this page is very sloppy and barely human readable which likely indicates that the code was scraped from the real google site and repurposed rather than mimicked or re-created. Again we see the sloppy work of the attackers where the Google logo is missing, but not because a third party took it down but instead because the attackers simply forgot to include the asset ‘top.PNG” on their site.
Unlike the others, this page contains code to pop up a little alert box when the victim tries to either right click on the page or presses their Ctrl key with the message “Secured”. This again is likely to be an artefact left over from a previous campaign as it seems to have no relevance here.
The final interesting file is loader.php which is in many ways similar to the verify page above. This again contains code to obtain information about the victim which is then emailed to the attackers along with the phone number the victim had entered in the previous step. It then shows a gif of a loading wheel seen below with a simple 10 second wait function.
Once all the details have been obtained the page fakes a loading wheel
Finally, once all the data has been obtained and emailed to the attacker the victim is redirected to a blank contract hosted on the Oak Ridge National Laboratory. This is likely a tactic to meet the victims expectations of accessing an important document and to mask the fact that they have indeed been phished. It also improves the success and longevity of the phishing campaign in the hope that it will remain active longer and avoid it being reported.
Other Interesting Findings
Alongside the source code for the site in question a number of other archives were present on the site which showed the campaign in various states of completeness. From this we are able to extract more email addresses related to the attackers, again using a mix of Yandex and Gmail accounts.
p****@yandex.com
p*****442@gmail.com
p*****11@yandex.com
A text file was also found in the archive which had links to another known phishing domain (yadu.pl), likely used as reference when building this site. It also contained a link to a Microsoft support page explaining how to password protect Word documents. This could indicate the attackers may be looking at using office macros hidden in password protected documents for a future campaign in an effort to bypass traditional security tools. These kinds of attack would be detected by the Senseon platform’s ability to detect suspicious processes. For example, if Word were to launch process such as powershell or cmd this would be detected as highly unusual by the Senseon endpoint agent. If this process then made network connections to unusual or known malicious hosts the network appliance and Investigator Bots would detect this and with the data from all three components a highly scoring case would be created.
Conclusion
Whilst this campaign was clearly targeted and likely took significant time to create it is clear the attackers cut corners leading to some fairly basic mistakes in the final product such as missing assets. Missing assets however were not the biggest downfall of this campaign. It was clear that significant time had been put into trying to stop anti-phishing tools detecting the site, but within a few hours of this campaign going live both Google and Mozillia, two of the world's most popular browsers, flagged it as malicious and warned anyone accessing the site that it was likely going to try and steal their data. From the source code it appears that these attackers are of eastern European origin however due to the mistakes and poor attention to detail it is unlikely that this is a nation state sponsored attack.
Whilst phishing attacks are incredibly common and somewhat basic in their approach they are still a tried and tested method of attack that deliver results. Unfortunately it is human error that allow these attacks to be successful and even with rigorous training of staff, a large number of phishing email links are clicked and credentials spirited away that can later be sold or used to access victims devices or sensitive data.
Most traditional security tools would not be able to identify an attack like this and indeed in this instance the attack was not picked up by the customers other security tools. Senseon observes behaviours and activity across the entire digital estate and automatically pieces together relevant information to build up an accurate picture of the threat - in the same way that a human analyst would.
In this Case the network data would be monitored to see if this or other devices were attempting to connect to the malicious external domain, and the Investigator Bots would gather external intelligence about the domain, looking at factors such as how recently it was purchased and other indicators indicative of malintent. The Endpoint agent would also be able to detect whether a payload was delivered by the attackers or executed by the victim. All of these separate Observations are automatically generated and presented in a single Case.
This automation of the human analyst’s role is applied at a speed and scale that far outpaces traditional tools and manual investigation by analysts. Further emulating how an analyst thinks and acts, Senseon’s AI Triangulation, at the heart of the platform, is able to reason in order to deny or confirm the hypothesis that a suspected behaviour is indeed malicious before alerting the security team.
About the author
Aamir Mir, Cyber Security Analyst, Senseon
Before joining Senseon, Aamir helped develop the Galileo satellite network for the European Space Agency. His passion for cyber security began during highschool and he went on to win the UK Cyber Security Challenge. Now at Senseon, Aamir is taking his passion in cyber security to the next level, including helping Senseon’s technology automate the process of investigation by emulating how an analyst thinks and acts.