Seven of the ten largest businesses by market cap in 2020 were IT companies. Some offer on-premises or cloud software or products, and the source code is one of their most valuable assets. Like any corporate critical asset, source code is of huge interest to threat actors. Compromising the source code opens up possibilities for attackers, who can subsequently sell it to the company's competitors or other cybercrime/APT groups to conduct "white-box" security research and identify system vulnerabilities. Product builds provide an opportunity to deploy the product in private networks, perform black-box security analysis, and resell pirated copies.
Security incidents involving source code occur all the time. Big-name companies are no exception: Nissan source code was leaked
in early 2021 after a Git repository misconfiguration, Microsoft 10 source code and builds were leaked
, and Watch Dogs: Legion
source code ended up
online after Ubisoft was hit with Egregor
During a recent incident response engagement, I and other Group-IB DFIR experts discovered that adversaries had accessed a misconfigured CI server to steal product source code by launching a CI pipeline and downloading build artifacts from the job workspace.
Security misconfiguration (e.g., public-facing web-service) and weak authentication (no two-factor authentication and weak passwords or insecure cryptographic storage) are most often to blame.
The abovementioned incident prompted me to write this blog post and share our experience. While the vectors and attack scenarios might be different, what is always the same is the financial and reputational losses as a result of source code compromise. This article covers the sources of digital forensic evidence and investigation patterns for various "atomic" activities of development team tools in case of source code and related incidents. Atomic activity is a plain action made by human (e.g., user login attempt, API token creation) or automated scripts (e.g., git push web-hooks).
Such activities help the investigators identify whether the attacker used credential access or persistence techniques. The post contains recommendations on secure product development practices. Security Operation Centers (SOCs) and blue teams in organizations can use this article to improve their security monitoring and detection measures.
For the sake of convenience, we will use the following: GitLab CE (community edition) version 13.7.1 as VCS (version control system) and Jenkins (LTS) version 2.263.1 as CI. According to surveys, these two tools are the most popular among developers and DevOps engineers. Acknowledgements I would like to thank my colleague Vladislav Azerskiy for contributing to current research by performing forensic analysis of Jenkins CI and developing the examination plan.