While our technology estates have evolved beyond workstations, laptops, servers and networks to include numerous Software services, many organization’s detection and analysis capabilities are still focused on the malware involved in endpoint detection and response tools, and exploits sent detected by network Intrusion Detection Systems and next-gen Web Application Firewalls.  

Meanwhile the loosely disorganized sets of actors associated with theCom (aka Muddled Libra, Scattered Spider, and more) have cemented themselves as the opportunistic threat actor of the day. Known for leveraging social engineering and identity-focused intrusions, their operations have targeted critical infrastructure, telecom, and software supply chains.  The actors associated with theCom have truly democratized the infamous “I hunt sys admins” approach. They often gain initial access by compromising IT help desk staff and administrators.  

The actors frequently target Version Control Systems (VCS) such as GitLab and GitHub. These platforms enable development teams to store, manage, and deploy source code and infrastructure configurations. Development teams often mistakenly commit credentials for other systems to their VCS repositories, which enable the actors to move laterally within the technology estate.  

This post dives into their tactics and techniques used when compromising version control systems (VCS) such as Git, how to detect and mitigate these intrusions, and how Abstract Security helps.
‍

Overview of Intrusion

These intrusions can be roughly categorized into 4 main phases. Initial Access, where the actor uses carefully crafted social engineering techniques to gain initial access to a privileged system. Establishing Persistence to enable the actors to maintain access to the systems. Further Reconnaissance and Lateral Movement where the actors gain access to other parts of the technology estate. Data Exfiltration, when the actors proceed to exfiltrate or encrypt the organization’s data for ransom.

We’ll break the intrusions down below while describing detection and protection opportunities to help mitigate.
‍

Initial Access

These intrusions often begin through the compromise of a laptop or workstation. The actors associated with theCom have professionalized  

path and often target initial access via IT help desks and known administrators identified by using publicly available data from platforms such as LinkedIn.
‍

Establishing Persistence  

After gaining access to a GitLab instance or GitHub user account, the actors often create a new personal access token (PAT). This personal access token will allow the actors to have persistent access to the Git instance, or GitHub organization. They may also add users or outside collaborators to the GitLab instance or GitHub organization.  

Detection  

To identify this activity in GitHub Audit logs look for actions of  

• `personal_access_token.access_granted`

• `org.add_member`

• `org.add_outside_collaborator`

Detecting GitHub actions of `personal_access_token.request_created` can provide early identification of these requests, though this action is more prone to detecting True Positive Benign activity.  

Actors associated with theCom have also been observed adding a member or outside collaborator to your GitHub organization. To detect this activity look for events with `org.add_member` or `org.add_outside_collaborator`

Entries in the GitHub Audit Log with the action “personal_access_token.auto_approve_grant_requests_disabled” are a very high fidelity alert signal that occur when this configuration option is changed. This activity almost never occurs within an organization, and can easily be followed up with your GitHub administrators.  

An example of this activity can be seen in the image below, with identification information obscured.  
‍

There are additional GitHub org activities that are suspicious, rarely occur, and provide high fidelity signals to alert upon. Abstract Security includes out of the box detection rules for this activity and more, including the following GitHub configuration changes which can be useful to detect suspicious activity:

• disabling MFA for users - org.disable_two_factor_requirement

• disabling SAML authentication - action equals org.disable_saml

• Adding or inviting admins: action equals any of business.add_admin or business.invite_admin

• Adding or approving access to Oauth Applications – action equals oauth_application.create or oauth_application.create or  org.oauth_app_access_approved

• Modifying Single Sign On requirements to access your organizations repositories – action equals any of sso_redirect.disable or sso_redirect.enable

The ASTRO detection rule trigger criteria for org.disable_two_factor_requirement is seen below.  

‍

Defense

1. Enable admin access for fine-grained personal access token creation
To protect your organization from unauthorized PATs, enable admin approval of fine-grained personal access tokens. Here's how it looks in the GitHub administrative console.

‍

2. Restrict access via classic personal tokens
   While the above option requires administrator approval for fine-grained personal access tokens, classic PATs are either completely allowed or completely restricted. Once you Allow Access via classic personal access tokens, you will not have further visibility into users creating and associating those to your organization.
   ‍

These controls provide a useful control on static tokens from less permissioned developers. The problem here is that theCom actors are targeting the GitHub Administrators who have permission to change these controls! Luckily GitHub requires the use of multi-factor authentication to make these config changes.  
‍

