When you talk to people in the cybersecurity industry, you’ll hear that incident response is often associated with “good guy” actions you take to means “good guy” actions that you take to stop the “bad guys” from stealing your stuff, whereas “hack-back” is the equivalent of identifying a person who robbed you, following him home and exacting vigilante justice, far exceeding the realm of self-defense.
We think this is because people consider incident response to be limited in time and scope so that it takes place to face an ongoing, identifiable event without persistent actions; and also because we instinctively attach importance to the intent behind the actions, and not necessarily to the consequences. This is a bit odd, because the techniques for detecting, containing, investigating and remediating the damage caused by a computer attack are the same regardless of their location, and they’re not inherently limited in their scope or time of application as one might imagine.
Truth be told, “hack-back” techniques are not inherently different from incident response techniques. Forensic tools run just fine when they’re in your system or the bad guy’s system, even if they’re used for different purposes (reconnaissance for the attacker, or attribution for the defender).
In our view, “hack-back” is a form of extreme incident response – one in which you are not satisfied with remediation, mitigation and forensic gathering with intent of attribution, but one in which you take the next (and rightly forbidden) step of retaliation. Nevertheless, while we agree that vigilante-style action should be avoided, we disagree categorically with the assumption that all attacker-side activity is vigilante activity, and wish to explore the options at our disposal.
With Cymmetria MazeHunter, we’re challenging the concept of hack-back itself. What follows is a short summary of our research into the legal applicability of “hack-back” techniques as part of Incident Response. This post explains what active defense payloads are, how they work, and what kind of legal challenges their use poses for a privately-owned organization.
Read here about MazeHunter, the product we built based on this methodology.
2. What Cymmetria MazeHunter does
MazeHunter is the evolution of a feature we’ve had in MazeRunner, Cymmetria’s cyber deception platform, for some time – collecting forensics from attacker-side computers on your network. Once MazeRunner detects an attacker, it immediately connects back to the attacker-controlled machine in your environment, obtaining their attack toolset (it runs netstat to see which process opened up the connection to the decoy, thus identifying the attackers’ toolset).
With MazeHunter, instead of just pulling forensics, you can run any payload of your choice and engage with a confirmed, live attacker. We do this by relying on the company’s own existing authorizations to allow the deployment of payloads that are custom-designed. This allows us to circumvent a majority of the legal issues arising from the prohibitions on “computer trespass” and “computer damage” (as defined in 18 USC §1030(a)(2) and 18 USC §1030(a)(5)) that accompany activities outside your own network, by limiting all activities to computer you’re fully authorized to operate on.
3. Our framework and policy model for legal hackback
While researching the literature, we discovered that most frameworks discussing “hack-back” consider the issue mainly from a legal standpoint without fully examining the technological or operational considerations it entails. They also group most attacker-side activity under the same “hack- back” category. This grouping under a collective denomination does a disservice to the discussion. A more nuanced approach is to distinguish between several categories by their intended use or “payload”, and by their location in relation to your infrastructure.
In our opinion, you need to ask the following questions in order to determine your course of action.
- What legislative and regulatory constraints do you face?
- What kind of action are you interested in taking?
- Where and when are you planning to deploy your active defense component? Particularly:
- Is the affected computer a part of your infrastructure, or does it belong to a 3rd party? If it belongs to a 3rd party – can you secure their consent to act on or inside their device?
- Who is currently controlling the asset in question?
- Are there any context-specific legal or operational considerations on the deployment of your chosen payload that need to be discussed?
3.1 Determining the Scope and Extent of Applicable Laws
All legal frameworks start with one basic question – “What are the laws and regulation that apply to the situation being discussed?”.
Only within the confines of these limitations are you the master of your domain (for the purposes of this post – your network). Accordingly, while our analysis deals with the applicability of a specific federal law, it leaves open a lot of limitations—both up and downstream—that need to be considered.
3.2 Choosing a Payload
In order to categorize the possible payloads, we refer to the level of aggression of the payload against the attacker, and the likelihood the payload may have an impact on the Confidentiality, Integrity or Availability of information in the system.
Forensic payloads designed to extract information about the attacker’s activities, especially when deployed within the network, are considered benign and passive towards the attacker.
Monitoring payloads, while still generally benign, are more likely to accidentally reveal information to unauthorized personnel (such as PII). “Shoulder surfing” a live attacker is great when you’re trying to locate his infiltration and exfiltration methods, but it imposes additional duties on you to ensure compliance with applicable laws.
Passive Engagement components are components that can detect connections to and from them, and react. They can replace the contents of the files accessed in the decoy with encrypted versions of the same file or corrupted copies of the file, before they are exfiltrated.
Live Engagement payloads are the most aggressive and most damaging components. When deployed, these may disable network connectivity, “brick” a computer or parts thereof (which is different from the passive components in that the damage is caused actively, after the retrieval of files, not before). These are of course not only the most aggressive (and arguably, effective) tools in your arsenal, but also the riskiest.
Most of these payloads are deployable without much difficulty, but the more aggressive you get, the better it is to get your risk management and legal teams involved early.
3.3 Location and Stage of the Attack
We now want to add an additional and important distinction into the discussion, which revolves around the spheres of activity, or rather – the “stages” of defense.
This table addresses two key factors for determining the type of threat you’re facing: it’s not just about determining where the attacker is coming from and what tool they’re using; it’s about knowing what your limitations are with regards to the location where the attack is taking place, as the CFAA deals with the question of authorization to act within a specific computer.
If you can pinpoint the location of the attacker within your network, you can extrapolate from that the extent of your authority over that location, and that, in turn, governs the extent of your response options within the limits of the law.
The vast majority of problems that are intertwined with the concept of “hacking back” stem from the fact operating outside of your own network requires you to essentially “plunge into darkness”, without knowing if your reactive measures will affect your attacker, or an innocent intermediate system or even without knowing where that system may be located or what jurisdiction you are currently operating in. This inherent uncertainty brings into question the legal validity of a defensive system designed to perform activities outside your own network. Accordingly, we’ve decided to solve some of these problems by proposing to apply active defense systems on a limited “geographical” perimeter and we refer only to activity that occurs within your own, fully-controlled network. Through our research, we concluded that in most cases, defensive activity against positively-identified attackers inside a fully-controlled network, by attackers that are operating from computers inside a company-controlled perimeter, which does not exceed the limits of said network, is permissible under the CFAA.
Our framework therefore seeks to empower defenders with new possibilities to engage their attackers in a manner which is not only compliant with our interpretation of the law, but also which is effective in increasing their cyber-security. Whereas engagement with a live attacker within your network can at the very least prevent the success of their attack, retaliatory action or “hot pursuit” outside your network against unknown parties achieves neither of these results, and should not be pursued.
3.4 Context-Specific Considerations on the Deployment of Specific Payloads (Legal and Operational considerations)
Once you have decided to engage the attacker and determined the appropriate type of response, you need to revert back to your constraints and take into account two types of considerations: legal limitations on the use of the components (the exact same payload may be prohibited for use by a bank but permitted by a manufacturing plant due to specific industry regulation); and operational aspects of the same.
In the broadest of terms, we expect defenders to asks two major operational questions – “What are the objectives of this defense?” and “What are the desired effects of this deployment?” If your operational objective is to avoid engagement with the attacker, you may choose to deploy either forensic or monitoring payloads. If your objective is to engage directly, you may choose either an active or passive engagement component. The determination is also made in terms of the effectiveness of the measure: even if you want to engage an attacker quickly and directly by disabling the network connectivity of each and every compromised endpoint, it may be unwise to do so when the attack you’re trying to deflect is coming from multiple attack vectors.
The relationship between these two operational parameters is what dictates what payloads are suited for each situation just as much as the legal constraints dictate the types of payloads that can or cannot be used. If the defender’s objective is to prevent further attacks and the desired effect is to achieve deterrence, it is up to each deterrence to determine which payloads best serve the combined goals, given the limitations of the law.
If a conclusion is to be reached from the discussion listed above, it is this one: The determination of which payload is suited for each purpose is not only a legal concern, but also an operational one.
We advise practitioners wishing to design active defense campaigns to first determine the applicable law as it applies to them, and once the applicability of the law has been clearly defined, defenders must define the objectives of their defense, incorporate into their defensive strategy the applicable legal limitations, and then design a deployment campaign which takes into account the desired effects of the defense.
We welcome your feedback, questions, and comments. Please feel free to reach out to us.
Not yet a customer? Ask us for a demo today.