2026.07Prophet Evaluation9 min read

Evaluating Exfiltration Over an Established Cloud Channel

A controlled evaluation of exfiltration detection by IRIS Baryon 1.B and attack reconstruction by Apollo against a rate-limited transfer over an established Google Drive relationship.

Evaluation summary

Scenario: Valid access, stock tooling, encrypted transport, a familiar cloud service, and a transfer deliberately spread across several hours.
Detection boundary: IRIS received network telemetry only. It did not receive login, process, file, command, or identity evidence.
Detection result: IRIS measured a material behavioral departure inside an established host-to-service relationship.
Reconstruction result: Apollo reconstructed the attack provenance chain from access through egress while preserving what the evidence could not establish.

Initial access is only the beginning of a breach. Data theft is a common objective of modern post-breach operations. To turn access into that outcome, an attacker has to act through the environment: use an identity, execute, collect, stage, and eventually move data across the network. Exfiltration is the network-visible end of that larger operation.

Once inside, an attacker can use valid credentials, ordinary administrative tools, encrypted transport, and cloud services already present in the environment. Each component can be legitimate in isolation. The attack exists in how those components are composed over time and in service of an objective the environment would not have produced on its own.

This makes exfiltration a useful paired evaluation. Detection has to recognize that an established communication relationship has changed state. Attack reconstruction has to recover the access path, identity, processes, and actions that produced the change.

Evaluation boundaryThe evaluation begins after initial access. It does not test whether Prophet prevented or detected the acquisition of the credential. It tests whether the activity produced after access becomes visible on the network and whether its provenance can be reconstructed from evidence.

01 / Network telemetry

Exfiltration detection

IRIS Baryon 1.B, Prophet's internal network detection model, received network telemetry. The question was whether IRIS could identify a material behavioral shift inside an established source-to-service relationship without destination novelty, a known-malicious indicator, payload inspection, or host evidence.

IRIS Baryon 1.B

02 / Network + host evidence

Attack reconstruction

Apollo, Prophet's autonomous attack reconstruction system, received the network and host evidence available for the event. The question was whether Apollo could recover the full attack provenance chain, test competing explanations, and preserve any fact the evidence could not establish.

Apollo

The simulation used an existing operational system that already communicated with Google Drive, not a sterile test host created for the exercise.

The simulated operation followed a post-access exfiltration sequence:

AccessAn established credential was used to access the system.
CollectionInternal data was collected and staged locally.
EgressStock file-transfer tooling initiated an encrypted upload to a pre-existing Google Drive destination.
Rate limitThe transfer was bandwidth-limited to continue over several hours.

These choices kept the destination service, access path, and transfer mechanism inside familiar or legitimate surfaces while changing the behavior of the communication relationship. The evaluation did not introduce a malicious domain, failed authentication, custom malware, or an unrestricted volume spike.

The evidence boundary was deliberate. IRIS did not receive the login, command, process, file, or identity evidence used for reconstruction. Its result had to come from the changing shape of network communication itself.

IRIS Baryon 1.B measured the transfer as a material behavioral departure within an existing host-to-service relationship.

Before the evaluation, the system's Google relationship was low volume. During the simulated operation, that relationship became sustained and strongly upload-dominant. Its direction, volume, continuity, and temporal shape departed from both the system's own history and the behavior expected for the relationship.

The significant result was not that the system communicated with Google. That was already established behavior. IRIS identified a change in how the system communicated with Google using network evidence alone.

FIG.01Evidence capture reserved

Screenshot placeholderIRIS detection finding

Detection view showing the established source-to-service relationship and the measured behavioral departure.

FIG.01IRIS identified the transfer inside an existing Google relationship from network evidence alone.

Apollo reconstructed the attack across host, identity, process, and historical communication evidence. The resulting provenance chain contained five stages:

AccessAn established remote-access path authenticated successfully using a valid credential.
IdentityThe credential and local account were established, while the person controlling the credential at the time remained unproven.
ExecutionThe resulting session launched ordinary shell and file-transfer tooling rather than an observed implant.
CollectionInternal data was assembled into a local staging location.
EgressThe staged data was transferred to Google Drive over an encrypted, bandwidth-limited connection.

After the transfer completed, the Google relationship returned to its prior low-volume behavior.

FIG.02Evidence capture reserved

Screenshot placeholderApollo attack provenance chain

Reconstruction view connecting access, identity, execution, collection, staging, and egress.

FIG.02Apollo reconstructed the operation from established remote access through encrypted cloud egress.

The network and host evidence independently converged on the same operation. Network telemetry established the destination, direction, duration, and transfer shape. Host telemetry connected that communication to the access session, account, process ancestry, staged data, and transfer mechanism.

Apollo also tested alternative explanations. The observed evidence did not support brute-force access, a newly created account, scheduler-launched execution, newly installed persistence, process injection, or a transfer driven by an observed implant. The operation was performed through valid access and stock tooling.

FIG.03Evidence capture reserved

Screenshot placeholderApollo discriminator findings

Evidence used to separate the observed operation from scheduled activity, recurring exports, and implant-driven exfiltration.

FIG.03Competing explanations were tested against the available evidence rather than silently discarded.

The available evidence could not establish who controlled the valid credential at the time of the event, whether the receiving Google Drive account was organization-controlled or personal, or whether the transfer had been authorized out of band.

Known: An established access path and valid credential were used to collect, stage, and transfer internal data to Google Drive.
Unknown: Who controlled the credential, who controlled the receiving account, and whether the transfer was authorized.
Therefore: Confirm authorization and destination ownership outside the observed telemetry. If the operation cannot be tied to an approved task, treat it as data theft and rotate the affected access credentials.

FIG.04Evidence capture reserved

Screenshot placeholderEvidence boundary

Apollo verdict separating what the evidence established, what remained unknown, and the resulting action.

FIG.04The reconstruction preserved missing business context instead of converting it into an unsupported malicious verdict.

This distinction matters. The evidence established what happened and how it happened. It did not establish the intent of the person controlling the valid credential.

BehaviorA familiar service did not make the operation indistinguishable from normal activity. IRIS evaluated the changing behavior of the relationship rather than assigning risk to the destination itself.
TrajectoryRate limiting changed the local transfer rate, but it did not erase the full trajectory from established state to sustained upload and back to baseline.
SeparationIRIS reached its finding from network telemetry. Host evidence entered when Apollo reconstructed how the communication was produced.
ProvenanceApollo followed valid access through identity, ordinary processes, local staging, and network egress without requiring custom malware.
BoundaryThe reconstruction connected the operation while keeping unresolved authorization explicit instead of turning missing business context into a malicious verdict.

This was a controlled capability evaluation in one environment, against one host, service, and transfer strategy. It was not a blind or independent benchmark.

The scenario did not evaluate initial-access detection or lateral movement. The result does not establish universal exfiltration coverage, arbitrary low-and-slow sensitivity, actor identity, or a fleet-wide false-positive rate. Those require repeated evaluations across authorized controls, additional systems, services, rates, and transfer strategies.

Within the tested scenario, Prophet identified a material behavioral departure inside an established cloud relationship and reconstructed the attack provenance chain from access through egress without claiming knowledge the available evidence could not support.