Further Reconnaissance and Lateral Movement

In the past, actors associated with theCom have connected trial accounts of GitGuardian to git repositories. While GitGuardian is a great tool for security teams to detect leaked credentials in code commits, using this tool allows the actors to find additional credentials to move laterally into additional technology infrastructure such as AWS accounts, GCP projects, Azure subscriptions, VSphere and OpenShift infrastructure, other SaaS platforms, and sometimes event SSH keys. This behavior isn’t limited to GitGuardian, the actors could use other tools such as trufflehog, gitleaks, shhgit, and more.

Detection

You can detect this and other mass git repository collection activity by detecting a threshold of unique repositories within a reasonable time frame. The detection rule below looks for 10 distinct repositories upon which git.clone or git.fetch has been performed within 10 minutes.  

Intrusions into SaaS, PaaS, and IaaS technologies are often hard to accurately detect because nearly all of the actions within these platforms are resident to the platform. This is a similar challenge to the Living off the Land (ref: https://www.youtube.com/watch?v=j-r6UonEkUw ) techniques unveiled by Matthew Graeber and Christopher Campbell  at DerbyCon 3 in 2013. When adversaries are Living off the Clouds the activity blends in with legitimate administrator and developer activity.  

To increase your true positive rates you can create a table of known login IP addresses from your Identity provider, and whether they have been Multi-Factor Authenticated or not. If the activity is originating from the known MFA’d source addresses, then the activity can be treated with a lower severity.

Perhaps your organization does legitimately use GitGuardian or other tools, You can similarly opt to include known infrastructure source_addresses to further improve your true positive rates of Critical detections.
‍

Exfiltration  

There are a few actions on objectives the actors can take to exfiltrate repositories from compromised organizations. The actors can exfiltrate repositories via git.clone actions manually to their local systems.  

Some actors associated with theCom have also been observed manually downloading.zip archives of repositories.

This activity is odd by itself, as most developers prefer to use git clone versus a web UI. Manually downloading multiple .zip files is almost always a sign of suspicious activity, whether it is performed by external actors or a malicious insider.  

To increase the true positive rate of external actors performing this activity, you can correlate the activity against known MFA’d IP-addresses from your Identity Provider logs.  
‍

Pulling the timeline together

While the above activities and actions can be a strong indicator of suspicious, malicious or compromised GitHub user accounts within your organization. Analysts need to pull the timeline together to tell the story of what happened.  

What and Who? – collect the suspicious source_addresses paired with the GitHub user_names and user_ids associated with the activity. Expand and pivot from those users to other users associated with the source_addresses, as well as other source_addresses associated with the users.  

When? – to determine your window of compromise, analyze the additional activity from these IPs and users. Typically there will be activity that is much more benign to help determine when the compromise began.  

You’ll often find that a compromised laptop or workstation led to this activity, and the actors began interacting with a long lived login session to your version control system software.  
‍

Conclusion

Our technology estates are now composed of a wide range of systems and services including Cloud, SaaS, self-hosted services, and the traditional computers and networks.  This expanded footprint opens threat actors to a larger realm to compromise and operate upon. Our detection and analysis methods need to expand to collect telemetry from these systems and improve our skills to analyze this telemetry.  
‍

Secure with Abstract

Abstract Security provides data integrations to collect the GitLab and GitHub audit logs, paired with filtering and aggregation functions to reduce unnecessary data without compromising your ability to detect, investigate and respond to intrusions. Paired with the ASTRO’s Git detection rules to detect suspicious and malicious activity from insider threats and external actors.  

Applicable ASTRO detection rules

ASTRO provides over 50 GitHub detection rules as Out of the Box content for customers to detect suspicious GitHub activity. This activity can be tuned using contextual information with additional data models to increase true positive rates. The rules most relevant to this post include:

• GitHub PAT Approval Disabled

• GitHub Collaborator Added to Repo

• GitHub Enterprise Add Admin

• GitHub Enterprise Invite Admin

• GitHub Oauth Created

• GitHub Oauth App Approved

• GitHub SSO Disabled

• GitHub SAML disabled in Enterprise Account  

• GitHub MFA disabled in Enterprise Account

• GitHub Mass Repository Retrieval

• GitHub Suspicious Repository Archival Activity  

References:
GitHub, Audit log events for your organization, https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization