alt Hacker NewsSee [1] for April 2024 Clickhouse Github activity analysis of the xz backdoor.
I haven't seen anyone write up a proper analysis that includes consideration of:
- GitHub activity (e.g. all API actions on GitHub side including replying to comments) _and_ mailing list activity _and_ other public facing activity all considered together.
- Complexity of public actions e.g. was there a queue of code changes that would have taken 20 hours effort to put together that were all committed at once? Were there any long streaks of high activity where it might reveal how many people were involved?
- Latency of public actions e.g. if an issue was raised by some random person, how long did it take for the attacker to respond, and later resolve/commit a patch? Similar to the complexity of public actions, it might reveal how many people were involved by estimation of the time needed for an experienced developer to fix an issue vs. actual time taken, both in terms of level of effort and duration.
- International dispersement of a team in different timezones with some core hours for collaboration, review and public facing activity.
- Public holidays, country/region-specific work habits, etc--e.g. consideration of "summer holiday" periods or similar common holiday periods, consideration of unusual days of no/low activity versus snow days, power outages, etc which might have been experienced by the attacker.
Distribution of actions from Github indicates the attacker used a 6 day work week excluding Sunday, and almost all activity conducted between UTC 12:00-16:00. Within these 6 days, activity was uneven at 0.5, 1, 1, 1, 1, 0.5 effort per day. There are low activity periods too that line up with summer solstice (southern hemisphere) or winter solstice (northern hemisphere).
There are interesting patterns in the data not yet publicly analysed (I think?) that seemingly would reveal the true location of attackers, particularly because attacker actions are anchored to uncontrollable events such as a known-good contributor (such as Linux distro maintainer) raising a Github issue against a repository and the attacker replying an hour later. For such events with low latency of reply, it'd be well worth considering when a reply was made quickly, and when it wasn't, across a few years of data points.