Mitre ATT&CK Techniques and Unikernels

MITRE has a long list of attack techniques used to describe how hackers force their will on unsuspecting computers. We have gone through this list and described how some of these techniques are completely eliminated and others are scaled back when using unikernels.

It is important to note that unikernels do not completely stop every style of attack or technique but there are many techniques that are severely limited or outright removed all together.

It is also very important to note that NanoVMs has only enumerated these tactics and techniques against the Nanos unikernel. End users should be aware that many other projects that consider themselves unikernels not only don't have the same guarantees but some have very bad security properties. If you are using unikernels for security ensure you are using Nanos and not some knock-off.

MITRE breaks this long list up into tactics and techniques. Tactics are grouped into goals of an attacker whereas techniques show how the attacks actually occur.

We can further break up tactics and techniques into the enterprise category which contains Linux and the Cloud. We're going to focus in on the enterprise category but a lot of the same techniques apply to ICS as well. For the purposes of this article we're going to ignore that because of overlap. The cloud category also contains IaaS and Containers. The enterprise category has 14 tactics which is composed of 211 techniques - way more if you want to iterate sub-techniques.

Many of these techniques can be grouped in multiple categories. We've tried to limit describing them to one category for simplification purposes but do note that they could be in mulitple categories.

TA0001 Initial Access - The adversary is trying to get into your network.

Initial access is harder with a unikernel based infrastructure. Certain techniques such as T1190, Exploit Public-Facing Application can be harder to achieve. For instance unsafe deserialization can land webshells in certain environments but this might be much harder to do in a unikernel environment and even if it happens might be very limited on what can practically be done.

T1195 - Supply Chain Compromise is becoming a much bigger threat in the past so many years with attackers phishing for things like NPM accounts or snarfing tokens from github actions. While the initial collection of say a popular NPM account may not be stopped many payloads that are inserted into compromised npm dependencies involve executing other programs, be it a shell or a cryptominer or something like that. Most droppers are inherently built to land many varying types of payloads.

TA0002 Execution - The adversary is trying to run malicious code.

The execution tactic is one place where unikernels really shine. While an attacker might have access to running cloud administration commands, once inside a network, more than likely it will need to happen as part of the payload itself vs just by running via a shell. An attacker could skirt around this by spinning up a new linux instance in the same VPC.

T1059 - Command Scripting Interpreters are severely throttled in unikernel environments. First off unikernels can only run one application per vm so there is never a case where an application might be running node.js and then an attacker tries to run python or bash. What might happen here is that an attacker might be able to execute a RFI (remote file inclusion) written in the same language. For instance if they are able to upload a new .js file to a node.js unikernel and then call that. However it is important to keep in mind that that new file would never be able to spawn new processes or a new shell - whatever payload that would need to execute would have to be entirely in javascript.

T1609 - Container administration command obviously is not a technique that is applicable to unikernel environments. If one has the correct privileges one might be able to communicate to or issue new resources in a cloud but that is usually constrained quite a lot by cloud IAM policies which is almost never the case in a container based environment.

T1610 - Deploy Container - Similarly, is not something that is applicable in a unikernel based infrastructure.

T1559 - Inter-Process Communication is obviously not something that works in a unikernel environment with it's single process model. Unikernels are inherently designed to run one and only one process.

T1106 - Native API is severely hampered in a unikernel environment. While an attacker can obviously issue certain syscalls that might gain them more information about a particular system they will not be able to issue other types of calls such as using fork to create a new process.

T1053 - Scheduled Task/Job are inherently eliminated in unikernel infrastructure as there is no concept of a cronjob as it is impossible to run other programs in an unikernel based infrastructure. Many exploit payloads install illicit cronjobs for persistence purposes.

While unikernels can not eliminate T1648 Serverless Execution, if there are no IAM policies for it it is not a problem. If you have some serverless workloads and some unikernel workloads you eliminate this simply by converting the serverless workloads to unikernels.

