Graphic of honeycomb

Honeypots and Honeytokens: Trapping Attackers With Source Code Lures

Published May 22nd, 2023 by John Walsh

Many developers were left wondering which secrets were compromised and what code needed to be updated after attackers breached CircleCI and potentially exposed any source code that was stored there. The popular CI/CD pipeline and DevOps tool was hit by a data breach after a third-party vendor was compromised. This resulted in hackers compromising user data, including usernames and email addresses associated with GitHub and Bitbucket, along with user IP addresses. Those impacted needed to immediately rotate their secrets to mitigate the potential risk of attack.

But think about the secrets you might have embedded in your code – do you know where they all are if this type of attack struck? And how much extra development time would it take you to manually rotate all of those secrets? It’s not just the information that’s exposed in these types of attacks that makes them so damaging – it’s also the extra time and effort it takes your development team to respond after this kind of breach happens.

The best advice to follow when thinking about how to mitigate these types of attacks is to adopt an “assume breach” mindset. By following a Zero Trust approach to security and applying security in layers, you can limit the blast radius of any potential breach. Now more than ever, developers are a critical piece of securing the software supply chain. Your teams are often the first link in the chain and have crucial areas of impact – from the credentials you use in your code to the endpoints your team works on. By working in coordination with your security and operations teams, you can help ensure that your code doesn’t have anything that attackers could exploit if they do find a way in.

But even if you operate under Zero Trust security principles, it can be helpful to understand what vulnerabilities or systems your enemy is targeting and get an early warning about which applications, code repositories and clouds are being targeted or potentially compromised. This can help save developers time if a breach does occur by knowing which repositories or code to prioritize updating first.

That’s what honeypots and honeytokens were designed for. Wouldn’t it be great if we knew ahead of time what source code or repository was compromised to focus your attention on there first to prevent any attacks from escalating?

Trap More Attackers With Honey

In the world of cybersecurity, organizations attempting to protect themselves from attackers often take a defensive stance, engaging in a high-tech cat-and-mouse challenge of finding and catching cyber criminals. Things like honeypots and honeytokens are essentially a trap for an attacker to fall into. A honeypot is a fake system deployed next to your genuine digital assets. It is made to look attractive to an attacker, and when the criminal falls for the bait, not only do they waste their resources on a useless system or fake data, but they also reveal crucial information about the nature of their attack strategy.

On the other hand, honeytokens are more of a way to identify attackers. When an attacker uses a honeytoken, the security team can track these malicious actors, revealing critical information about their identity and the methods they are using to exploit a system.

My first experience with honeypots was with an SSH longtail honeypot project that I contributed to, in which sacrificial SSH servers were set up in an effort to learn more about attackers. It took a bit of time, but once we started getting bites, the volume of attacks began to increase. While it used to take days for one of the honeypots to be attacked, eventually it took only minutes. This speed of attack will only accelerate with AI-powered bots.

When we dug further into the learnings from these honeypots, we had some interesting findings. The attacks came from all over the world, but the majority of them appeared to come from known botnets. We saw a lot of brute-force attempts on passwords and keys. And there was the most important piece: a lot of these passwords the attackers were trying were very simple. Things like “password1,” “change me” and other defaults that were obviously not very secure. Surely people weren’t actually using those passwords, right? But the fact that the attackers were guessing those passwords told us exactly that – this was a method that had worked before with them. They were giving us a sneak peek into weaknesses that they successfully exploited.

And that’s where honeypots and honeytokens can be really powerful: they give you a window into the attacker’s mindset and show you the general vulnerabilities they are trying to exploit.

Revealing Your Weaknesses

Honeypots and honeytokens are a great addition to a Zero Trust software development approach, and the best part is a fairly small lift can have a big impact here. So how can you use these concepts to find specifically which code repositories, clouds or other areas of code are potentially vulnerable?

