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 Campaign Status.