In our modern, digital-centric era, an unprecedented amount of sensitive data is stored and transmitted online. This reality underscores the fact that even the smallest error can have costly consequences, particularly for businesses. Often, these companies underestimate the vulnerability of their private resources —those not directly exposed to the Internet—to potential cyber-attacks.

Leaks of sensitive information, including Personal Identifiable Information (PII) or programmatic credentials (secrets), can provide cyber attackers with a significant entry point into internal systems. Once inside, these attackers can broaden their assault, ultimately gaining access to highly sensitive areas. This scenario underscores the crucial need for robust data security measures.

To illustrate this concept, we have created and simulated a hypothetical situation involving a cyber attack. This attack originates from a minor oversight, such as the unintentional inclusion of sensitive data in a Git commit.

We’ll guide you through the attacker’s process, step by step. The scenario will follow a trail from secret recovery to the compromise of environments isolated from the Internet, at the heart of a company’s infrastructure.

By understanding the “kill chain” (the sequence of steps taken by the attacker) organizations can develop appropriate defenses and countermeasures at each stage to detect, prevent, or mitigate these kinds of cyberattacks.

Quick introduction: The Lab

Enterprise Network

For our demonstration, we will model a realistic target environment for the cyber attack.

The environment embodies a traditional, internet-oriented, enterprise network architecture, typically featuring multiple zones utilized for various functions:

• LANs for the employees’ workstations
• Servers for the development environments
• Datacenter with the Active Directory
• DMZ with services such as DNS, NTP, or mail relay
• Guest Wi-Fi network
• Cloud services, including GitHub repositories.

The company’s network structure is arranged around two routers, RE and RI, each of which is encircled by a firewall, respectively FE and FI.

For our demonstration, we will focus on the LANs and Servers areas, which are organized as follows:

In our scenario, LAN 1 is dedicated to Human Resources, Marketing, Sales, and Direction, while LAN 2 is dedicated to developers’ workstations.

On the server side, three development environments are represented:

• Development, which can only be accessed by LAN 2
• Q&A, which can only be accessed by LAN 2
• Pre-Production, which can be accessed by LAN 1 and LAN 2

Keeping separate environments enhances security measures, facilitating better flow monitoring and providing a robust shield against potential attacks.

However, with the company’s accelerated growth, a strategic decision has been made to permit unrestricted traffic flow between the Development, Q&A, and Pre-Production areas. This simplifies the growth of these environments without requiring too much effort, but it also creates a vulnerability.

Lab Setup

Before diving into the kill chain, let’s quickly talk about how our hacking lab is set up. The scenario we have chosen for our attacker requires four areas:

• Pre-Production
• Development
• LAN 1
• Internet

To prevent any mistakes, we are hosting the attacker’s command and control server inside a simulated internet area. But when it comes to the leaked secret, we are considering a real public-facing GitHub repository.

Following our specification, we can sum up the needed architecture as follows:

In this setup, we’ve streamlined the system by removing all unused networks. You might have noticed that both the Development and Pre-Production environments belong to the same /17 subnet. While this could potentially complicate traffic monitoring, it’s not a concern for our specific situation. In our context, Development and Pre-Production freely communicate without any restrictions, making this implementation good enough.

What’s important to accurately mirror our target infrastructure, is to adjust our firewall settings to prevent LAN 1 from accessing the Development network.

The Scenario: It All Starts From a Leak💧

The scenario starts with the discovery of a public Git repository hosted on GitHub. This is a screenshot of the commit history for this public repository:

In one of the commits, a comment indicates that some SSH keys were removed. Additionally, the .ssh/ directory was added to the .gitignore file to prevent it from being inadvertently published to GitHub.

Details of the commit d531cf8 are particularly interesting: we can see that both the public and private SSH keys were removed from the repository, therefore leaking through the repository history:

The scenario we’re about to delve into isn’t as far-fetched as you might think: GitGuardian’s annual State of Secrets Sprawl reported a staggering 10 million secrets—ranging from private keys and API keys to credentials—unintentionally laid bare on GitHub in 2022.

Moreover, secrets that are readily identifiable, such as RSA private keys, can be compromised in mere seconds (see p. 21 of the report). Secrets left over in Git history are a startling reality that underscores the urgent need for robust data security measures, such as implementing secrets detection, remediation, and prevention at an industrial scale.

See MITRE: T1593.003 Reconnaissance | Search Open Websites/Domains | Code Repositories

The Kill Chain

1. Reconnaissance

In the scenario we’re exploring, the attacker has already identified a leaked SSH key — a critical reconnaissance step that has set off a sequence of events often referred to as a “killchain”. The attacker must also gather a list of valid email addresses from the targeted company to successfully initiate a phishing campaign.

However, our emphasis here isn’t on the reconnaissance techniques. Instead, we’re focusing on the subsequent exploitation sequences. So for the sake of our discussion, let’s assume that the attacker has deducted valid email addresses from the leaked SSH key or the committer email.

MITRE: T1589.002 Reconnaissance | Gather Victim Identity Information | Email Addresses

2. Initial Access & Execution

When creating the phishing campaign, the attacker uses a weaponized Microsoft Excel document, embedding malicious code that will be used to get the initial foothold on the targeted infrastructure.