All you need to do is sprinkle some “lures” into source code on critical systems that you think might be targeted by attackers. For example, you could purposely write code into your applications that “accidentally” exposes a fake admin account like the one below (this would be your honeytoken or deception), with the intention that it will be stolen and used by attackers if your source code is compromised. Then you sit back and wait for attackers to take the bait.

# Don’t push to prod, test only!!!!
password = "SuperSecret"
username = "admin"
def authenticate(username, password):
	if username == username and password == password:
		return True    else:
		return False

Next, you set up a way to monitor the fake admin account and get notified when anyone tries to those fake credentials or honeytokens. This serves as an early warning that something is wrong and that wherever you stored that source code is potentially exposed. This could tell you that attackers are exploiting another vulnerability to gain access to this system, giving you the advantage of knowing where and when to look to help stop breaches before they start. From there, you can shore up your defenses around these weaknesses.

The Canary in the Coal Mine: Privilege Deception

So how do you create these lures and track them? That’s where CyberArk can help, acting as a canary in the coal mine for you. CyberArk Endpoint Privilege Manager (EPM) has a capability called “Privilege Deception” that leverages a credential lure to help you spot where attackers are getting into your systems and enables defenders to quickly detect and proactively shut down in-progress attacks. CyberArk helps break the attack chain at the initial point of entry by providing a deliberate and controlled way.

Think of it like a tripwire. You set up a fake administrative account as a honeypot, and then once the attacker tries to use the account, you’re notified via CyberArk EPM that “credential lure was used.” This tells you that someone is trying to access your servers where the code is sitting or is an internal bad actor is trying to do something they shouldn’t. CyberArk EPM helps you adapt and respond, keeping you one step ahead of attackers as you learn more about your enemy.

Secrets Management + Endpoint Privilege Security = Better Together

Using tripwires like Privilege Deception from CyberArk EPM is a great way to spot your vulnerabilities and protect those further, which can help you guard your source code and spot areas that might be at risk for compromise. But in an assume breach mindset, we should still consider that there are other vulnerabilities that we’re not aware of. That’s where secrets management comes in by securing secrets and credentials used by CI/CD tools like Jenkins, containerization platforms like Kubernetes and other applications and automation scripts.

A hard-coded secret is exactly what led to the 2022 Uber breach. A script stored in a network share had an account that fetched information from the privileged access management (PAM) solution on a schedule. So, when the attackers compromised the network share and found that script, they were able to access the PAM solution and expand the attack surface. By maintaining good secrets management processes, you can ensure that even if an attacker does get in, you’re protected.

By using a centralized secrets manager like CyberArk Conjur Secrets Manager, you can establish strong authentication protocols and easily manage and rotate secrets. Centrally applied policies mean that you can reduce the risk that a hard-coded secret is lurking in your organization somewhere, waiting for an attacker to snatch it up.

In addition to the Privilege Deception capability, CyberArk EPM also helps protect your development team’s endpoints, another key area attackers target. Developers routinely perform high-risk actions, such as running debuggers, connecting to cloud implementations, using, and building and running third-party code. CyberArk EPM helps contain that risk through role-specific least privilege policies, to ensure team members only have the level of privileged access that they need to perform their tasks.

In a nutshell, endpoint privilege security and secrets management tools like those offered by CyberArk create a secure environment for developers. By using CyberArk Secrets Manager and CyberArk EPM together, you can reduce the attack surface and mitigate the impact of a potential attack.

It’s All About Layers

Defensive deception helps establish an active cyber defense posture, so that you can detect attacks before they happen, delay or inconvenience attackers and gather new threat intelligence to prevent similar attacks.

Combining a capability like Privilege Deception with good best practices for endpoint privilege security and secrets management ensures that you have the layers in place to spot weaknesses in your source code and arms your developer team with the proper defenses to build into code. A holistic solution like the CyberArk Identity Security Platform can help you build these layers into your program, all through a single vendor.