Ghost in the machine: machine identities and invisible risk

Summary:

• Non-human threat actors use systems which are always in operation and are long-lived or never expire
• Organisations can protect against these attackers by keeping thorough logs of who and what logs in and out of their systems and keeping an inventory of valid credentials with expiry dates
• The increasing adoption of AI agents as normal means organisations must be cognizant of this attack surface to protect against threats
• Machine access should be 'limited, monitored and necessary' as human access is

According to Entro Security, computer identities outnumber humans by over 100 to 1. This number is rapidly rising every year, but much effort focuses on human attackers. We use security controls to protect our systems — password policies, security training, systems monitoring and more. They aim to catch a malicious person, intent on doing harm. But what about machines?

With a growing non-human population comes a growing threat, and a potential oversight in many organisations. Machine credentials such as API tokens and service accounts are often used by systems that are always in operation, so are long-lived or perhaps never expire! This makes their compromise devastating. They are often given wide access to execute their function, but aren’t monitored, meaning we can overlook their compromise.

How are secrets exposed?

In 2020, the ICO fined British Airways £20 million for a data breach which was triggered by credentials shared with a third party. An attacker gained access to their networks, stealing personal and payment information from customers. This attack lasted around 3 months, simply reusing an existing credential that didn’t expire.

In 2023, CircleCI, a popular developer tool, found that malware deployed on an engineer's laptop had been used to hijack a valid session cookie. The attacker was able to steal a number of customer secrets, including environment variables, private keys, and access tokens. These could’ve granted access to customer systems. In this case, CircleCI worked quickly to mitigate the impact, but these secrets could’ve proved devastatingly valuable to would-be attackers.

Often secrets are exposed through everyday development accidents. According to Entro, over 50% of exposed secrets come from source code. Developers accidently leak secrets by hard-coding them in public code repositories. With many open source projects being under-resourced, and often maintained by only one person, the risk of their publishing credentials being exposed presents a major supply-chain threat.

For you

Be part of something bigger, join BCS, The Chartered Institute for IT.

How can we keep data safe?

Start with an inventory of what has access. Plugins, SaaS, CI/CD, automations — if something logs in, log it! When first creating credentials take a few minutes to explore the scope of access being granted. It’s always easier to add permissions later than take them away.

Monitoring secrets is extremely helpful. Ideally you can do this with automated tooling, but in a smaller organisation you may be able to simply record issued credentials and their expiry as part of your inventory (naturally, don’t record the secrets themselves!). Automated tools can rotate secrets for you, taking the hassle out of manual updates. But again, this can become part of monthly inventory reviews. Rotating secrets often mitigates the damage that longer-lived credentials could cause if stolen.

Small improvements, such as storing credentials like SSH keys in password managers rather than in clear text, can be helpful. Modern operating systems often have built-in disk encryption. Use it to reduce the chance of a stolen developer’s laptop leading to the keys to the kingdom going missing.

In our changing world, where adoption of AI agents will lead to more machine access, it’s critical that individuals and organisations consider this attack surface. The recent Moltbook breach reportedly exposed large volumes of API tokens, potentially providing remote access to connected machines. We are just beginning to imagine the damage these fully autonomous agents could do in the hands of an attacker.

Machine access should be limited, monitored and necessary. Treat them like administrator accounts, as they often are. You know your employees. Do you know what else is connecting to your systems?