T1129 - Shared Modules aren't necessarily eliminated by unikernels but they can by enabling Nanos unique exec protection feature which explicitly prevents new executables from being created or existing ones to be modified.

T1569 - System Services is eliminated by deploying with unikernels as there is no init system or systemd or the like. Again, unikernels being single process systems make this technique irrelevant.

TA0003 Persistence - The adversary is trying to maintain their foothold.

T1908 - Account Manipulation is a bit different with unikernels. While cloud based credentials such as IAM policies remain others such as ssh keys go away. Keep in mind there is no ssh or shell on unikernels and there aren't system level users either.

T1547 - Boot or Logon Autostart Execution - Unless an attacker is supplying a new shared library (which can be entirely disabled using Nanos' exec protection) this particular technique is entirely removed.

T1037 - Boot or Login Initialization Scripts - This is entirely removed by Nanos as you can not execute random initialization scripts in the Nanos environment.

T1554 - Compromise Host Software Binary - Technically an attacker can overwrite a binary on a unikernel system but if you enable Nanos exec protection that becomes not possible.

T1136 - Create Account - While an attacker may create new cloud based accounts they can not create accounts inside of a unikernel as the unikernel has no concept of a user at all.

T1543 - Create or Modify System Process - An attacker may not create a system process on a unikernel as there is no means to run other system processes other than the one that is running. This technique is eliminated on unikernels.

T1546 - Event Triggered Execution - This technique is rather encompassing on non-unikernel based systems but is completely obviated on unikernels.

T1668 - Exclusive Control - This is a very common technique that one will see, especially with cryptominers as one of the first things they will do is look for other cryptominers on the system and try to remove them. Again, this isn't really applicable to unikernels as you can't execute random programs and there are no user accounts so there isn't really something to shut the door on to begin with.

T1574 - Hijack Execution Flow - This can be a technique that is used on unikernels if for instance a shared library was uploaded and replaced on an affected system, however this can be disabled with Nanos' exec protection eliminating this threat.

T1525 - Implant Internal Image - In this sense there are no containers in a unikernel environment but the unikernels themselves are machine images. An attacker could implant a new AMI for instance on AWS assuming they have credentials/access to do so.

T1556 - Modify Authentication Process - At the system level this entire class of techniques is eliminated as there is no authentication for unikernels as there are no users.

T1112 - Modify Registry - There is no concept of a registry on unikernels. This is eliminated.

T1137 - Office Application Startup - This class of techniques is obviously not relevant to unikernels.

T1653 - Power Settings - This is not a technique that would be applicalbe in the cloud but if one were hosting unikernels on their own servers and the control plane (eg: hypervisor) was commandeered one could execute this technique.

T1542 - Pre-OS Boot - Again, this is more to do with onprem servers and the same thing applies.

T1053 - Schedule Task / Job - This technique mostly does not apply as there is no concept of cron jobs within a unikernel, however one can use certain services such as AWS Scheduler to implement the equivalent of cronjobs. If an attacker has gotten access here then it could be a problem.

T1505 - Server Software Component - This technique still exists in unikernels, however it's effects are greatly diminished. For instance with a web shell one could read or write files but one could not implement a reverse back shell or start running arbitrary commmands. Similarily, one might be able to execute SQL in a compromised host database but one could not spawn other programs from it.

T1205 - Traffic Signaling - This technique is not eliminated under unikernels but thing like port knocking typically are tied to activities such as opening a reverse shell which would be eliminated by running unikernels.

T1078 - Valid Accounts - Valid cloud accounts are still a target for attackers in unikernel based infrastructure but as there are no system level accounts there are no valid accounts to use at that level.

TA0004 Privilege Escalation - The adversary is trying to gain higher-level permissions.

Privilege escalation is a technique that unikernels thwart considerably as there are no system level users on unikernels.

T1548 - Abuse Elevation Control Mechanism - Abusing things like suid or sudo simply doesn't work here as there are no users to elevate privileges to/from.

T1098 - Account Manipulation - While cloud accounts are still affected here all system level accounts such as messing with around with ssh keys simply has no affect since there are no users on unikernels.

T1611 - Escape to Host - While vm escapes do happen from time to time they are exceedingly rare compared to container based escapes. Since the entire public cloud is built on virtualization this is typically corrected on the major providers before end-users are even aware of their existence.

T1068 - Exploitation for Privilege Escalation - Again this is largely irrelevant on unikernel based systems as there are no users to begin with.

T1055 - Process Injection - While process injection is not inherently defeated on unikernel basd systems it can become much harder. There typically is not much of a proc attack surface unlike Linux. Ptrace is non-existent and exec protection may be turned on to prevent any new executable code from being put onto the unikernel or modifying existing executable code.

TA0005 Defense Evasion - The adversary is trying to avoid being detected.

T1612 - Build Image on Host - This obviously isn't relevant to unikernels however it's best to look into your IAM policies to ensure that new unikernel images can't be built from existing instances by default. There might be cases where you explicitily want this, however for ci/cd systems.

T1610 - Deploy Container - This is much like T1612 in that your IAM policies might allow for the equivalent version of this for unikernels. However one big difference is that unikernels are deployed as vms whereas containers might run side by side next to each other on the same host with the same kernel. This makes the container version of this much more insecure.

T1222 - File and Directory Permissions Modification - This is a big difference with unikernel based systems as there are no users. This implies that there are no access rights with files. The difference is that since you can't run other programs, and there are no users, any file on the system is fair game. This is not necessarily true, however as you can mark certain volumes to be read-only, the kernel lives on a different, in-accesible partition, and Nanos has support for openbsd style unveil.

T1562 - Impair Defenses - This is a collection of techniques where some are irrelevant and others are relevant but defeated. For instance there is no command history on unikernels that you can wipe as there is no shell or method to run arbitrary commands on them. Similarily, you can't downgrade software as easily as you can in a corresponding linux system since there is no apt-get or rpm or wget and such.

T1070 - Indicator Removal - Like the previous technique certain sub-techniques here are obviated. You can't clear a history file but an attacker could clear a log file.

T1202 - Indirect Command Execution - You can't run arbitrary commands (eg: programs) on unikernel systems so this is entirely obviated.

T1036 - Masquerading - This collection of techniques includes a few that unikernels remove but leaves others as applicable. For instance you can't rename system utilities as there are none. You also can't break a process tree as the unikernel is a single process system.

T1556 - Modify Authentication Process - This category of techniques is not applicable to unikernels as there are no users and no authentication to be had on the unikernel so the authentication process doesn't even exist.

T1578 - Modify Cloud Compute Infrastructure - Most of these techniques are applicable under unikernels, however, are reliant on a few pre-existing conditions. First applicable IAM policies must exist to allow this to happen on a compromised system. Secondly, the process of modifying the compute will need to be put into code that the attacker controls - versus simply running some commands on a linux system the attacker would need to, for instance, upload a new script for a node.js interpreter to execute or modify a go binary with the cloud modification code.

T1601 - Modify System Image - Today there is no method to modify an existing kernel on a unikernel without a fresh deploy although other portions of the filesystem might be overwritten if compromised.

T1027 - Obfuscated Files or Information - At first glance many of these techniques seem applicable to unikernel instances however there are a few that are not. For instance, Compile After Delivery, is not an option as that would require the ability to run the compiler which wouldn't even be present but if it were unikernels can not run other programs on the same instance other than the one that is running. Also Command Obfuscation doesn't make sense here as there are no commands to begin with.

T1620 - Reflective Code Loading - While technically this remains a viable technique, unikernel exploit payload mitigation kicks in here as you won't simply be able to run another process or spawn a shell so whatever payload you want to run will need to run within the payload itself.

T1216 - System Script Proxy Execution - This is not relevant for unikernels as there is no system script runner.

T1550 - Use Alternate Authentication Material - Several of these techniques don't apply to unikernels as you can't pass the hash or pass the ticket on unikernels since there aren't users.

T1497 - Virtualization/Sandbox Evasion - Unikernels are explicitly designed to run as virtual machines so malware utilizing these techniques aren't relevant in unikernel environments.

TA0006 Credential Access - The adversary is trying to steal account names and passwords.

T1557 - Adversary in the Middle - Unikernels don't necessarily prevent this technique - they just make it harder. For instance if an attacker were able to have a dhcp server as an exploit payload that might still give more ammunition for spoofing later on.

T1110 - Brute Force - This is not applicable for unikernel environments for system users. If you have an application level user such as a database user/password this might be more applicable.

T1555 - Credentials from Password Stores - While an attacker can snarf passwords from a password store they could only be use for application level or cloud level access as unikernel instances themselves don't have users.

T1212 - Exploitation for Credential Access - This technique like others still remains viable in unikernels but becomes more difficult. For instance an attacker could replace javascript code on a server through a RFI that ships login username/passwords to an external url. The difference on a unikernel environment is that the attacker would need to have their code on the instance vs being on the instance themselves.

T1040 - Network Sniffing - This remains a viable technique on unikernel systems but is harder to do. On a comparable linux system an attacker might use something like tcpdump to look at plain text traffic or intercept tls traffic and decrypt it first, but to do this on a compromised unikernel instance one would need to provide all that code in their payload and it makes live introspection, which is quite common, hard to do.

T1003 - OS Credential Dumping - this is largely not applicable to unikernel environments as there are no os credentials to begin with. While there might be an etc/passwd to allow certain glibc calls to work it is merely used as a stub and does not offer any sort of access. Similiarly there is no proc support to look at memory and one can not spawn a new process to force proc to populate.

T1558 - Steal or Forge Kerberos Tickets - Again this is largely irrelevant on unikernel systems. This technique remains viable if the purpose is to attack other non-unikernel based systems.

T1552 - Unsecured Credentials - Some of these techniques are still applicable in unikernel environments as it is still quite common to see plain text passwords put into env vars, files on the filesystem and other places.

TA0007 Discovery - The adversary is trying to figure out your environment.

T1087 - Account Discovery - There are no system users on unikernels so this set of techniques are only applicable for unikernel based environments at other levels such as cloud accounts.

T1580 - Cloud Infrastructure Discovery - This remains a viable technique assuming an attackers payload can perform the required enumeration. It is made harder in a unikernel environment though as there is no shell and so all code whether it's ICMP or TCP or something else will be required to be in the payload itself.

T1538 - Cloud Service Dashboard - This is applicable in a unikernel environment. This is the equivalent of having root on a system but at the infrastructure layer so should be given higher attention to securing.

T1613 - Container and Resource Discovery - While container discovery is not something that is applicable in a unikernel environment unikernel image discovery might be and you would need to consult your IAM policies to ensure this is scoped appropriately.

T1083 - File and Directory Discovery - This technique is still applicable in unikernel environments. If controls are not set at the code level an attacker might be able to enumerate remotely. If an attacker has already compromised the system then various exploit payloads should make this easy to perform.

T1654 - Log Enumeration - If an attacker has compromised the system already then this is probably relatively easy to enumerate.

T1046 - Network Service Discovery - While this can still happen on compromised unikernel instances through exploit payloads it is more challenging to do as typically this will be done via a shell with common tooling - instead the exploit payload will need to have this built in without the capability of leaning on other tools (eg: shelling out to use nmap).

T1135 - Network Share Discovery - Nanos unikernels do not have the concept of network shares today and so this would only be a technique applicable to non unikernel systems.

T1201 - Password Policy Discovery - This technique would not be applicable for unikernel based systems - only non unikernel systems.

T1120 - Peripheral Device Discovery - This technique is largely removed as unikernels are only deploy as virtual machines and so do not have inherent access to things like USB, printers, etc.

T1069 - Permission Groups Discovery - While cloud groups remain a valid target to enumerate there is no concept of local system groups on unikernels.

T1057 - Process Discovery - Since unikernels are a single process system this technique is basically useless as there is only one process and you can't discover more about other processes as they don't exist.

T1018 - Remote System Discovery - Like other techniques that closely resemble this - this technique is not inherently removed it just becomes harder to do. A lot of remote system discovery relies on tools such as telnet, nmap, ping, etc. - none of this is accessible in unikernels - instead the attacker has to make custom paylods that can run code that does this job.

T1082 - System Information Discovery - This technique remains in unikernels but there is a lot less that one can gleam from the system. For instance it is common to embed both the nanos and ops version aws env vars into the system. This might tell you if you are using an outdated version of the kernel but there's so much less other information an attacker can glean from.

T1016 - System Network Configuration Discovery - This technique is much like the prior ones. It is still possible if custom code is loaded in through a payload but it becomes much harder as the attacker can not simply run arp or ip or route or other common commands.

T1049 - System Network Connections Discovery - Like some of the other techniques in this group this can become difficult as you can't simply use lsof or tcpdump or other common tools. The code would need to be in the payload itself.

T1033 - System Owner/User Discovery - As there are no system users on unikernels this technique becomes useless.

T1007 - System Service Discovery - There are no other services running on unikernels so this technique does not provide anything of value.

T1673 - Virtual Machine Discovery - This technique is applicable if an attacker has gained access to the cloud account and can then interact with the various instances. Properly scoping your IAM policies here limits this.

TA0008 Lateral Movement - The adversary is trying to move through your environment.

T1210 Exploitation of Remote Services - It becomes very hard to exploit remote services without a staging area of some kinda, ala a shell, on an existing compromised host. While not impossible unikernels make this technique extremely difficult especially if the host the attacker is trying to exploit is also a unikernel.

T1570 - Lateral Tool Transfer - Lateral tool transfer becomes very difficult in an unikernel infrastructure environment as even if you can download new tools to a compromised system you won't be able to execute the tool nor where you be able to compile one if you need to because you only have source.

T1563 - Remote Service Session Hijacking - While remote service session hijacking still is a viable technique in unikernel environments the ability to do so and the impact of being able to do so are severely limited to the extent that it becomes much harder.

T1021 - Remote Services - Again, the ability to connect to remote services is not necessarily removed as one could tunnel through an existing compromsied service, however, it again becomes hard to do so as the attacker has no shell environment in which to work in.

T1091 - Replication through Removable Media - This technique is not workable as unikernels are only deployed as virtual machines and so do not have access to things like usb.

TA0009 Collection - The adversary is trying to gather data of interest to their goal.

T1560 - Archive Collected Data - While this technique is useable in a unikernel environment many of the common methods of doing so are not. For instance it might be common to download a shell script after popping a box and running 20-30 commands to gather/compress/encrypt/upload password files for instance. In order to perform each of these operations in a unikernel environment each operation needs its custom code put into the payload itself. It can not be an external program. That's what makes this technique, like the others like it more difficult.

T1123 - Audio Capture - There are no audo device or webcam devices with unikernels as they are virtualized and server-side only so this technique doesn't do anything.

T1119 - Automated Collection - This technique isn't really something that happens on unikernel systems as it usually implies an illicit cronjob.

T1530 - Data From Cloud Storage - If the compormised unikernel system has existing access to a cloud storage bucket and the attacker knows it this could potentially be a technique.

T1005 - Data From Local System - If a unikernel instance was compromised than the attacker presumably should be able to any other data on the system.

T1039 - Data from Network Shared Drive - Nanos today does not have this concept so this isn't really applicable for nanos unikernels.

T1025 - Data From Removeable Media - As mentioned for other techniques since unikernels are virtualized there is no removeable media.

T1056 - Input Capture - This technique does not provide much fruit as neither keylogging nor GUI capture work in a unikernel environment.

T113 - Screen Capture - Serial consoles can be exposed on unikernel instances so if you log directly to serial an attacker might see that output, however production environments typically will ship to a logging endpoint such as elasticsearch.

T1125 - Video Capture - There is no video support in unikernels so this isn't a technique that gets used.

TA0011 Command and Control - The adversary is trying to communicate with compromised systems to control them.

T1071 - Application Layer Protocol - Obviously various application level protocols can be used as command and control channels, however they will be limited in scope of what they can do. For instance they can not spawn a reverse back shell or execute random commands.

T1092 - Communication Through Removal Media - There is no removeable media on unikernels so this is not a technique that can be used.

T1105 - Ingress Tool Transfer - While attackers might be able to upload a simple script in the same language a unikernel is using or modify an existing binary with new functionality they can not transfer arbitrary tools into the unikernel and start executing them. This is a pretty large limitation for this technique.

T1104 - Multi-Stage Channels - This is a very common technique for malware on linux based systems, however, the majority of these tools are designed for multi-process systems - they expect to be able to have a shell to work with and execute many different commands so why this technique can't be eliminated in a unikernel environment it can be severely scaled back.

T1090 - Proxy - While proxies can be utilized in unikernel environments they are typically installed via external tooling as a compromised host can be used as the proxy but then needs the capability to forward traffic to the next target. To utilize this technique in a unikernel environment the attacker would need to ensure they can execute this payload through the compromised service vs as a new program.

T1219 - Remote Access Tools - Using tools like RDP, IDE tunneling and such are typically not choices on unikernels as these tools usually involve running many other programs and a unikernel only runs one.

TA0010 Exfiltration - The adversary is trying to steal data.

Generally speaking there is very little difference on exfil of a unikernel instance vs a normal linux instance other than the fact that one can simply not use ad-hoc tooling to do so. For instance if an attacker wanted to exfil a mysql database they wouldn't be able to run something like mysqldump on the compromised unikernel host. They would need to connect from a different instance or have code that can do the dumping and send it over an existing established channel.

TA0040 Impact - The adversary is trying to manipulate, interrupt, or destroy your systems and data.

T1531 - Account Access Removal - While an attacker might be able to remove a cloud account they can not remove a system account because there is no system account on a unikernel to begin with.

T1485 - Data Destruction - Generally speaking this technique is going to be similar to a linux environment just like a unikernel environment. If an attacker has already compromised an instance it isn't a lot of effort to start removing files. The attacker might need to use a webshell on the unikernel instance and use actual libc calls vs shelling out to the same similiar commands but it can be done.

T1565 - Data Manipulation - This is very similar to data destruction in that the same techniques can be used to achieve this purpose.

T1491 - Defacement - If an attacker has compromised a unikernel instance they can probably easily deface a webserver by simply copying over a new file.

T1561 - Disk Wipe - This technique can be used against a unikernel system much in the same way as the data destruction technique. Again, there are no 'rm -rf' style tools available to use but one could make various glibc calls to do the same.

T1496 - Resource Hijacking - In general a lot of resource hijacking techniques are still permissable on unikernel systems but under the circumstance that you can't simply download a new binary, such as a cryptominer and have it work since it is in all likelihood a completely different language under a different program.

T1529 - System Shutdown / Reboot - An attacker can shut down a unikernel instance in a variety of ways. If they have access to the cloud api that is one way. If they can inject a fault that is another way. What an attacker can't do is issue commands like 'reboot' or 'shutdown'.

Summary

As you can see unikernels remove plenty of MITRE ATT&CK Techniques from being used at all and severely throttle the scale and magnitude of many others.

While most of our articles are not living documents we might try to keep this one more current as new techniques are added. Also, if we got something wrong or should clarify something please let us know!

You made it to the end! It is important to note that this is not an exhaustive list and unikernels are still a relatively new method of deploying software but we hope this starts to provide a waypoint for navigating attacker techniques and tactics on unikernel systems.

If you have any questions on how unikernels might help to protect your infrastructure please reach out.