Archives for 2020

In July 2020 7 Elements discovered a vulnerability in Rackspace that exposed all its global hosted email customers to the potential malicious use of their email domain by unauthorised actors. Malicious actors had the ability to leverage multiple accounts and pass security checks designed to detect spoofed emails. This was utilised in the wild to conduct targeted phishing attacks.

7 Elements has called this the “SMTP Multipass” attack.

The vulnerability was the result of how the SMTP servers for Rackspace (emailsrvr.com) authorised users. When this vulnerability is placed within the context of Rackspace’s guidance on customers specifically authorising these SMTP servers to send email on their behalf via DNS entries (denoting the use of SPF records), it can be used to form a viable attack vector.

This allows an attacker, authenticated under one customer account to send emails as another customer. Those emails would be received by the recipient, pass email security checks and be identified as a legitimate sender. Given this, malicious actors could use this to masquerade as a chosen target domain, potentially causing reputational damage.

The vulnerability was discovered by the 7 Elements team through our incident response service back in July 2020. 7 Elements engaged with Rackspace, through our responsible disclosure process, at the start of August 2020.

The Incident

Whilst supporting a client’s internal investigation into a targeted email compromise incident, our team and the client’s technical team worked together to assess inbound emails. This collaborative approach identified that the malicious actor(s) involved with the business email attack was sending emails using Rackspace customer domains. However, it was noted that when doing so the actor(s) authenticated with a user account under a different domain, successfully spoofing Rackspace hosted email customers, passing SPF controls.

By using this approach, the malicious actor was able to bypass the clients email filters and was free to choose from a large pool of suitable domains that make use of Rackspace’s hosted email offering.

This prompted further investigation by the 7 Elements team, which ultimately identified that any customer of the hosted email service was vulnerable to this issue. This was especially the case if their SPF records were set to pass emails from emailsrvr.com (as recommended by Rackspace). Based upon conversations with Rackspace, our understanding is that all customers of the hosted email service were vulnerable. Clients included US federal agencies, UK local government, military, politicians, financial organisations and high-profile individuals.

Force Multiplier

In this instance, two individual issues combine to have a greater impact. The first is the vulnerability within the Rackspace hosted email service that allows an authenticated user of the platform to send emails as any domain (including those that also use the service). The second is in how DNS entries configured by legitimate customers of Rackspace specifically authorised the affected Rackspace SMTP servers (emailsrvr.com) for the purpose of sending emails on behalf of that domain. So, any email coming from that IP on behalf of that domain is de facto authorised. The following image shows such an email:

In the Wild

As stated earlier, we are already aware of this vulnerability being utilised in the wild. With our internal POC scripts, it was a trivial exercise to identify vulnerable domains and then using a single account, authenticate to the SMTP server and send emails from those other domains. From an investigation point of view, as the email will appear to be legitimated (passing SPF security checks), the email headers would need to be interrogated for specific traits as outlined below:

Date: Thu, 24 Sep 2020 14:02:18 +0000
To: 7 Elements <contact-us@7elements.co.uk>
From: Finance <finance@**redacted**.com>
Reply-To: Finance <finance@**redacted**.com>
Subject: SMTP Multipass

X-Mailer: PHPMailer 6.1.7 (https://github.com/PHPMailer/PHPMailer)
Received-SPF: Pass (protection.outlook.com: domain of **redacted**.com designates
146.20.161.126 as permitted sender) receiver=protection.outlook.com;
client-ip=146.20.161.126; helo=smtp126.iad3b.emailsrvr.com;
X-Auth-ID: john@7ei.cc
Authentication-Results: spf=pass (sender IP is 146.20.161.126)
smtp.mailfrom=**redacted**.com; 7elements.co.uk; dkim=none (message not signed)
header.d=none;7elements.co.uk; dmarc=pass action=none
header.from=**redacted**.com;compauth=pass reason=100
Received: from smtp126.iad3b.emailsrvr.com (146.20.161.126) by
HE1EUR02FT008.mail.protection.outlook.com (10.152.10.77) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.3412.21 via Frontend Transport; Thu, 24 Sep 2020 14:02:20 +0000

Example email header with highlighted fields of interest.

Please note, the sample headers above are from one of our test emails against a live domain (hence the redacted content). The key header fields of interest are highlighted to show the email ‘from’ and ‘to’ as well as various checks being passed. 

Specifically, to identify this exploit we are looking for an X-Auth-ID value that does not match the ‘From’ address (usually at the domain level). In addition, the sending server “emailsrvr.com” indicates Rackspace being the sender. The malicious actors we have found to be using this in the real world also made use of PHPmailer to send the email, although this would not be required to exploit the vulnerability.

For our test, we used a trial account (7ei.cc) within Rackspace to send an email as another domain that had the relevant SPF records. A malicious actor could have done the same or as with the real-life cases we have investigated use compromised accounts.

Summary

As you can see, the main impact of this vulnerability would be with a malicious actor being able to send emails as any domain using the Rackspace hosted email solution, and one we have already seen in use by malicious actors with a focus on business email compromise attacks.

By sending email as another domain, the malicious actor can leverage the trust of that brand to coerce clicking on a link for a phishing style attack or potentially using the domain to send content that could result in reputational damage or even financial fraud though malicious invoicing-based attacks.

Disclosure Timeline

• 20th July 2020 – Client receives phishing email using this technique to achieve business email compromise (with intent to conduct financial fraud).
• ~30th July 2020 – 7 Elements provides assistance to client’s internal team and to collaboratively identify this technique and are able to reproduce it.
• 7th August 2020 – After finishing up our incident response effort we confirmed with the client that they would like us to report the issue to Rackspace. This contact is made to security@rackspace.com.
• 7th August 2020 to 25th August 2020 –  Communication with Rackspace around verifying the issue, the timeline for fixing the issue and ethical considerations of disclosure. Rackspace confirms that internally they are already aware of the exposure. Agreement to follow standard 90-day responsible disclosure window after a commitment by Rackspace to work toward fixing the issue.
• 15th September 2020 – Rackspace provide 7 Elements with an update to advise that another party has also discovered the exploit and notified them.
• 3rd November 2020 – Rackspace provide 7 Elements with an update to advise that customer-specific communications went out on the 29th October to advise of the issue, with a fix planned to start on the 5th November 2020.
• 5th November 2020 – Agreed disclosure date.

Image credit: Waverley Jane Media

A recent client incident response engagement relating to a ransomware attack has led us here at 7 Elements to explore trends in attack vectors and malware strains.

As part of the response, we took a deep dive into the Emotet and TrickBot malware strains used to support a Ryuk ransomware attack.  This included identification of the initial attack vectors used to compromise the environment. How the malicious actors gained a foothold, the methods used to leverage this initial access to maintain command and control over the asset and use this to map the internal network. Resulting in lateral movement, exfiltrate data for nefarious purposes, and finally encryption of data for extortion.

This blog post takes a high level look at what we found.

History First

The Ryuk ransomware family was first identified in September 2018, being traced to the WIZARD SPIDER criminal organisation. Their operations have focused primarily on cybercrime. The Ryuk strain of ransomware has been used to predominantly target large enterprise environments as reported by CrowdStrike, with the objective of forcing the organisations who are affected to pay a significant ransom to regain access to their encrypted resources and assets.

This type of attack vector is often referred to as ‘Big Game Hunting’. It relies on large-scale enterprise compromise to increase the necessity of an organisation needing to regain control of their environment by paying the ransom demanded, as local recovery would not be possible (due to removal of restoring from backup). The Ryuk ransomware strain bears a resemblance to previously identified malware, such as the BitPaymer ransomware.

Under the Hood

This particular ransomware attack has a number of moving parts, designed to perform tasks including but not limited to encryption and deletion of sensitive, valuable data as well as deletion of backups. Privilege escalation to a high privileged account such as a Domain Admin account and network mapping leading to lateral movement to navigate through the environment and further propagate the malware to affect as much of the environment as possible. This typically increases the likelihood of a successful attack resulting in the ransom demands being met.

The organised crime gang uses both TrickBot and the Emotet trojans in tandem with the Ryuk malware to accomplish this aim.

TrickBot and Emotet are employed by the malicious actor to leverage initial access into full compromise of one host. Research by the Malwarebytes lab team identified that this is often accomplished via performing a phishing attack against users within the organisation. The phishing email is likely to contain a malicious script, or document containing a macro that when executed, triggers a PowerShell command to download the Emotet trojan from an attacker controlled remote host onto the victim host.

Once Emotet is downloaded and installed on the vulnerable host, it uses its built-in download functionality to retrieve and execute the TrickBot trojan payload(s) on the host.

TrickBot contains a number of modules that are designed to perform malicious activities on infected hosts. Malware analysis has previously revealed that this included malicious .dlls that contain code designed to perform system and network enumeration, retrieve sensitive information and code used to propagate the malware and attack other systems.

From our recent investigation we identified a number of malicious files, including:

• systeminfo64
• networkDll64
• psfin64
• injectDll644
• pwgrab64
• wormDll64
• shareDll64

The systeminfo64 and networkDll64 files contain malicious code with the objective of extracting information from the systems registry hive, performing WMI queries and producing network/domain topology. This information is submitted back to the attacker via the use of a Command and Control (C2) server allowing them to identify useful targets and produce an accurate map of the infrastructure and active directory implementation.

The psfin64, injectDll644 and pwgrab64 malicious DLL files are used to attempt to identify locations that may store sensitive data such as user credentials or financial resources. They then attempt to extract that sensitive information or compromise those resources. Attack vectors included extraction of user credentials or tokens from system memory, or the compromise of network connected credit card payment machines and other devices used for financial transactions.

The wormDll64, shareDll64 and other related .dll files contain malicious code which is employed to assist in the process of lateral movement through the environment, as well as establishing methods of persistence for the attackers to access the environment at a later time. The process begins by using SMB and LDAP querying to identify access to other hosts and enumerate information from those hosts, such as domain enrolment. In some instances, it also attempts to exploit known vulnerabilities in the SMB implementation, most commonly the ETERNALBLUE vulnerability to achieve unauthorised access to other hosts. It then attempts to verify remote access via the Remote Desktop Protocol (RDP) or other means such as third-party tools.

Attack Flow

One of the most common attack patterns, as observed by CrowdStrike,  and in keeping with what we found during our incident response, appeared to be a multi-stage process, leading to a compromise of the wider environment. This starts the TrickBot trojan executing an obfuscated PowerShell script that establishes a connection to a remote server hosted by the attackers. A reverse shell would then be downloaded to the victim host and executed, connecting back to an attacker-controlled host. The TrickBot trojan then looks to perform a number of actions on the victim host(s). First, it runs some PowerShell anti-logging scripts to mask its activity, followed by disabling any anti-virus software in operation on the host, before performing system and network wide reconnaissance using built-in windows functionality as well as a number of the modules mentioned previously. TrickBot attempts to identify user accounts with higher privileges that may be stored in memory and extract their credentials, with the aim being to achieve enterprise or domain admin access. It will also look to harvest any useful sensitive information, such as financial data or a user’s web browser password vault contents.

Using any credentials identified, including those belonging to the initial exploited user, lateral movement is attempted to identify accessible users and repeat the process. One of the TrickBot modules attempts to create service user accounts on any host it is able to get a foothold, before downloading and installing a C2 server as a service. Lateral movement through the network to access new hosts will continue, attempting to access critical resources such as domain controllers.

Coup de Grâce

Once the initial compromise is successful, the attacker will then upload the Ryuk malware via a Remote Desktop Protocol (RDP) connection and execute it to infect the system. This will begin the process of encrypting files whilst also creating a ransom note in every folder where it has encrypted those files.

The PSEXEC utility is then used to propagate the Ryuk binary and execute it on each host that has been compromised. Ensuring that the malware performs the file encryption and deletion process on the hosts. Upon completion of the activity, scripts are executed to terminate processes or services used as part of the attack, and remove any and all data backups identified, before finally removing the Ryuk binary from each host.

However, this final tidy up is not always noted, in our latest incident, multiple copies of the Ryuk binary were left on affected hosts. We also identified the use of scheduled tasks to coordinate timed delivery of the ransomeware payload.

Magic (otherwise known as Crypto)

The actual file encryption, as reviewed by Checkpoint, was determined to use a combination of symmetric and asymmetric encryption using encryption keys unique to the victim to encode and lock the files. Specifically using RSA-2048/RSA-4096 and AES-256 keys and keypairs. The first keypair is the global keypair held by the attackers, the private key of this pair is kept separate from the victim throughout infection. The second key pair is the victim specific keypair. This is embedded within the Ryuk malware binary and is unique to each victim organisation. This is used to perform the initial encryption of the files on the victim hosts as well as any network shares the victim may have access to.

As a result, only the appropriate private key for that organisation will allow for data to be decrypted. The private key used is pre-encrypted using the global keypair, which would mean that the only way to retrieve the unique private key used to encrypt the files is to decrypt it using the private key from the global keypair. All of this is encrypted using the AES-256 keys that have been generated specific to the victim using the Win32API ‘CryptGenKey’ and ‘CryptExportKey’ functions. This allows the malicious actor to obfuscate the process further and prevent analysis and attempts to combat the malware.

Recent threat intelligence disclosed by security firm Emsisoft, noted that the Ryuk Ransomware has recently been modified. It appears that the newer version no longer encrypts files larger than 54.4 megabytes. This appears to be with the intention of speeding up the encryption process. Instead, these files are only partially encrypted, which will likely make decryption and retrieval of the data impossible.

Ryuk in Practice

During our recent client engagement, we examined the initial breach that led to a significant compromise of the client’s internal network, as well as the actions undertaken after the initial compromise. This included the actions taken against any hosts, services or users that may have been compromised, as well as any data exfiltration activities undertaken.

While it is common to prioritise an emphasis on loss of resources caused by a ransomware attack, the broader understanding of the full attack process end-to-end often gets overlooked during the incident response activity. This Is typically due to the IT and business teams focusing on the immediate issue of loss of data or resources. Unfortunately, this can often lead to the cause of the initial attack or post breach attack vectors persisting. Which in the worst case could expose the organisation to repeat attack.

Side-note – Data Exfiltration
Serious consideration of possible GDPR reporting requirements should be given. To enable a full appreciation of this, the organisation should look to identify evidence of data exfiltration and where possible assessment of that data to understand if any data falls within the need to report to external agencies such as the ICO.

Our CEO, Dave Stubley providing Information Security Media Group (ISMG) with insight on ransomware tactics.

Even without a blatant threat to expose or sell data, we are seeing other ransomware families exfiltrate ‘useful’ data and in some cases, using the data obtained to deliver targeted phishing against supply chain partners.

Initial Foothold
Taking a broader look at the incident at hand, we determined that the organisation was compromised by the malicious actors sending a large number of emails. Those emails had malicious word documents attached, containing macros designed to download the Emotet malware (using PowerShell).

The Emotet malware then downloaded, installed and executed a number of TrickBot malware executables designed to identify and extract sensitive data, enumerate the wider network and active directory instance. This included querying for information relating to hosts, services and user accounts.

User credentials stored in system memory and session cookies stored within the user’s browser were also extracted, and all information was transmitted to an external server via a Command and Control service.

While the antivirus solution employed by the client, as well as other systems designed to mitigate attacks led to a loss of data that would have been useful to the investigation,  7 Elements were able to prove that client data was exfiltrated, with the intention of recycling this information to target related third parties in similar attacks. However, of interest, only information stored within the initial compromised host was exfiltrated. 

Lateral Movement
The attackers used the credentials harvested to pivot further through the network using RDP. 

End Game
Once the malicious actors had completed their compromise of the estate and exfiltrated data of interest, they then uploaded and ran the ransomware binary to begin encrypting data and deleting copies and backups to prevent or limit data restoration activities. 

Conclusion

While the ransomware proved to be at the core of the attack, we placed a significant emphasis on trying to identify how the environment was initially compromised, and then how the malware was propagated throughout the environment. Looking to answer questions such as:

Did they attackers leave any further backdoors into the environment?

Did they steal any sensitive information relating to the organisation, or third parties such as clients or customers?

This is critical in ensuring that any weaknesses exploited as part of the attack can be identified and resolved, and more importantly to reduce the odds of a successful follow-up attack, or exposure to GDPR related sanctions.

One area that we can all agree, would be in the need for verbose incident response and disaster recovery plans. While it is still possible to respond without such plans in place, the potential consequences of a breach are reduced and restoration of the environment can be as efficient and comprehensive as possible, if plans exist. While this may increase the cost of security within the organisation, it will be greatly appreciated if and when a breach should occur.

The business landscape has undergone a sudden, drastic shift to remote access, in order to cope with the current social isolation requirements. Commensurately, the usage of video conferencing applications has skyrocketed. Perhaps the video conference tool that has most benefited from this change in business model is Zoom. The company has seen a huge boost in popularity, with reports of up to a 535% increase in traffic[1].

Wide adoption can help reduce the burden of continued operations challenges faced by a company, and a simple, reliable and flexible platform is an IT teams dream. In spite of this, a number of security concerns persist within the Zoom platform, which should be taken into account when looking to implement within an organisation’s operations.

Challenges in vulnerability remediations

The core security concerns raised around the Zoom platform to date, related to the ability to perform video-chat hijacking, insufficient end-to-end encryption, and a number of recently discovered vulnerabilities within the client installed on a user’s device. One issue previously identified within the software, related to privilege escalation on Mac OSX device, which may be leveraged to achieve malicious code execution, or in the case of a malicious actor, be used as an entry point into an organisation’s wider infrastructure. Another concern related to sensitive information disclosure that may be allow an attacker to manipulate a user into leaking their user credentials inadvertently[2].

Ever Evolving Threats

While these issues had been previously identified and were obviously a concern for people using the platform, with such a significant increase in user base, this has led to security researchers and malicious actor seeking to identify attack vectors within the software to target users. This has resulted in three Zero-Day vulnerabilities in the software being identified and publicised during the first 3 days of April 2020. The first two vulnerabilities[3] may allow an attacker to inject malicious code within a Zoom installer to achieve privilege escalation. This may be used in tandem with other attack vectors such as a phishing attack to target individuals or organisations.

Another vulnerability identified may allow a malicious actor to perform a malicious code injection attack that would give the attacker equivalent access rights to that of the Zoom application, meaning they would be able to intercept and spy on users via the microphone and web cam used as part of the chat.

The final issue, which was raised publicly on April 3rd 2020[4], related to the use of inadequate data encryption, which appeared to be an in-house implementation. It is highly recommended to avoid ‘rolling your own’ cryptography implementation and to use established and comprehensively reviewed methods that are widely available. The encryption implementation Zoom use was determined to contain flaws which in some instances may allow encrypted data that has been intercepted to be decrypted.

Slow start, but a rapid response

While Zoom have acknowledged the presence of these issues and have announced publicly that they are in the process of resolving them, concerns persist about the nature of their ongoing security activities and processes. Security researchers have been critical previously of the response times between disclosure of bugs and remediation by the company. On March 30th 2020, New York’s attorney General, Letitia James, contacted the company requesting an outline of the security measures that Zoom are undertaking to resolve these issues, as well as safeguard the platform, particularly due to the swell in its user base[5]. Zoom published an open letter on their public blog detailing the steps they have taken already, as well as steps they will be taking over the next 90 days to improve the security posture of the platform as a whole.[6]

The steps highlighted will include a freeze on new features to allocate developers to resolving open security issues and platform hardening. They intend to engage with third parties such as security architects and penetration testing firms to perform audits and security assessments on the platform, enhancing their existing bug bounty platform and employing methods of transparency with users to allow them to understand what is done with their data, and whom it may be shared with. They have also released security fixes for Mac OSX and Microsoft Windows clients to remediate a number of the vulnerabilities publicised.

In reality, while the flaws raised publicly so far are concerning, they should be considered in context. Many of them require at least a low privileged user account on local devices, which may significantly reduce the likelihood of a successful device compromise, unless another attack is successful to gain that initial access. In the matter of the encryption implementation, the significant resources required for a successful attack to be performed make it a fairly low risk attack vector, and the majority of users would be unlikely to be legitimate targets.

Conclusion

As with any adoption of new conferencing technology during this period of change, organisations should ask themselves if they are comfortable with what is being discussed over the conferencing platform and what adverse impact could intentional or unintentional disclosure of that content cause the business.

Further consideration should be given to any risks that the installation of software could bring to the integrity of end point devices. While Zoom are now clearly in the headlights, and will undoubtably take additional steps to assure organisations that they can deliver, so the increased attention is likely to result in further security concerns being identified.

Matthew Linney (Senior Consultant)

References:

[1] https://www.theguardian.com/technology/2020/apr/02/zoom-technology-security-coronavirus-video-conferencing

[2] https://blog.rapid7.com/2020/04/02/dispelling-zoom-bugbears-what-you-need-to-know-about-the-latest-zoom-vulnerabilities/

[3] https://objective-see.com/blog/blog_0x56.html

[4] https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-quick-look-at-the-confidentiality-of-zoom-meetings/

[5] https://www.digitaltrends.com/news/new-york-attorney-general-is-latest-to-question-zooms-privacy/

[6] https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-users/