Archives for 2020

SMTP Multipass

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 ( 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 (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 ( 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:

Screenshot showing a POC email sent as another domain

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 <>
From: Finance <finance@**redacted**.com>
Reply-To: Finance <finance@**redacted**.com>
Subject: SMTP Multipass

X-Mailer: PHPMailer 6.1.7 (
Received-SPF: Pass ( domain of **redacted**.com designates as permitted sender);
Authentication-Results: spf=pass (sender IP is
smtp.mailfrom=**redacted**.com;; dkim=none (message not signed)
header.d=none;; dmarc=pass action=none
header.from=**redacted**.com;compauth=pass reason=100
Received: from ( by ( 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 “” 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 ( 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.


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
  • 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


Enhancing Email Security 101


While imitation may be the sincerest form of flattery, email impersonation and spoofing has proven to be a serious risk to organisations and their staff.

An email sent from an attacker that is convincing enough to fool the recipient into believing it is legitimate can have major consequences to the security of organisation’s infrastructure, as well as the data they possess. All it can take is one email carrying a document containing malicious code for an attacker to gain a foothold into a network (see our blog on Ryuk Ransomware for more information). As a result, email security is paramount when designing robust security controls. This guidance document will take a high-level look at three core controls areas, Sender Policy Framework, DomainKeys Identified Mail and Domain-based Message Authentication, Reporting and Conformance. Links to Microsoft and Google configuration guidance is included at the end of this document. 

Email 101

Email works in a way akin to traditional physical mail. the email server sends a message to the recipient address containing an array of data, most notably the sender user and domain, recipient and the message body. One significant flaw within the email process is due to the server or client receiving the email typically trusting the validity and authenticity of both the sender and the information received without question and handling it accordingly. No matter the sending mail server, all mail servers are treated equally. In reality, it can be a fairly trivial process for an attacker to host their own malicious mail server designed to spoof email content and sender details. To address this risk, there are a number of additional controls that can be utilised to enhance email security. 

Sender Policy Framework (SPF)

Sender Policy Framework is a method used to verify that an email is coming from a server authorised to send mail on behalf of the domain. This is achieved through use of DNS records which are publicly accessible tables regarding a domain which link domains and IP addresses for routing. SPF can be added to the DNS records of a domain which then provides a publicly accessible list of the authorised places where email can come from. This list is then checked once the recipient email server receives a message. The receiving mail server cross references the DNS records from ‘’ and the sending IP address that the email originated from in order to determine if the IP is on the list of authorised senders. If yes, then the email proceeds to the regular inbox. If the sending IP is not listed on the SPF DNS records, then it is used as a spam indicator.

While SPF is not a bulletproof solution as it only verifies servers used to send emails not user accounts it does typically enhance mail security and is one of the easier headers to implement properly.

DomainKeys Identified Mail (DKIM)

One area that SPF is not intended to provide assurance of is the integrity and authenticity of the contents of the email’s sender and message. This is of particular concern in the event that the message can be intercepted and modified in transit between the sender and recipient. To guard against this, a standard was developed known as DomainKeys Identified Mail (DKIM) it employs public-key cryptography to generate a hash value which is then signed using a private key, this is then appended as a header value to the email together with a number of other values needed for DKIM (such as information needed to retrieve a public key from DNS).

Upon receipt of the email, the recipient can use the corresponding public key (obtained from the sending domains DNS) to validate the hash value received. The recipient server will then it will generate its own hash value to compare against the received hash value to validate the email.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Domain-based Message Authentication, Reporting and Conformance (DMARC) is a method used to inform mail recipient servers of what should happen to an email if SPF and/or DKIM fail to validate. This removes the need for the recipient to make a judgement call (i.e Gmail will not mark an email as SPAM just because it fails SPF, without DMARC telling them to), providing further protection against phishing and other business email compromise attacks.

A DNS record entry is published by the sender containing instructions that typically include if SPF/DKIM should be validated and if so to what level. It will also tell the recipient what to do if either fail validation. Typically this may lead to emails that failed authentication being quarantined automatically or deleted but it’s possible to also request that failures are reported back to a business making it possible to evaluate if a failure is down to a technical problem or someone trying to spoof emails from the domain. 

A Layered Approach

While any of these measures can be used in isolation or combination, using all three measures provides a defence in depth approach to email security that can assist with protecting against many common attack vectors. Most enterprise email service providers offer their ow client or resource to implement and configure email security records and DMARC rulesets. Their tools will typically allow you to generate a domain key, associate the public key with the mail server’s DNS record and apply the relevant ruleset to the record for all outbound messages.


Out of the box, email and especially cloud based email services require additional hardening to protect against common attacks (such as spoofing). This guidance document has introduced at a high-level three core control areas that as individual components, combined or all together can provide a more robust email security posture. However, they are by no means a guarantee that future security vulnerabilities wont find away to work around those controls and result in trivial email spoofing. As such, a more in-depth approach to email security is required, and one that takes into account both technical controls such as those discussed, along with multi-factor authentication, and combine with more human elements such as phishing awareness training.

Platform Specific Links

Microsoft O365:






Phish and Clicks

7 Elements have been assisting businesses in investigating cybersecurity incidents for over 10 years. We’ve seen a significant increase in phishing incidentsover the last 6 months, mostly as a direct result of the increased use of remote services such as Zoom and Microsoft Teams. 

The increased use of these services results in the perfect environment for phishing, since their legitimate emails often include links requesting users to log in or even to install applications. Attackers have been exploiting this trained behaviour by sending phishing emails that closely match these legitimate emails, requesting passwords or instructing victims to install malware.  

This blog uses an example phishing email, claiming to contain a link to Zoom meetingto demonstrate how to spot a fraudulent email. We’ll also take a closer look at what exactly happens when a user clicks on the link inside it. 

screenshot of a recent phishing email
Screenshot of a recent phishing email

Tell-Tale Signs: How to Catch a Phish 

So, how can we tell that the email in question is fraudulent? To begin with, there are a couple of things that simply don’t look quite right. 

For starters, regular Zoom users may know that Zoom emails typically contain the meeting ID and details of who the meeting is from, whereas this email is much more generic. Or, we may notice that the blue “Zoom” text doesn’t match Zoom’s usual branding. Their real logo uses a different font and is all lower case: 

zoom brand
Zoom logo

Also, while the sender’s address does appear to contain the word “zoom”, the very last part (called the domain) is actually “”:

Image showing from address
Screenshot showing the sending email address

This is odd, since Zoom typically uses the domains and Of course, we may not always know where legitimate emails from a given company should come from. However, if the sender’s domain is different to what we would expect to type into a browser to visit their website, it’s worth being suspicious.

We do need to bear in mind that it’s often possible for attackers to “spoof” emails, meaning they can make them appear as though they actually did come from, or another legitimate address. Also, other attackers are better at copying the branding and email content of the real company. So, just because these things look good in an email, it doesn’t necessarily mean the email is legitimate. But if one or both of these things looks off, it’s a red flag.

So, how can we be sure? The crucial thing is the link which the email contains, since this is where the email is actually trying to get us to go. Rather than clicking on the link, we can hover over it with our mouse pointer to reveal where it goes:

screenshot showing the destination link
Screenshot showing the destination of the link

On mobile phones, this can usually be done by long pressing on the link until a pop-up appears.

In this case, we can see that the link begins with “”. While we may not recognise the address that’s used here, it doesn’t appear to be related to Zoom. We can confirm this by entering “” into a search engine – when we do, none of the results have anything to do with Zoom. If performing this check, be sure to visit the search engine’s website and enter the suspicious domain into their search bar. Don’t enter it directly into your browser’s address bar to perform the search. While the browser’s address bar can be used for typical searches, if a domain is entered you will actually be taken there – and in this case, there’s a good chance the webpage will be malicious.

Sometimes attackers may use an address here which does resemble the name of the company, similar to the “” which we saw earlier. But if the address in this link isn’t one which we know is legitimate, e.g. “”, we shouldn’t click on it.

If we’re concerned that something needs our attention, e.g. if the email claims that we’ve been locked out of our PayPal account or that we owe HMRC more money than usual, the best thing to do is to access the website or contact the organisation in question directly using a method which we trust. For the previous examples, that would mean visiting PayPal through a bookmark or trusted link, or phoning HMRC on the telephone number published on their official website. You can then find out from the website or member of staff whether the content of the suspicious email is legitimate.

A Closer Look

Let’s look more closely at the malicious link contained in the email, to see what happens when a victim clicks on it. This section is written from a more technical perspective.

The link is:,d7623c,1ac8b&

So, the email is pointing potential victims to a host on – a legitimate domain, belonging to the RAC breakdown cover and insurance company. The attacker appears to be taking advantage of the fact that a service hosted on an RAC subdomain contains an open redirect1. This is a type of web application vulnerability which allows attackers to direct victims to a malicious website via a link that begins with the address of a legitimate company. In this case, the address which the attacker is redirecting victims to is the section in red:,d7623c,1ac8b&

We can confirm this by replacing the red section with our own website’s address:,d7623c,1ac8b&

As expected, clicking this link takes us to the 7 Elements website. This is done by a simple HTTP 302 redirect from the RAC website.

Example of an Open Redirect

Let’s see what happens when we actually click the link in the attacker’s email. Our browser is redirected from to the address, and sends a request to that server. The server responds with an HTTP 404 page which contains a JavaScript redirect to the location in red:

HTTP/1.1 404 Not Found
<<HTTP headers removed>>
Link: <>; rel=""
<<HTTP headers removed>>
Content-Type: text/html; charset=UTF-8

<script type="text/javascript">window.location.href = ""</script>

Our browser is automatically redirected once again to this new link, which is hosted in Azure, and we’re presented with a fake Microsoft 365 login page asking the victim to “sign in to Zoom with your Microsoft 365 account”. The use of Azure in order to host this page on a “” URL gives the page some appearance of legitimacy:

Screenshot of a fake login page
Screenshot showing a fake login page

Zoom doesn’t actually appear to allow signing in with a Microsoft ID currently, but the creator of this phishing page seems to have opted to run the risk of arousing suspicions through this request in order to capture Microsoft passwords rather than Zoom passwords. This is presumably because a Microsoft ID will potentially grant the attacker access to the victim’s personal or business email account. Email accounts are more valuable to an attacker than Zoom credentials, since they typically contain greater amounts of sensitive information and can often be used to reset the victim’s password for other websites. In the case of a business account being compromised, information found in the victim’s emails and calendar can then be used for further attacks against the business.

The victim’s email address is pre-filled in the login form above. This is tied to the link in the attacker’s email – for each phishing email that the attacker sends, the recipient’s email address is embedded in that email’s link. This means each potential target receives a unique link, tied to their email address. This allows the attacker to see who has clicked on their link, and also helps to make the login page more convincing – when the victim sees a login form with their email address pre-filled, it seems as though it’s a website they’ve used before.

The email address is Base64 encoded before being embedded in the phishing link. In our example, the encoded email address is the section in red:,d7623c,1ac8b&

This string (“Ym9iQGJvYi5jb20=”) decodes to “”, the address which is also seen in the fake login page above. When we received this phishing email, the Base64-encoded section of the link contained the actual email address of the recipient – this has just been changed to “” as an example for this blog. Interestingly, when we attempt to use the link with the email address completely removed or with a Base64-encoded value of “”, the link redirects us to the legitimate Zoom website. This appears to be an attempt to hide the fact that the link is being used for phishing, and potentially also to stop the attacker from receiving submissions for known invalid email addresses.

When we submit a dummy password to the fake login page, we receive an error message telling us that we entered an incorrect password:

Response to incorrect password
Screenshot showing response to incorrect credentials

Behind the scenes, the user’s password is submitted to a PHP script hosted on each time the user attempts to log in:

POST /mp.php HTTP/1.1
<<HTTP headers removed>>!

The server at responds with the following:

HTTP/1.1 200 OK
<<HTTP headers removed>>

Or, when no password was entered, it responds with:

HTTP/1.1 200 OK
<<HTTP headers removed>>

This may be a clue as to the origin of the phishing attempt, or at least the author of the phishing kit being used – “kosong” means “empty” in Indonesian, while “gagal” means “failed”.

These responses tell our fake login page what message to display to the victim who has just entered their password. Let’s take a closer look at the login page:

Azure hosted phishing site
Screenshot showing an Azure hosted phishing site

The script has been obfuscated, but we can simply run it through an online JavaScript deobfuscator. When we do that, we can see the code which tells the login page present the “sign in failed” message when the server responds with GAGAL:

source code 1
Screenshot showing the clear text code

A similar if statement exists for the KOSONG (no password entered) response. Interestingly, we noticed that the page has also been coded to handle responses of “VALID”. As shown in the following screenshot, then this response is received the login page will redirect the user to the legitimate Zoom website. Before redirecting, the “Finish” class which is referenced will display the message “This video conferencing has been cancelled. You will be redirected to Zoom”.

source code 2
Screenshot showing further code

We created a new Microsoft ID and entered its credentials into the fake login page, to see whether the attacker’s script was attempting to use the credentials and would respond VALID if it was successful. The server responded with GAGAL as before. We then entered credentials for our Office365 honeypot. This time, the credentials were verified by the phishing server and we received the “cancellation” message followed by a redirect to

Cancellation Message
Screenshot showing the cancelled meeting message

We suspect the reason that only our Office 365 honeypot credentials were successful here was the fact that we have legacy authentication enabled on our honeypot. Legacy authentication doesn’t use MFA and is likely what the phishing script uses to verify the credentials that are submitted. It’s worth noting that legacy authentication can be used to bypass MFA in tenancies which support it, even if they also have modern authentication enabled ( – so disabling legacy authentication wherever possible is highly recommended.


Despite the initial email not being the most convincing, the fake login page which it linked to was much more sophisticated. The phishing chain makes use of an open redirect vulnerability within a legitimate service, leverages Microsoft’s own hosting and involves two compromised web sites. The Microsoft 365 branding was well imitated, and the attacker’s script even checks to see whether the credentials are valid. As well as helping the attacker to filter out submissions which they can’t use, this also makes the page appear more genuine to victims. Users who mistype their password the first time will be prompted to try again, before receiving a different message when they enter the correct password, just like the real thing.

It’s easy to see how a victim could give away their password without even noticing. Learning to spot the tell-tale signs is an important defence for users – and we can’t finish without a reminder to enable MFA and disable legacy authentication!


7 Elements worked with the RAC Group to ensure that the open redirect detailed in this report was resolved prior to publication.

Ryuk Ransomware

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. 


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.


7 Elements are now a CREST accredited company

7 Elements achieves CREST (The Council for Registered Ethical Security Testers) company accreditation in recognition of our professional penetration testing services.

CREST is an international not-for-profit accreditation and certification body that represents and supports the technical information security market. CREST provides internationally recognised accreditations for organisations and professional level certifications for individuals.

Company accreditation builds upon our long-term commitment to professional certifications for our testing team, many of whom hold either CREST Registered Tester (CRT) or CREST Certified Tester CCT) status.

More information on our penetration testing services can be found here.

Zooming in on security

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.


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)











Scottish Business Hub

The team here at 7 Elements are proud to be a supporter of the Scottish Business Hub.

The hub, created by ScotlandIS with support across industry, offers as many of Scotland’s digital technologies resources as possible to businesses either free of charge or at discounted rates. It provides Scottish businesses with essential digital tools to support rapid transformation at this challenging time.

As part of this we will provide free cyber incident triage calls for all SMEs within the Scottish business economy during #COVID-19. This could range from advice and guidance on how to deal with a ransomware attack or business email compromise, through to a hacked web site or computer virus.

Further information on our approach to cyber incidents can be found here:

If you have an ongoing cyber incident call our triage team on 0131 235 2901

Keeping the Show on the Road

With the onset of the current COVID-19 pandemic, causing huge operational shifts for organisations, their IT operations will have to adapt in kind. Not only will organisations need to maintain their current legacy operations, they may need to leverage new tools to enable remote working. As a result, tools such as VPNs to access internal resources, or new cloud environments may be deployed to allow for operations to continue. Malicious actors, such as those focused on ransomeware or business email compromise may take any opportunity presented to them to cause negative impact. Given this, it is paramount that organisations take the time to ensure that they continue to maintain good cyber security hygiene while managing the wider risks associated to both employees and the wider business by COVID-19.
The following guidance looks at a number of core cyber security controls that should be maintained to help organisations weather the current storm.

Vulnerability Management

The first of these priorities should be to ensure that organisations continue to download and install software security updates upon release. A comprehensive patching policy, that includes operating systems and third-party software must be a cornerstone of an organisations security policy. Ensuring that potentially exploitable vulnerabilities within software are minimised and resolved as soon as possible can significantly reduce one of the primary attack vectors malicious actors will seek to target.
On some occasions, security patches may introduce bugs into the operation of that software. As a result, it is recommended that where the business has capacity, it should install these patches in a test environment to verify the stability of the software once the patches are installed, before issuing to the wider estate.

Data Backup

Another priority should be ensuring that all sensitive and important business data is adequately backed up. A robust backup mechanism, that stores current data for a short-term in one location, before appending to a longer-term, more comprehensive back up solution would ensure that multiple disaster recovery scenarios are prepared for. Especially in terms of dealing with ransomware attacks.
In the event of sudden data loss, the short term backups can be rolled out, reducing the need for operational downtime. Equally, in the event of a breach, the data can be rolled back from the longer term solution to a time before the breach occurred, removing the potential for loss of data integrity and providing a measure of non-repudiation.
Consideration should be given to ensuring that any new technology deployed (such as cloud based solutions) to enable the organisation deal with changes to working patterns are included within their backup requirements. A key question to ask, would be “Do any changes we have implemented altered where our sensitive data is held?”

Changes to the network perimeter

Due to the current government advisory of social isolation, the number of remote workers within organisations has skyrocketed. This places higher burdens on the existing remote access solutions such as VPNs to access internal resources, or forces organisations to deploy new solutions to allow access remotely. This can pose a number of risks, such as exposing services to the internet that may not have been appropriately configured. Another issue may relate to the use of outdated software if this solution has been in place for some time. Any new or existing software should be deployed to adhere to recommended good practices, such as those provided by the National Cyber Security Centre (NCSC) as part of their End User Device Security guide.

Robust Password Policy

Another significant security control that must remain a focus is a robust password policy, with multi-factor authentication enforced where possible, especially where new services are being stood-up in short timescales. Modern password cracking ‘rigs’ designed to attempt to bruteforce password hashes, cloud computing resources that can be scaled up as needed to target user accounts in a number of ways or generic password guessing/brute-forcing attacks are all common attack vectors. Enforcing a strong password requirement, such as those laid out by NCSC ( or the National Institute of Standards and Technology (NIST).
An example of NCSC’s current advise on user password creation is to allow users to use three random words as a password. That should be easy for a user to remember, but difficult for an attacker to guess, while typically being of a sufficient length to make password cracking very difficult.

Enable MFA Everywhere

Multi-Factor Authentication (MFA) can further reduce the likelihood of a successful account compromise. Other solutions may be to use enterprise Single Sign-On (SSO) solutions that are designed to reduce the number of passwords a user must remember, while allowing for access to multiple applications and services. This can allow for a stronger password to be set without the confusion of multiple passwords to manage.

Phishing Awareness

With the increase in remote working, comes the decrease in the ability for the workforce to communicate face to face. As a result, the number of emails received is likely to increase. While email security is a fairly broad topic, with a number of security controls that can be implemented, it is often the human factor that leads to issues. Phishing attacks have become more and more sophisticated, with methods to evade technical controls constantly being discovered. As a result, training plans that aid all users with identification of potentially malicious emails, as well as the process to report them, is often a crucial piece of the puzzle. This training will need to be ongoing to ensure that emerging threats and trends are taught to staff to help them with this.


While organisational IT operations are forced to change and evolve due to the current challenges faced by society, the core security practices we have laid out should not be neglected and ignored. They are as crucial to an organisations ongoing security now as they were a year ago. Many organisations will already have these practices implemented, while a number will still need to adopt them. Whether just rolled out, or implemented and in use for several years, auditing and security testing is vital to verifying that the controls implemented do as intended, and identifying any gaps in the control.

David Stubley (CEO) and Matt Linney (Senior Security Consultant), 7 Elements

7 Elements expands with new office

2020 is already proving to be a good year for the team, as 7 Elements continues to grow with the addition of a new office in Leicester.

The technical team based out of the new office will be led by Senior Security Consultant, John Moss, who said, “We have a great technical team working from our new office, a number of which are graduates of the cyber security course here at DMU and I am really excited to continue to build local relationships.”

The team has already hit the ground running, with recent engagements ranging from penetration testing of a business with over 15,000 clients and 30 million users, as well as incident response capability as part of multi-million pound cyber breach.

“As we enter our 10th year, the company continues to grow in strength, with the addition of our managed vulnerability service Clarus – and now a permanent team in Leicester to manage the increased demand in England for our security testing and incident response services.” says CEO David Stubley.