MITRE T1566.001 Initial Access | Phishing | Spearphishing Attachment

This file contains malicious VBA code that will execute when the user decides to enable macros by clicking on the “Activate Content” button.

T1204.002 Execution | User Execution | Malicious File

This technique might not work anymore due to the evolution of Microsoft policies and antivirus software, but the concept of phishing using documents that look legitimate remains the same.

The VBA code contains a Meterpreter stager.

3. Command & Control

When the user enables the macros in the malicious Excel file, the stager downloads the Meterpreter implant and executes it on the host: a connection is made back to the command-and-control server at 149.22.84.66 on port 443, using TCP and RC4 encryption.

MITRE T1095 Command & Control | Non-Application Layer Protocol

4. Persistence

The attacker then needs to migrate the process in order to avoid the session from terminating if the user who opened the malicious Excel file closes it.

MITRE T1055 Persistence | Process Injection

5. Collection

The attacker then monitors the user’s activity on the host in order to gain valuable information. Here, we have a screenshot showing the capture of an IP address and credentials of user “eric” by monitoring the information copied to the clipboard.

MITRE T1115 Collection | Clipboard

6. Lateral Movement

The goal for the attacker now is to gain access to this new target in order to move laterally and extend the attack to other machines on the network.

The following screenshot shows the output of the Metasploit module “autoroute,” which allows to route the traffic to different networks by using the compromised host as a proxy or pivot point.

In this case, the subnet of the compromised host is 192.168.0.0/17, and the target network for lateral movement is 192.168.128.0/17.

By using a SOCKS proxy through a Metasploit module, the attacker can send the traffic of attacking tools through the session of the compromised host. The following screenshot shows the output of the Metasploit module “proxy_socks” configured with the following parameters:

With these new routes and the SOCKS proxy server, the attacker can now leverage Proxychains to gain access to the first targeted server via SSH, using “eric” credentials that were previously captured.

MITRE T1090.003 Command and Control | Proxy: Internal Proxy

After scanning the compromised server, the attacker can determine that it now has access to other parts of the 192.168.128.0/17 subnet that were restricted from the first compromised host’s subnet. Among these new addresses, 192.168.128.10 corresponds to a server that can be accessed using the leaked SSH key.

To do so, the attacker first uploads the stolen SSH key to the compromised server:

Then, they leverage the SSH key and Proxychains to establish an SSH tunnel to the second server:

The attacker is now bypassing network and security policies and can log in as “john” with the compromised SSH private key into the second server.

In the end, the tunnel goes from the attacker’s machine to the first compromised workstation through the TCP tunnel, and then to the final server through the first compromised server.

7. Privilege Escalation

After compromising the final target, the attacker uploads linpeas.sh, a vulnerability scanning script, on the host in order to gain higher privileges. Since user “john” is an unprivileged user without root/sudo access, the attacker is looking to escalate privileges.

The following screenshot is part of the output of the script execution, which shows a vulnerability in the Linux kernel that can be used for local privilege escalation.

See MITRE T1078.003 Privilege Escalation | Exploitation for Privilege Escalation

We can see that the host is vulnerable to CVE-2021-4034 , also known as Pwnkit.

The attacker can use the SSH tunnel to upload the Pwnkit exploit to the compromised server and execute it to gain root privileges.

With root access to the development server, the attacker is now able to access any information hosted on the development server, modify the source code of different projects, and introduce backdoors and vulnerabilities.

Depending on the attacker’s motives, this attack could result in the complete leakage of private source codes, credentials, or any other sensitive information. Additionally, the attack could last longer if the intruder manages to acquire additional credentials. This could help them spread further into the network, launch a large-scale data breach, or initiate a devastating ransomware campaign.

Final Words

This cyber attack scenario highlights the vital role of robust cybersecurity practices at every tier. Basic education is the first line of defense in mitigating the threat of attacks, especially those originating from phishing emails. Learning how to stay safe is beneficial for all, not just those immersed in the cybersecurity field.

For tech-savvy professionals like software engineers, data scientists, and system administrators, it’s paramount to comprehend the impact of leaking sensitive information, such as secrets, even inadvertently. This awareness can significantly influence the organization’s overall security stance. It serves as a critical link in the IT security chain, holding equal importance to secure network management, sound architectural design, and safeguarding the software development lifecycle to thwart potential breaches.

In the scenario we presented, an infrastructure secret leaked silently through a sloppy commit on a public GitHub repository. In order to prevent this incident and ensure that no code containing a secret can be inadvertently made into a commit, the best solution is to install **ggshield** locally and use it as a pre-commit hook. For even more security, it is also recommended to install GitGuardian’s GitHub App to be alerted if ever a secret is exposed in one of our repositories.

Keeping secrets safe is an effective way to make it harder for attackers to access important networks, systems, and data.

Additionally, you can also use honeytokens. They are powerful tools in the cybersecurity toolkit, notifying you of any unauthorized activities in code repos, Jira, Slack, Linear, and more. Honeytokens use decoy credentials to detect when someone is attempting to compromise a system. This technology can be tested for free directly in the GitGuardian platform.

Implementing innovative practices and monitoring can make our companies safer from cyber attacks.