Artifacts
Refer to malware samples that are used to emulate various types of cyber threats. These artifacts are essential components in the platform's testing and validation processes, allowing organizations to emulate real-world attack scenarios in a controlled environment.
Each artifact represents a specific type of threat and is designed to mimic the behavior of actual cyberattacks.
Artifacts Categories in EVE
The EVE platform organizes artifacts into several categories that describe how a sample is constructed and how it behaves during an emulation. These categories help security teams understand the level of realism, transformation, and evasion techniques applied to each artifact.
Artifacts can belong to a single category or a combination of categories, such as Known, Obfuscated, Forced, or combinations like Known-Obfuscated. This classification allows organizations to select artifacts that best align with the threat scenarios they want to emulate and the level of sophistication they want to test against.
Known
Known artifacts are samples that are well identified and commonly recognized by the cybersecurity community. These samples correspond to malware families, tools, or techniques that have been previously observed in real-world attacks and are documented by threat intelligence sources.
The naming of these artifacts follows a structured convention aligned with commonly used industry naming, allowing analysts and defenders to easily identify the type of threat being emulated and its relationship to known campaigns, tools, or malware families.
Testing with Known artifacts allows organizations to validate whether their security controls are capable of detecting threats that are already publicly documented. These artifacts are useful for validating baseline detection capabilities across security technologies such as endpoint protection platforms, EDR solutions, network security controls, and SIEM systems.
Obfuscated
Obfuscated artifacts are samples that have undergone a process of code transformation designed to disguise their structure and behavior, making them more difficult for security tools to detect using traditional signature-based methods.
These artifacts emulate more sophisticated threats that rely on evasion techniques to bypass security controls. The purpose of these artifacts is to simulate adversaries who deliberately manipulate code in order to evade detection and analysis.
The obfuscation techniques applied to these artifacts take into account common obfuscation methods documented in the MITRE ATT&CK framework, particularly techniques such as Mutation and Virtualization.
Mutation-based obfuscation involves altering the internal structure of the code while preserving its functionality. This may include actions such as:
Modifying instruction sequences
Rewriting control flows
Renaming variables or functions
Inserting nonfunctional or junk instructions
Encoding or transforming parts of the payload
These changes produce multiple unique versions of the same artifact, making it more difficult for static signatures or hash-based detection mechanisms to identify the sample.
Virtualization-based obfuscation introduces an additional layer of complexity by executing the malicious logic inside a custom virtual machine or interpreter embedded in the artifact. In this approach, the original instructions are translated into a set of virtual instructions that are executed by an internal runtime engine. This abstraction layer hides the real logic of the artifact, making analysis and detection significantly more challenging.
By incorporating these techniques, Obfuscated artifacts allow organizations to evaluate whether their security stack can detect threats that intentionally attempt to evade detection mechanisms.
Forced
Forced artifacts are samples that have been encrypted through a proprietary process implemented by Reveald. In this category, the original sample, which may belong to any other category such as Known or Obfuscated, is encrypted before being delivered to the endpoint.
The encrypted artifact can only be decrypted by the EVE agent during the download phase on the endpoint. This controlled decryption process ensures that the artifact remains protected during distribution and cannot be easily analyzed or intercepted before execution.
This mechanism provides several benefits. First, it allows artifacts to be delivered in a secure and controlled manner, preventing exposure of the original sample during transit. Second, it enables the platform to avoid premature detection by security tools that may inspect files before they reach the endpoint environment.
Forced artifacts therefore simulate scenarios where payloads are protected or concealed until execution, providing a realistic method for testing how security solutions behave when malicious content becomes visible only at runtime.
Zero
Zero artifacts are custom samples generated on demand by Reveald. Unlike Known artifacts, which are based on previously identified threats, Zero artifacts are dynamically created to simulate new or unknown attack conditions.
These artifacts are designed to help organizations evaluate their defenses against previously unseen threats, similar to zero-day scenarios where no known signatures or indicators exist.
By using Zero artifacts, security teams can assess whether their defenses rely solely on known threat intelligence or whether they can also detect suspicious behavior and anomalous activity, which is critical for identifying emerging threats and advanced adversaries.
Naming Conventions for Artifacts
Artifacts in EVE are named according to a structured nomenclature that provides clarity and consistency. The naming convention varies depending on whether the artifact is a known, generic, or modified sample.
Known Artifacts (Named)
For named known artifacts, the structure is as follows:
Sample Name: The most common name of the sample, usually found through research on platforms like VirusTotal.
Malware Type: The abbreviation of the malware type from the provided list (e.g., Ransom for ransomware).
Extension: Always
.exe.
Example: WannaCry.Ransom.exe
Generic Artifacts
For generic known artifacts, the structure is:
First 5 characters of SHA256: A unique identifier derived from the sample's hash.
Malware Type: The abbreviation of the malware type from the provided list.
Extension: Always
.exe.
Example: e54d1.Adware.exe
Modified Artifacts
Modified artifacts follow similar naming conventions to known artifacts but include an additional identifier for obfuscation or other modifications:
Obf: Indicates that the sample has been obfuscated.
Extension: Always
.exe.
Example: WannaCry.Ransom.Obf.exe or e54d1.Adware.Obf.exe
Special Cases
Variants: If a sample has variants, these are specified with a "V" followed by the variant number:
Example:
PetyaRedV2.Ransom.Obf.exe
Re-Obfuscated Samples: If a sample has been obfuscated multiple times, the subsequent obfuscation is indicated by a consecutive number:
Example:
PetyaRedV2.Ransom.Obf.2.exe
Encrypted Samples (Forced): For samples that have been encrypted, the name includes the identifier "F" for forced:
Example:
PetyaRedV2.Ransom.F.ex
Malware Families Available
Upon customer request, these malware families are available for upload.
In order to upload the families a reques from the customer needs to be done.
Use of Artificial Intelligence and Machine Learning in Reveald
Overview
The Epiphany Validation Engine (EVE) is designed as a deterministic and controlled adversary emulation platform. Its primary function is to execute repeatable, measurable and safe attack simulations in order to validate the effectiveness of security controls across network, endpoint and execution layers.
As such, EVE does not rely on Artificial Intelligence (AI) or Machine Learning (ML) algorithms within its emulation execution engine. This design ensures that all validations are predictable, auditable and fully reproducible, which is critical for security validation, compliance and control verification use cases.
AI/ML within the Reveald Ecosystem
While EVE itself does not embed AI/ML in its execution layer, Reveald incorporates Artificial Intelligence and Machine Learning capabilities within its threat intelligence and risk analysis processes, which directly inform and enhance validation activities.
These capabilities are part of the broader Epiphany Intelligence ecosystem, and include:
Aggregation of multi-source threat intelligence
Analysis of known vulnerabilities, threat actor behavior and real-world attack patterns
Correlation of external intelligence with internal exposure context
Prioritization of high-risk attack paths and relevant TTPs
Continuous enrichment of threat feeds and attack scenarios
Through this approach, AI/ML is used to identify what should be validated, rather than how the emulation is executed.
Relationship Between AI/ML and EVE
Within the Reveald architecture:
AI/ML capabilities operate at the intelligence and prioritization layer
EVE operates at the execution and validation layer
This means:
AI/ML helps determine:
Which threats are relevant
Which attack paths represent real risk
Which TTPs should be tested
EVE ensures:
Controlled execution of those scenarios
Safe validation of controls
Measurable and reproducible results
Security and Validation Rationale
By separating AI/ML from execution, Reveald ensures that:
Emulations remain fully controlled and non-autonomous
Results are consistent and comparable over time
Security teams can validate controls against known conditions
There is no risk of unpredictable behavior during testing
This architecture aligns with best practices in:
Breach and Attack Simulation (BAS)
Purple Teaming methodologies
Continuous security validation frameworks
Last updated