From vulnerability to advantage: turn exposed secrets into your best allies to detect intrusion.

Yesterday, we announced the release of our latest open-source project, ggcanary, during our monthly community webinar. ggcanary, or the GitGuardian Canary Tokens, is an intrusion detection system using AWS credentials as honey tokens.

In their continued adoption of the cloud and modern development practices, organizations are (unknowingly) expanding their attack surface – and attackers are taking notice. In place of poorly secured internet-facing assets and corporate networks, attackers are increasingly turning to components in the software supply chain like Source Control Management (SCM) systems, Continuous Integration and Continuous Deployment (CI/CD) pipelines, and software artifact registries as entry points.

Given the complexity of the modern software factory and the sprawling of DevOps tools, detecting compromise poses many challenges and is often achieved too late. By deliberately exposing AWS credentials with ggcanary, we believe security and detection engineering teams can increase their odds of catching intrusion in this corner of their organization.

Why and how should you use ggcanary?

Our analyses of recent breaches have shown that, after gaining initial access, attackers often search for valid hardcoded credentials they can use for further lateral movement. With ggcanary, defenders can turn the table on attackers, making them victims of their own tactics and luring them into revealing themselves by tripping over AWS secret keys.

We built ggcanary with one goal in mind, we wanted it to be the easiest solution for security teams to create and manage AWS honey tokens on a large scale. Here's how we're making this happen:

• The project is based on a Terraform configuration file, to automate the provisioning and management of AWS honey tokens.
• It leverages AWS CloudTrail audit logs to offer highly-sensitive intrusion detection, tracking all types of actions performed on the honey tokens.
• It scales up to 5,000 active AWS honey tokens for their deployment on the internal perimeter of an organization, in source-code repositories, CI/CD tools, ticketing, and messaging systems such as Jira, Slack, or Microsoft teams.
• It ships with an alerting system that supports AWS Simple Email Service (SES), Slack, and SendGrid out-of-the-box! This can also be extended with a generic webhook to forward alerts to SIEMs or ITSMs.

🔎 The internals of ggcanary 🔎

Let's take a closer look at the different parts that make up ggcanary and understand how they work together.

1. Terraform backend: the user needs to define a set of variables in the terraform.tfvars file like the AWS profile and region to which it should deploy the project. This file also contains the parameters required to create the alerting service using AWS SES, SendGrid, or Slack. The user should also define an object in the ggcanaries.auto.tfvars file containing the AWS users (5,000 max) ggcanary will create before generating a secret key for each.
2. AWS CloudTrail: When an AWS honey token is tampered with, AWS CloudTrail logs the attempt and saves it to an S3 bucket. In turn, this triggers a call to a lambda function.
3. AWS Lambda: When triggered, the serverless function will parse the log file in the S3 bucket, filter for activity on the canary tokens, and send an alert if applicable.

Visit the GitHub repo if you want to dive deeper into the code.

The story behind ggcanary

Developers and security engineers familiar with GitGuardian and our solutions already know how close the topic of hardcoded secrets is to our hearts. Our initiatives in this space run towards a simple goal: educate developer communities about the vulnerability, the threat it poses, and the best practices to beat secrets sprawl.

And we're not the only ones in this fight! Over the years, our vision and ideas found echoes from a variety of industry experts and peers. In a long-awaited update of its Top 10 Web Application Security Risks, OWASP ranked hardcoded secrets #2 last year – under the Cryptographic Failures (A02:2021) entry. This year, the vulnerability also gained a spot on the MITRE CWE Top 25 Most Dangerous Software Weaknesses and now ranks 15th. Last, NIST included scanning source code for embedded secrets in its Recommended Minimum Standards for Vendor or Developer Verification (Testing) of Software under Executive Order 14028.

Until now, our focus has been on reducing the risks of secrets exposure in the software development lifecycle with our automated secrets detection and remediation platform, GitGuardian Internal Monitoring. Our approach has helped thousands of organizations harden the Source Control Management systems they rely on to build and ship software. With ggcanary however, we wanted to explore a different use of hardcoded secrets; to the advantage of the defenders this time.

When we started dabbling with the idea of honey tokens, we came across many popular free or open-source projects such as SpaceSiren, Canarytokens by Thinkst Canary, and SPACECRAB by Atlassian. These projects deeply inspired us, and through this release, we wanted to recognize the impact they have had on the development of intrusion detection systems and the extent to which they popularized deception techniques in the field of cybersecurity.

Take ggcanary for a spin

To get started with ggcanary, all you need is an AWS account! It's free and open-source. Visit the official GitHub repository and follow the instructions in the README to create your first AWS honey tokens.