> For the complete documentation index, see [llms.txt](https://docs.reveald.com/technical-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reveald.com/technical-documentation/admin-guides/epiphany-validation-engine-users-guide/chapter-3-eve-platform/navigation-tabs/emulation-control/email-fraud-and-infiltration/creating-an-attack-campaign.md).
# Creating an Attack Campaign
EFI allows security teams to create highly customizable email attack campaigns that emulate real-world phishing and malware delivery scenarios. These campaigns can be configured with different payload types, delivery methods, and execution modes to test various layers of email and endpoint defenses.
Campaign creation is handled through a guided interface that walks the user through all the necessary steps, from naming the campaign to selecting the payload and scheduling execution.
To create an Email Attack Campaign:
1. Click on the 
Add campaign button at the top of the EFI Campaigns Table
2. Follow the wizard.
### **General Information**
The first step in creating an EFI campaign is to define its basic metadata and scheduling parameters. This step ensures that each campaign is properly identified, scheduled, and targeted based on the intended scenario.
| **Field** | **Description** |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Campaign Name** | Enter a unique name to identify the campaign. Use meaningful names that describe the test scenario. |
| **On Demand Start** | Enable this option if you want to manually start the campaign later. Disables the scheduling fields. |
| **Campaign Start** | Select the date and time when the campaign should begin. |
| **Campaign End** | Define when the campaign should expire and stop collecting telemetry. |
| **Campaign Description** | Provide an overview of the campaign's objective, scope, or target audience. |
| **Target OS Distribution** | Choose the operating system intended to receive and execute the payload. Options include **Windows** and **Linux**. Currently, **Windows** is the most common target. |
* If On Demand Start is checked, the campaign will start as soon as the campaign is published.
* Start and End Times are essential for scheduled campaigns and help determine the Active or Expired status later.
* The Target OS influences the type of payload generated and the behavior of the emulation.
This information sets the foundation for the rest of the campaign configuration and ensures operational context is recorded for future reporting.
### Campaign Selection
Selects the type of campaign execution mode, which defines how the simulated attack will behave and whether telemetry will be collected from the endpoint.
You must choose between:
**Realistic and Controlled Attack Campaigns**
This mode provides full observability of the simulated attack lifecycle.
* Payloads are generated from EFI’s internal library or uploaded scripts.
* The EVE agent is embedded to collect telemetry from the endpoint.
* EFI tracks:
* Delivery and interaction (clicks, opens)
* Payload execution status
* Endpoint response
* C2 (command and control) communication behavior.
Ideal for testing real-world attack scenarios and validating detection and response capabilities across email, endpoint, and network layers.
**Unattended Attack Campaign**
This mode is designed for basic validations with no endpoint telemetry.
* Organizations can use their own artifacts or scripts.
* EVE does not embed the agent in the payload.
* The platform does not collect post-delivery telemetry, even though payloads may still execute if the user interacts.
* Used primarily to verify email delivery, routing, and gateway-level filtering.
Recommended for infrastructure testing and environments where deeper tracking is not needed or permitted.
### Threat Selection
In this step, users select the synthetic threat that will be embedded into the campaign. EFI allows the use of both predefined synthetic samples **and custom uploaded artifacts**, enabling flexible and realistic emulation of attacker behavior.
The selection interface displays a table of available threats with the following attributes:
| **Column** | **Description** |
| ------------- | -------------------------------------------------------------------------- |
| **Name** | File name of the threat or payload to be used in the campaign. |
| **Severity** | Assigned severity level. |
| **Platform** | Indicates the operating system compatibility (e.g., Windows). |
| **Size (KB)** | File size of the payload in kilobytes. |
| **Arguments** | Displays if any execution arguments are defined (for executable payloads). |
Users can search, filter, and navigate through available files using the toolbar at the top.
**Threat Types**
At the top of the view, you’ll find:
* THREAT: Refers to EFI’s built-in synthetic threats.
* CUSTOM THREAT: Refers to artifacts uploaded by the user or organization (scripts).
**Notes**
* Multiple threats can be selected per campaign.
* The selected threat will later be delivered via the chosen broadcast method (Email, Link, QR).
* The payload’s behavior and observability will depend on the campaign mode selected in Step 2:
* Controlled: Embedded agent collects telemetry.
* Unattended: No post-delivery tracking.
This step allows security teams to simulate realistic threat vectors by tailoring the type of file, severity, and behavior they wish to validate.
### Distribution
In this step, users define **how the simulated threat will be delivered** to the target users. EFI supports three broadcast channels:\
• 
Link\
• 
Email\
• 
QR Code
Each method ultimately leverages an **attacker URL** generated by the platform, but the delivery and presentation differ depending on the selected channel.
#### **Email Distribution**
This is the most comprehensive and customizable method. It includes the following configuration fields:
| **Field** | **Description** |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Email Template** | Select from a variety of predefined phishing templates categorized under tabs such as `Alerts`, `E-Commerce`, `Government`, `Login`, `Social Media`, and more. |
| **Login Page (visual)** | Choose the appearance of the login or bait content (e.g., spoofed financial institution, login portal). A preview is displayed on the right. |
| **Subject** | Define the subject line that will appear in the phishing email. |
| **Email Recipients** | Manually input the email addresses of intended targets. |
| **Artifact Delivery Method** | Defines how the synthetic threat is embedded or linked inside the email. |
| **Attached Agent in Email** | If selected, embeds the lightweight EVE agent to enable full telemetry collection. |
This setup allows for **realistic phishing simulations**, closely mimicking what end users would see in real-world attack attempts.
#### **QR Code and Direct Link Distribution**
When using QR Code or Direct Link as the broadcast method, the user must define the Artifact Delivery Method, which determines how the payload is structured and delivered, as well as how telemetry is handled.
#### Artifact Delivery Method
#### **Bundled with Agent**
* The full payload, including the synthetic threat and the embedded light EVE agent, is delivered in a single bundled file.
* Once the user executes the file, telemetry is collected immediately, covering:
* Agent report to console.
* Monitoring of payload execution.
* This method is best for Controlled Campaigns with full end-to-end observability.
#### **Network Download**
* The initial file delivered is a lightweight launcher, typically just the embedded EVE agent.
* Once executed, this agent triggers the download of the actual synthetic threat from the configured attacker URL.
* This two-stage execution allows the campaign to test the network vector, as the second-stage malware is retrieved via HTTP or HTTPS, defined in a later configuration step.
* Telemetry starts once the malware is downloaded and executed, enabling visibility into:
* Whether the malware was downloaded.
* Monitoring of payload execution.
This method is ideal for testing real-world scenarios where malware is not delivered directly, but instead downloaded after initial access, mirroring common attacker techniques like dropper behavior and C2 staging.
### Payload Configuration
Users define the final behavioral and visual characteristics of the payload. This includes execution parameters, file appearance, delivery behavior, and execution order of the threat components.
**Execution Configuration**
| **Option** | **Description** |
| ------------------------- | ------------------------------------------------------------------------------------- |
| **Secure Download** | Forces the network download (used in "Network Download" mode) to occur via **HTTPS**. |
| **Zipped** | Wraps the payload in a ZIP archive, simulating common malware evasion techniques. |
| **Threat Timeout** | Timeout (in seconds) for synthetic threats to run before being forcefully terminated. |
| **Custom Threat Timeout** | Timeout specifically for custom threats/scripts. |
**Payload Information**
* **Name**: Label used internally to identify the payload configuration.
* **Payload Description**: Additional notes or metadata to describe the behavior or intent of the payload.
* **Payload Organization**: Logical grouping or classification for organizational or reporting purposes.
**Installer Icon**
This section defines the **visual icon** that will represent the payload when delivered to the end user (e.g., as an attachment or executable). Options include common productivity apps, document formats, and social media platforms to simulate real-world deception tactics.
Selecting an icon helps make the payload more convincing to the user during the test.
**Execution Order (Sorting)**
Users can define the execution sequence of the selected payloads. This is especially useful when multiple components are bundled together.
* Drag and drop files to determine execution order.
* The first item in the list will be executed first once the emulation is triggered on the endpoint.
### **Save and Launch**
The final step in the EFI campaign creation process is where all configuration inputs come together. At this point, you can finalize and initiate the build process for your email emulation campaign.
* Once all steps have been completed, the interface displays a summary screen titled "Campaign Creator", indicating the campaign is ready for deployment.
* To confirm and initiate creation, click the “CREATE” button at the bottom of the screen.
* If changes are needed, you may click “BACK” to return to any previous step.
**What Happens Next**
After clicking “Create”, the platform returns you to the EFI Campaign Table, where the new campaign now appears with its current status.
To monitor the build progress and lifecycle, click on the Status indicator of the campaign. See details on [EFI Campaigns Table](/technical-documentation/admin-guides/epiphany-validation-engine-users-guide/chapter-3-eve-platform/navigation-tabs/emulation-control/email-fraud-and-infiltration/efi-campaigns-table.md#campaign-status).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.reveald.com/technical-documentation/admin-guides/epiphany-validation-engine-users-guide/chapter-3-eve-platform/navigation-tabs/emulation-control/email-fraud-and-infiltration/creating-an-attack-campaign.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.