Technical Measures for Signaling
By Dave Aitel
September 2021
Introduction
One of the major issues with applying signaling, norms, deterrence theory and other aspects of previous international relations efforts to the cyber domain has been the consistent issues around determining intent and boundaries. Futile efforts have been made to determine entire industrial sectors as “critical” and therefore off limits, but predictably in a domain defined by connectivity, these efforts have failed. Even defining a “CERT” as a critical response function is useless when many national CERTs are essentially dual use.
However, there are several proposals to reduce ambiguity in the cyber domain that have been discussed in private forums, but rarely made it out for public attention to the wider cyber policy community. These schemas attempt to leverage intrinsic aspects of the cyber domain as opposed to being stymied by them, without assuming an adversary can control all cyber activity happening within its borders or even using its offensive capabilities.
Currently, these less publicized technology-based measures include the following:
On-target tokens
Offensive toolkit tokens
Auditable implants
Each of these schemas at some level tries to reduce the uncertainty in intent and identity that is inherent in offensive and defensive actions in cyberspace. Ideally, these mechanisms can be used at scale and at network speed, as opposed to relying on human-to-human conversations, which may be too cumbersome, slow, or ineffective due to lack of trust. None of these mechanisms provide a level of definitive “proof” - they are essentially probabilistic in nature.
On-Target Tokens
On-target tokens are placed on a machine or in a dataset by defenders. They inform potential intruders about defensive intentions and limits. The aim of on-target tokens is to reduce ambiguity about how a certain machine or dataset is perceived by the defenders when an attacker who is party to the scheme has obtained access to it, while not providing information to other parties.
Ambiguity in how a defender views a system or dataset (email box for example) can be dangerous in the sense that an offensive team may intrude on a network it does not know a lot about, and then even through surveillance or port-scanning have unintended adverse effects on that network that cause an escalatory reponse.
Like any token scheme, this one requires sharing a public key and setting up a PKI. Some communication may be involved as a prerequisite to allow offensive teams to know the format and locations of possible tokens.
One example version of this kind of schema is “We will base64 encode an XML document, which will be in the LSASS as a User Logon Name, with a random password. The XML document will have a signed blob with the MAC address of the machine and a date. This Base64 string will also be in the hosts.txt file and as a filename in a directory in the root partition only visible to the SYSTEM user.” In some senses these placements are similar in nature to those used by honeytokens.
Concerns about this mechanism include:
Limiting the number of available tokens
Alerting adversaries and helping them target sensitive machines or data
Ensuring and knowing that tokens are retrieved by the offensive team
To address these concerns, we can further define what a token consists of, and where they are placed. Offensive teams have many different sets of what is called in the industry “Tools, Tactics, and Procedures” (TTPs) and studying these over time allows you to tune your placement of tokens to where a particular offensive team would naturally retrieve them as part of their normal operations.
In addition to placing tokens where they are likely to be retrieved, a target-based token scheme requires the offensive team to understand and trust in the forensics capabilities of the defenders. This can be buttressed by public reports from incident response firms or even law enforcement, stating the behaviors they have retrieved from offensive operations on that, or similar, targets.
A sample scenario using target tokens could be as follows:
A defensive team utilizes one of their tokens and places it on a machine central to election tabulation, in the LSASS process as a username
An offensive team penetrates that machine, as part of their typical operations behavior, and uses Mimikatz to retrieve all usernames and passwords stored in the LSASS
For every username that is longer than 100 characters, they send it to an API hosted by a government agency, along with a few other pieces of information (date/time, and MAC address of the machines, which they have also retrieved). This API returns a code, which is indicative of a “please leave this server alone” and also sends back a “return-token”
On their next connection to the election tabulation machine, the offensive team places a response-token on the system, and then removes their implant before disconnecting.
The incident response team, much later, reviews system logs and notices both the intrusion and the implant removal. Their analysis ties this activity to a particular nation-state actor.
Target tokens can represent either a “red-line - please do not meddle with this box as it controls life support functions” or contain as a norm encoded within them, the idea that “yes, we understand you will have penetrated this mailbox or machine, but if you leak that data to the public we will consider that a red line that has been crossed, and act accordingly.” In this sense they are not an enforcement mechanism, so much as a confidence building measure, communication, and signaling tool.
Each common concern around Target Tokens will be addressed in the below sections.
Token Limits
A common question around target tokens is whether they will be over-used. Why not put one of these tokens everywhere? There’s no right answer for how many tokens would be ideal for establishing confidence building measures, and one could envision scenarios where a bilateral agreement would distribute many tokens to one side, and few to another (i.e. between the US and North Korea, which has few computers and networks available to protect).
However, it’s likely that any realistic scenario between participants in the scheme will end up using a symmetric solution where both sides have the same number of tokens. Let’s say each side gets 100 tokens per year to distribute. How does each side determine which tokens are valid and which are not?
A simple scheme for this would be that when you placed a token, you included a signed hash (aka, an HMAC) of that token in shared, but private, space. Because tokens would include something host-specific (or mailbox specific, etc.) this would prevent token reuse. Other solutions require pre-signing a number of hashes, each with a unique identifier, and sharing valid identifiers with the bilateral party. Re-use of the same token runs the risk of being seen twice in two places by an offensive team (which would indicate misuse of the scheme).
The technical limits on these sorts of schemes involve fitting tokens into small spaces, as often the fields you want to put them in are not large (104 characters, for the LSASS example). Should this constraint be removed, more complicated methods for establishing limits can be created, with space for timestamps and other metadata to be encrypted and included into the token.
Tokens as an Adversary Alert
A common concern is that seeing a token would have an opposite effect upon an offensive team. Rather than letting it know it should “Draw Down”, it would attract attention and incentivise the offensive team to pay more attention. This would be a disincentive to apply tokens to networks where sensitive data or connections resided. Several counter-measures exist to prevent this effect:
Places where these tokens are placed are likely to be obviously sensitive, not ambiguously sensitive
Chaff tokens are easy to create which are impossible for someone not party to the scheme to tell apart from real signed tokens
Token Effectiveness
No scheme of this nature is effective unless the offensive teams understand that their behavior will be potentially instrumented and attributed. This is a matter of maturity when it comes to a country’s incident response and threat analytics, and also on the side of offensive methodology. Even though many countries prescribe to the theory that attribution is somewhat impossible due to the use of proxies, a long history of indictments and national name-and-shame campaigns points to a growing understanding that this is not typically the case.
While these sorts of schemas do not provide a behavioral guarantee, they do offer opportunities for each side to demonstrate due care and send confidence building signals that can be received clearly.
Steganography
While public discourse and advancement of steganography has largely been halted for decades, it would be possible to deploy a shared photo-steganographic library that hid enough data for tokens of this nature. Protected by a cryptographic key, it is possible to make it so without that key a third party would not be able to definitively say an image had hidden data in it or not.
Offensive Toolkit Tokens
These cryptographically secured tokens are placed within various pieces of a country’s offensive toolkit (implants, exploits, etc.). They evidence a particular intent. Like any token scheme, they require a PKI of some kind (although this can be a quite simple one).
Concerns with these schemas generally include:
False-flag issues (toolkits being reused by non-original actors)
Attribution issues
These tokens get placed where an incident responder would be likely to find them, but in an obfuscated way such that it would be required to perform manual analysis in order to decode them. This avoids the possibility of someone scanning their entire network traffic to detect them as a signature.
False Flag
Toolkits can get stolen from the wire or implanted hosts, or even incident response reports. This makes anything embedded in those toolkits something that will be copied as well. The ideal solution to this for a token embedded within an offensive toolkit would be something that is generated at runtime using an API under centralized control.
In other words, if your exploit sends “Http-user-agentx: <encrypted data>” and that data is generated at runtime by an API, it can be tagged and encrypted using a public key with information specific to the target, the date, and other information that could not be copied by someone stealing that exploit and reusing it.
It’s likely that someone not party to the offensive toolkit token scheme might not even recognize that these tokens were being used - and might remove them when they re-use the toolkit because they are extraneous to the effect of the tool. Some minor effort to make them look like shellcode or other normal exploit data would probably convince any bystander that they were left in an exploit as a mistake.
When placed on disk, in an implant, offensive toolkit tokens can be keyed to that host, which would make re-use of that token obvious.
And for both kinds of tokens, attaching a date nonce to them makes it so replay is more obvious.
Attribution
No country will use a toolkit that completely erases their ability to avoid attribution from a legal perspective. On the other hand, being able to “wear a uniform” in the cyber domain is of great utility in many cases. Having a larger group of members who all share the scheme (aka, making it not purely bilateral) dilutes the effect of any attribution issues, from a legal perspective.
In other words, I may not be able to prove which particular country placed an implant on a particular host, but I can say they are in the group of countries that ascribes to our norms, based on the tokens they have used.
Auditable Implants
While some implants are general-purpose, other implants can be placed in sensitive locations and serve a single use case. A recent example of this is the SUNSPOT implant, which was placed on a SolarWinds build machine to update new versions of SolarWinds Orion with attacker-enabled code. Another example could be the recent attack on the Iranian train system.
The goals of an auditable implant are to accomplish a limited mission, while at the same time communicating that limitation to defenders when it gets discovered, avoiding escalation. They are extremely useful when being placed in areas that otherwise would run the risk of being considered an act of war or a threat of armed action.
Some common features with auditable implants is that they are not updatable (aka, they are not designed to be modular). They store logs of their activities (usually disguised as “debug logs left in by mistake by the developer”) in an encrypted form, but with the key stored in the implant itself, as opposed to using a public-key system that would prevent defenders from reading the logs. The logs are timestamped, to allow a level of correlation with known activities, and build trust in the logs themselves.
Some of the common issues with auditable implants involve communication that an implant is designed to limit harm, as opposed to simply being the result of benign incompetence. In most cases, this is difficult to know without outside analysis or even confirmation from an adversarial government or offensive group! Advertising that an offensive team uses this methodology goes a long way towards allowing it to ease tensions as it is meant to.
However, there is a growing international consensus and understanding around the value in these techniques that is reaching up to policy circles and informing a wider public.
Conclusion
The past twenty years of diplomatic efforts with regards to bringing stability in Cyberspace has been hindered by a reliance on models imported from negotiations on conventional and nuclear arms control. We attempt in this paper to both illustrate efforts to leapfrog those techniques that are already happening, but also to collect a set of techniques into a single bucket so proper analysis can be done on their effectiveness and the future opportunities they present when it comes to confidence building measures and the larger goals diplomatic efforts are striving for.