Halcyon Red Team Testing Procedure and Expectations

Introduction

This document outlines the recommended procedures and expectations for Red Teams conducting security evaluations of Halcyon's ransomware protection technology. Unlike traditional Endpoint Protection (EPP) and Endpoint Detection and Response (EDR) solutions, Halcyon is purpose-built for ransomware protection. Consequently, traditional security testing methodologies may not fully apply.

To ensure meaningful and actionable test results, it is essential that all tests accurately reflect real-world ransomware attack methodologies.

Testing Expectations

1.1 Use Realistic Threat Models

• Ransomware actors predominantly utilize compiled binaries written in C++, .NET, Go, and Rust.
• Some newer groups have been observed leveraging Java JAR files running in the Java Runtime Environment (JRE).
• Ransomware rarely uses PowerShell for encryption operations in the wild due to its limitations in entropy generation, cryptographic function support, and scalability, but we have observed documented instances of this.

 

1.2 Key Characteristics of Real Ransomware

• Most ransomware employs hybrid encryption, which combines symmetric and asymmetric encryption. This approach ensures both efficiency and security:
  • Symmetric encryption (e.g., AES, ChaCha20) is used to rapidly encrypt victim files because it is computationally faster than asymmetric encryption.
  • Asymmetric encryption (e.g., RSA-4096, ECC) is used to encrypt the symmetric encryption keys. The attacker keeps the private key, making decryption impossible without paying the ransom.
• Generates unique symmetric keys per file, encrypting footers with an asymmetric key (e.g., RSA-4096).
• Uses cryptographically secure Random Number Generators (RNGs) such as Windows Crypto APIs.
• Deletes shadow copies and terminates security-related processes/services.
• Encrypts files as quickly as possible with minimal user interaction.
• Creates custom ransom notes with unique victim identifiers.

1.3 Limitations of Ransomware Simulators

• Many publicly available ransomware simulators lack key features of real-world threats.
• Examples:
  • PSRansom: Uses the same AES key for all files, making it ineffective.
  • RanSim: Uses hardcoded symmetric keys, making it vulnerable to key reuse attacks.
  • Phirautee: Encrypts all files using RSA, which is computationally infeasible for real ransomware.
• Simulators lacking process termination, backup deletion, or ransom note generation do not reflect real-world ransomware behavior.

Test Methodology Requirements

2.1 Approved Testing Methodologies 

Red Teams should utilize real-world malware samples or build custom ransomware that aligns with observed attacker methodologies.

The malware should:

• Generate unique symmetric encryption keys per file.
• Utilize Hybrid Encryption (Symmetric + Asymmetric)
• Store the encryption key securely (e.g., in file footers or memory).
• Use standard cryptographic libraries (e.g., AES-256, ChaCha20).
• Mimic process termination and shadow copy deletion behavior.
• Attempt to evade detection using packer or obfuscation techniques.

2.2 Unacceptable Testing Approaches 

The following methodologies are not valid for evaluating Halcyon's ransomware protection:

• PowerShell-based ransomware tests: While we have seen a few instances of attacks using admin powershell that delivers ransomware, it is not supported for detection at this time.
• XOR encryption tests: XOR is not used in real-world ransomware due to its weak cryptographic properties.
• Manual encryption scripts: Encryption tools requiring user input are not representative of automated ransomware campaigns.
• File modifications that do not involve actual encryption: File renaming or encoding operations are not equivalent to cryptographic encryption.

2.3 Custom Ransomware Development Guidance 

If Red Teams choose to develop custom ransomware, the following must be included:

• Dynamic key generation for each file using cryptographically secure methods.
• Multithreading for efficient, rapid encryption operations.
• Realistic ransom note generation with victim-specific data.
• Process termination and backup deletion to mimic real-world threats.
• Stealth techniques, such as code injection or packed binaries.

Reporting and Evaluation

3.1 Test Submission Requirements 

To facilitate accurate evaluation and feedback, Red Teams should provide the following details:

• A detailed test methodology, including tools and scripts used.
• The ransomware sample (if custom-developed).
• Evidence of key characteristics:
  • Encryption method (e.g., AES-256, ChaCha20, RSA-4096)
  • Key management process
  • Ransom note structure and behavior

3.2 Halcyon Response to Testing

• Halcyon will review test methodologies and results within a reasonable timeframe.
• If a test aligns with real-world attack techniques, Halcyon will:
  • Provide insights on how its technology responded.
  • Offer recommendations to improve testing methodologies.
• If a test does not reflect real-world attack techniques, Halcyon may reject the findings and provide guidance on more realistic testing approaches.

Conclusion 

This document ensures that Red Team engagements produce meaningful and actionable results by using realistic ransomware methodologies. Halcyon is committed to working collaboratively with security teams to improve resilience against actual ransomware threats, rather than ineffective simulations.

For additional guidance or to submit test results, contact Halcyon Threat Research or Halcyon Customer Success by opening a support case.