C2 Functionality

Callback Monitoring & Orchestrator Playbook Validation

Overview

EVE (Epiphany Validation Engine) provides advanced callback monitoring capabilities designed to validate the correct execution of Security Orchestrator playbooks (SOAR) and similar solutions.

Through controlled artifact generation and monitored callback infrastructure, EVE enables organizations to verify whether automated security workflows properly detect, process, enrich, contain, and block malicious activity as defined by their orchestration logic.

This functionality is critical for validating:

• Automated response workflows

• IOC enrichment and propagation

• Firewall / IDS / IPS blocking logic

• EDR containment rules

• URL and hash aggregation processes

• Trigger-based playbook execution

EVE does not validate theoretical configurations, it validates operational reality.

Callback-Based Validation Architecture

EVE generates custom artifacts that may include:

• Controlled payloads

• Obfuscated test files

• Kill-switch callbacks

• Controlled malware simulation

• Fileless execution artifacts

• Specific IoC-triggering artifacts

Each artifact contains a callback mechanism that reports execution results to EVE-controlled monitoring infrastructure.

When the artifact executes inside the target endpoint, EVE verifies:

• If the callback was initiated

• If the callback was blocked

• If it was partially processed

• If playbooks reacted as expected

• If enforcement mechanisms were applied

This enables deterministic validation of automated response workflows.

Playbook Validation Logic: First vs Second Execution Model

One of the most important validation mechanisms in EVE is the controlled repeated execution model.

First Execution – Baseline Trigger

During the first execution:

1. The artifact is delivered.

2. Endpoint activity is generated (evasion, injection, fileless, etc.).

3. EDR / SIEM generates an alert.

4. The orchestrator playbook is triggered.

5. The playbook should:

   • Extract IoCs (URL, hash, domain, IP, etc.)

   • Enrich or process them

   • Push blocking rules to FW / IDS / IPS / EDR

   • Store indicators in defensive systems

If this flow completes successfully, the environment is considered responsive.

However, this does not yet validate enforcement.

Second Execution: Enforcement Validation

The same artifact is executed a second time.

At this stage, one of two outcomes must occur:

✅If the callback is still allowed

• The artifact reaches the callback server.

• The firewall / IPS / proxy did not block the URL.

• The playbook failed to enforce protection.

• Result: Playbook validation failed.

❌ If the callback is blocked

• The callback never reaches EVE infrastructure.

• Network controls block the URL or domain.

• EDR may block execution pre-callback.

• The playbook successfully enforced security policies.

• Result: Playbook validation successful.

This repeated-execution logic allows EVE to validate not just detection, but true containment.

Validation of Mandatory Orchestrator Playbooks

Many SOAR platforms include mandatory playbooks such as:

• URL aggregation playbooks

• IOC extraction workflows

• Auto-block policies

• Threat intelligence enrichment

• Firewall rule deployment

• Endpoint isolation procedures

EVE validates whether these playbooks:

• Trigger when expected

• Process the correct IoCs

• Push enforcement rules

• Propagate protections to relevant security controls

• Close the loop operationally

If the second execution fails to be blocked, EVE provides immediate validation feedback.

Custom Artifact Generation with Exact IoC Triggering

EVE supports custom obfuscated artifact creation.

Artifacts can be generated with:

• Exact URL triggers

• Specific file hashes

• Custom domains

• Specific attack techniques

• Fileless patterns

• Shellcode injection behaviors

• Evasion layers

If a playbook requires a very specific IoC structure to trigger correctly, EVE can generate an artifact that precisely matches those requirements.

This ensures validation aligns exactly with production automation logic.

Callback Infrastructure and Monitoring

EVE maintains dedicated callback servers that:

• Receive artifact callbacks

• Correlate execution events

• Timestamp activity

• Associate events with campaigns

• Validate delivery success or blocking

• Provide execution telemetry

These servers are used exclusively for validation purposes and are part of EVE’s controlled infrastructure.

Callbacks can represent:

• URL requests

• DNS requests

• HTTP/HTTPS callbacks

• Kill-switch verification

• Malware download simulation

The callback telemetry is used to determine playbook performance and enforcement status.

Internal Execution Flow: Artifact & C2 Callback Mechanism

Internally, EVE operates through a controlled artifact execution model designed to simulate realistic endpoint behavior while maintaining deterministic validation.

The basic execution flow is as follows:

1. Artifact Download The generated artifact is delivered to the endpoint and saved in the default Downloads directory.

2. Artifact Staging The artifact is programmatically copied into a dedicated execution directory. This directory acts as the controlled runtime environment for validation.

3. Configuration File Generation (.ini) Inside the execution directory, EVE generates a configuration file (.ini). This file contains:

   • The C2 (callback) IP address

   • A unique instance identifier (Instance ID)

   The Instance ID allows correlation between execution attempts and specific validation campaigns.

4. Artifact Execution The artifact is executed from the execution directory.

5. Runtime Configuration Usage During execution, the artifact reads the .ini file to:

   • Retrieve the C2 IP address

   • Associate execution with the specific Instance ID

   • Initiate the callback communication

This design allows EVE to dynamically control callback destinations and uniquely track each execution attempt without hardcoding infrastructure details inside the artifact itself.

The separation between artifact binary and runtime configuration ensures flexibility, traceability, and precise validation of enforcement mechanisms across multiple executions.