# E21. Build and hosting chronology

## Timestamp sources

The build-artifact record aligns mail-header times, domain-registration times, configuration commits, ZIP-entry timestamps and Go VCS metadata. These fields describe different events and have different precision and trust properties. The chronology is useful only when those distinctions are retained. [S1]

## Recorded sequence

On 13 July 2026 the record places new domain registrations and a C2 configuration change. The retained Windows agent ZIP has three members dated 13 July and two package-lock members dated 20 July; its full member-date range is 18 June–20 July (Exhibit E21-3). These stored archive timestamps corroborate the note’s archive-date observations, but do not certify build times or prove one operator or one continuous session. [S1]

A phishing message is recorded at 01:08:32 UTC on 21 July. The Go binary records `vcs.time` as 01:14:06 UTC, five minutes and thirty-four seconds later. The latter is version-control metadata, not certified compiler output time. The original statement that compilation happened five minutes after mailing is therefore not supported by that field alone.

## Archive interpretation

ZIP local timestamps must be distinguished from UTC extended fields and from the analyst's display timezone. Even a consistently recovered offset describes archive metadata, not physical location. Repackaging and deliberately set clocks remain alternatives. The Go trimpath setting removes path information but does not identify a build host or prove malicious anti-analysis intent by itself. [S1]

## Hosting changes

An early infrastructure note centers on `23.137.105[.]75`, then adds `170.205.30[.]227` through overlapping historical domain observations. Later analysis identifies `207.241.172[.]222` for C2/administration and `170.205.31[.]182` for lure hosting. These notes must be read as successive observations, not simultaneous or exhaustive topology. The earlier single-host and dismantled-fleet descriptions are not evidence that all later activity ended. [S2, S3]

## Assessment

A defensible chronology preserves the raw field, timezone semantics, source and event type. Resolution, registration, content retrieval and service disappearance are separate events. This report establishes recorded temporal associations, not an operator's location, certified build times, present availability or measured disruption.