The array of phishing vectors used by attackers is constantly expanding. On a daily basis we observe numerous different phishing themes such as voicemails, fake invoices and documents requiring signing. Recently, we have seen more topical themes such as US elections, COVID-19 and Brexit.
One staple in the phishing arsenal is the use of fake Microsoft login pages that are often outdated, have faulty “forgot password” links and are hosted on obviously unrelated domains. On occasions we have seen these phishing sites misconfigured and publicly exposing all the credentials they are capturing. These are easier to catch but with not much more effort, an attacker can register convincing domains and use tools to proxy the requests to the legitimate Microsoft login pages making them almost indiscernible from the real thing.
In a recent red team exercise we decided to do exactly that in order to test employee awareness and gain access to corporate Office 365 accounts. To inspire a bit of urgency, the initial email’s premise was that someone was trying to reset the password on the target’s account and that they needed to login to stop a ‘temporary password’ being sent to the ‘alternative’ email address.
Ok, the above email looks pretty convincing. The only sign of its illegitimacy being the domain of the sender address not actually belonging to Microsoft and the fact it went ‘via amazonses.com’. Again, to the untrained eye, those details are not glaringly obvious. This domain was registered with Amazon AWS and the email was sent using the AWS SDK for Python (Boto) which makes scripting these phishing attacks easy.
For the actual phishing page, we used Modlishka which acts as a reverse proxy between the targeted user and the legitimate site making it a powerful weapon for phishing. It essentially presents the same page as the legitimate Microsoft login page but hosted on the attacker’s domain. All requests made to the attacker’s domain are then forwarded on to the domain being proxied (login.microsoftonline.com) including the password and any 2 factor authentication (2FA) code in order to establish an authenticated session. An attacker can use this to capture the session cookies and gain access to the target’s account. This allows us to essentially bypass the 2FA protection!
The config for Modlishka is shown in the screenshot below. On setting up Modlishka, the only things needing to be changed are the ‘proxyDomain’ and certificate details. The certificates are necessary to avoid any warning being displayed to the victim about lack of encryption (HTTPS). Using Certbot and Let's Encrypt it is quick and easy to get HTTPS configured on the phishing landing page.
The ‘targetRules’ value may also need to be changed depending on the site you want to mimic. These target rules are used to replace string patterns in the code of the legitimate site. The configuration uses the format - base64(new):base64(old). These changes are necessary to bypass the Subresource Integrity checks present in the web page’s code.
Though the page served on the attacker’s domain is very similar to the legitimate domain it is not exactly the same as it includes references to the attacker’s domain rather than microsoftonline.com. This means that the loaded JavaScript resources are altered when compared to the scripts that the legitimate site would pull in. For this reason, when the integrity check compares the hash of the loaded resource to the expected SHA384 hash it fails, resulting in the login page not rendering correctly. Using rules such as those shown below (but base64 encoded in the config file) these integrity checks can be bypassed allowing the login page to be displayed properly.
t&&s.setAttribute("integdrity"" : t&&s.setAttribute("integrity"
What results is a very convincing phishing page.
Within minutes of sending out the phishing emails we could see that they were getting through mail filters, and being opened by users through the use of tracking URLs embedded in the body. The tracking URLs contained the base64 encoded target’s email address meaning we could see exactly who had opened the email.
Eventually, we got lucky. A few of the targeted employees entered not only their passwords but also the 2FA SMS codes resulting in the Modlishka server logging the requests with the valid session cookies. For Microsoft O365 logins, the session cookies of interest are the ESTSAUTH and ESTSAUTHPERSISTENT cookies. The latter being relevant if the user chooses to “Stay Signed In”. Hijacking the session using these cookies is as easy as pasting them into the browser. If you are using Chrome, you can right-click on the login.microsoftonline.com page, click Inspect, this brings up Developer Tools. Then in the ‘Application’ tab you can see the cookies set on the page. By adding the value of the captured cookie to either ESTSAUTH or ESTSAUTHPERSISTENT depending on whether the user chose to “Stay Signed In”, on refreshing the Microsoft login page you should find that it redirects to the email inbox and you are in an authenticated session.
The captured cookies not only gave us access to the user’s emails but an abundance of documents on the SharePoint site. This included documents detailing IT infrastructure, VPN configurations and cleartext passwords for various systems such as databases.
The victim’s desktop and a number of other folders were also synced to OneDrive. From one perspective this is a useful feature that backs up important work making it accessible from other devices. From an attacker’s perspective, we were able to leverage this in a number of ways.
Firstly, it meant that we could drop any file we wanted onto the victim’s machine. As explained in a previous blog article on Alternate Data Streams, because files downloaded using the OneDrive sync agent do not have a Zone.Identifier they will not be blocked by protections such as Windows SmartScreen. Combining that with the fact that OneDrive also reveals the documents that were most recently accessed, we identified a number of documents we could weaponise to get code execution on the machine.
We opted for the classic approach of using a masqueraded executable. The main benefit of this technique is its simplicity. We don’t have to worry about whether the target actually enables macros and accepts the Office security warnings. All it takes is a double-click. We noticed that the target user was frequently accessing a particular PowerPoint presentation and it was this document that we replaced with the masqueraded executable using the OneDrive web interface. The changes made online propagated to the victim machine’s local directory as it was synced. It was a matter of minutes until the target tried to open the masqueraded file and instead of opening the presentation she had unknowingly provided us with remote access to her machine.
The masqueraded executable was actually a custom Remote Access Trojan (RAT) developed by the ThreatSpike team. Consequently, it did not trigger any signature based detections from Windows Defender and remained active on the device for the entirety of the exercise.
The attack tool polls commands from a remote command and control (C2) server, executes them and sends the results back over a HTTP channel. The tool also has a number of different attack modules that can be triggered with specific opcodes. The modules we used in this red team exercise allowed us to establish persistence, steal the user’s web browser cookies and identify local privilege escalation vulnerabilities resulting from misconfigurations. Interestingly, the execution of these attack modules also went undetected by Windows Defender. I plan to provide a more in depth discussion of the implementation of the various attack modules in a subsequent blog article. For now, I will briefly discuss how particular modules were used to strengthen the foothold on the compromised machine.
Once we had obtained initial access to the victim’s machine, the next step was to establish persistence on the device. This means that in the event of a reboot or an attempted clean up by endpoint solutions or the company’s IT security team, the RAT would still execute and connect back to the C2 server. To achieve this, we copied the executable to multiple locations including the user’s “AppData” and “Saved Games” directories. We then hid the executables using attrib.exe and the command detailed below. This technique of evasion can be useful in hindering security investigations and an analyst may believe that the file has been cleaned up by antivirus if they do not realise it is in fact only hidden. This is often the case if the analyst attempts to identify the malicious file using File Explorer which by default does not show hidden files.
attrib +h +s +i "ImportantWork.ppt.exe”
We created scheduled tasks to run the executables daily. This meant that even if the machine rebooted, the scheduled task would ensure that the executables were eventually executed again providing persistent remote access to the machine. Relocating the dropped payload, hiding it and configuring the scheduled task was automated through an attack module making establishing persistence quick and efficient. The following command can be run manually to create scheduled tasks using schtasks.exe.
schtasks /create /sc DAILY /tn "taskname" /tr "c:\Path\to\my\payload.ppt.exe"
The next module that was executed performed the extraction and decryption of passwords and cookies stored in Chrome’s SQLite database. The decryption of the cookies is possible as the (AES) decryption key is encrypted with the DPAPI master key that is tied to the user. This means that any malware running in the context of the user has the ability to extract and decrypt the contents of Chrome’s SQLite database. This was a useful module in this particular scenario as it could be used to maintain persistent access to the corporate SharePoint as the user’s session cookies could be hijacked again when the previously captured cookie expired.
Our attack tool also allowed us to identify potential privilege escalation vulnerabilities. In particular, we noticed a scheduled task set up to run administrative tasks by the IT team. This task ran with SYSTEM level privileges and executed a PowerShell script. The vulnerability stemmed from the PowerShell scripts file permissions which allowed any authenticated user to modify it. This meant that we could change the contents of the script to run the RAT executable again so that we had remote command execution with SYSTEM level privilege.
Now coming back to leveraging our OneDrive access and the sync feature. Not only could we drop files onto the machine, but with the reverse shell over the HTTP channel, we could copy whole directories to locations that were synced with OneDrive and easily download them via OneDrive’s web interface. This provided a covert channel of egress with uploads to OneDrive going undetected and a better option than uploading documents straight to the C2 server. This allowed us to gain all sorts of useful information such as VPN configs and client certificates.
So from a simple phishing attack alone, we had gained a way to drop files onto a corporate machine, remotely execute code on that machine as SYSTEM and covertly exfiltrate data from the corporate device all within the space of about 5 minutes from the initial phishing email! Finally, we maintained access to the machine until the end of the exercise without the RAT being detected by the endpoint solution, Windows Defender. The chain of events and the associated Mitre ATT&CK IDs are summarised below.
This just shows how dangerous these phishing attacks can be especially when more and more companies are moving to operate almost exclusively in the cloud. While multi-factor authentication usually provides a good level of protection against the majority of phishing attacks, the use of tools like Modlishka manage to bypass 2FA. This highlights the importance of proper training for staff with regards to cyber security and phishing in particular. While the attack surface of your external perimeter may be tiny, securely configured and meticulously kept up to date with the most recent software versions, human error will always impose a significant risk. For this reason, regular awareness courses and phishing simulations are invaluable. However, when it only takes one person to give up their credentials and allow an attacker to gain access to corporate resources, other protection is needed.
Security considerations should be taken when managing resources in SharePoint. In particular, this exercise highlighted issues with non-IT users having access to various IT documentation. Groups should be used within SharePoint to lockdown file access and ensure that employees belonging to different departments can only access the files for which they are authorised.
Organisations should do their utmost to filter out these kinds of malicious emails using email gateway solutions. However, this is not always successful as we have demonstrated. The best form of protection may actually be having an efficient reporting system so that employees can report these phishing emails as soon as they are seen. The IT security team should have a process in place to quickly respond to these threats, blocking the sender address organisation wide and changing the password and deauthenticating all sessions for accounts that received the email.