Incident Response: Pay a Ransom, Go to Jail

Companies that find their files, data or networks locked by a malicious actor demanding an extortion payment now have a new worry in their incident response: The U.S. Department of Treasury. On Oct. 1, the Treasury Department’s Office of Foreign Asset Control (OFAC) issued an advisory warning companies affected by ransomware that paying ransom could lead to sanctions from the government.

The advisory notes that the problem of ransomware and ransomware demands is serious and growing. It is being promoted by governments, non governmental entities, organized criminal groups and dedicated cyberthreat actors. Because paying ransom in cybersecurity cases necessarily involves giving money to these threat actors, the government posits that the ransom payer may be providing material support to hackers in violation of various U.S. and international sanctions regimes, and that this opens the ransom payer to civil, administrative and criminal penalties.

The Office of Foreign Asset Control is generally responsible for enforcing various U.S. and international financial sanctions regimes, including those against specific countries (e.g., Cuba and North Korea), persons (specially designated nationals such as certain Russian oligarchs and others) and specific programs. Some of these sanctions regimes were specifically authorized by acts of Congress, some through international organizations such as the United Nations, and some implemented by Executive Order of the President. Typically, such sanctions prohibit certain financial transactions with the prohibited entity and require entities to check the list of prohibited countries and entities prior to engaging in financial transactions. In fact, the federal Know Your Customer (KYC) and Anti Money Laundering (AML) rules and regulations are part of the implementation strategy with respect to sanctions regimes. For example, under the International Emergency Economic Powers Act (IEEPA), the White House prohibited any “transactions” with both Tik Tok’s parent company and with WeChat, and similarly has imposed sanctions on various foreign companies and even hacker groups. The same is true under the Trading with the Enemy Act (TWEA).

As a result, the Treasury and State Departments have issued specific cyber-related sanctions against entities responsible for particular cyber attacks. In addition, in 2015 and again in 2016, the Obama administration issued executive orders authorizing sanctions against “individuals and entities determined to be responsible for or complicit in malicious cyber-enabled activities that result in enumerated harms that are reasonably likely to result in, or have materially contributed to, a significant threat to the national security, foreign policy, or economic health or financial stability of the United States.” The December 2016 sanctions were aimed specifically at sanctioning those responsible for the cyberattacks and disinformation campaigns aimed at the 2016 election.

The Ransomware Problem

When it comes to ransomware or other similar internet-based problems such as extortionware, doxxing, revenge porn or other forms of internet threats, the threat actor typically demands money in cryptocurrency in return for releasing blocked files, folders or networks, or not releasing stolen information, trade secrets or embarrassing facts learned about a company.
In each of these cases, the company is faced with a choice: pay the ransom or not pay the ransom and suffer the consequences. While there are many legal issues associated with paying the ransom, either directly through an insurance company or through a third party, one of the problems with paying any money in cryptocurrency to an unnamed and unknown entity is that it may run afoul of the OFAC regulations. Because the sanctions prohibit transactions with certain entities, including those responsible for certain cyberattacks, by paying a cryptocurrency ransom to an unknown entity a company inadvertently may be engaging in a financial transaction with a prohibited entity. This opens the company paying the ransom to allegations of violations of the sanctions regime and potential civil and criminal penalties for doing so.

Moreover, by paying the ransom, a company may also be exposing itself to civil and criminal liability for aiding and abetting the hacker’s enterprise or providing material support to the criminal enterprise that has attempted to extort money from them. While some entities have a flat policy never to pay ransom, this results in situations such as those that occurred with the cities of Atlanta and Baltimore, in which the refusal to pay modest ransoms (a few thousand dollars) resulted in the cities’ networks being shut for weeks and tens of millions of dollars of damage and disruption.

The WhoIs Problem

The OFAC regulations and the sanctions regimes prohibit the knowing engagement in financial transactions with a prohibited entity—but the “knowing” aspect applies to the act of engaging in a financial transaction, NOT the knowledge that the entity is a sanctioned entity. While the law requires financial institutions to check the sanctions list before engaging in any financial transaction, the mere fact that it has done so does not insulate it from liability if, after the fact, OFAC finds that a prohibited transaction has occurred. While the Treasury Department’s Enforcement Guidelines take into account the good faith efforts of an entity to prevent a prohibited transaction, the sanctions regimes impose strict liability on those that violate them. Also, prior to engaging in a transaction with a prohibited entity, a company could apply to OFAC for a license to engage in the transaction—essentially permission to pay the ransom at issue. But to obtain such a license, the company paying the ransom would have to identify the entity to which it is proposing to make the payment as well as the sanctions regime from which it seeks relief, and must obtain the license prior to making the payment. With ransomware, the victim rarely knows the identity of the perpetrator and has to act within hours or days, not the weeks or months usually necessary to obtain a license from the government.

Moreover, if a ransomware victim seeks an OFAC license and is denied, then it has made it even more difficult for it to pay the ransom if it determines that this is the best course of action.

Practical Advice

So, what should a company facing a ransomware or extortion demand in cyberspace do to minimize its risk of violating OFAC and other sanctions regimes?

First, it is important to get competent legal advice from counsel knowledgeable about both cybersecurity, data privacy, incident response, sanctions regimes and data forensics. This is not only to simply help navigate the shoals of incident response but also to enable the response to be protected by a presumptive privilege associated with the legal advice. The privilege is not absolute and is not a panacea, and does not protect the company from later liability if it violates the law (including sanctions regimes), but it provides some greater freedom to explore and investigate.

Second, it is important to collect data and thoroughly investigate both the data-locking (ransomware) and the demands in a forensically acceptable manner. If the victim has an effective data forensics capability, then it should be invoked. If not, the company should immediately retain outside advisers with experience in data forensics, incident response and threat intelligence—the latter being essential to attempt to make attribution for the threat actor. Remember, the OFAC advisory relates to paying money (ransom) to entities that are on a list of prohibited entities. Part of your incident response is to make at least a good-faith effort to determine whether the threat actor you have decided to pay is on the list. Collecting data such as log data, firewall data, router data, IP and DNS data and even data about the malware itself—its behavior, origin and level of sophistication—can help determine whether the threat actor is or is not “on the list.” Various companies can also be helpful to act as an intermediary in paying a ransom, and have sophisticated tools and techniques for tracing cryptocurrency payments or using escrow agents to ensure that the money is only transferred once the unlock keys or codes are validated (“Throw me the idol and I’ll throw you the whip.”).

Third, check the sanctions list,  particularly the cyber-related sanctions. If you have any reason to believe that the entity you are proposing to pay is or might be on the sanctions list (by IP address, nature of the entity, location, etc.), then you may wish to at least inform OFAC, law enforcement or others prior to making the payment. Remember, the sanctions are strict liability, but the enforcement guidelines rely on your good-faith actions.

Fourth, obtain appropriate cyber insurance now. In doing so, it is important to know what insurance you are buying and what it covers. Most policies cover “data breach” and breach recovery, which is inadequate to protect you from cyber extortion and regulatory costs. A comprehensive risk assessment is essential to measure your risk, and select the appropriate behaviors and insurance to mitigate it.

Fifth, consider working with the appropriate law enforcement agencies. Law enforcement is ambivalent about whether it is “legal” to pay a ransom, with the official FBI policy being that companies should not pay a ransom but it won’t generally prosecute entities for doing so. There’s little comfort in that policy, but the OFAC advisory and its enforcement guidelines note:

Under OFAC’s Enforcement Guidelines, OFAC will also consider a company’s self-initiated, timely, and complete report of a ransomware attack to law enforcement to be a significant mitigating factor in determining an appropriate enforcement outcome if the situation is later determined to have a sanctions nexus. OFAC will also consider a company’s full and timely cooperation with law enforcement both during and after a ransomware attack to be a significant mitigating factor when evaluating a possible enforcement outcome.

Of course, such self-reporting will impact the company’s ability to assert privilege and have other impacts on the investigation, so it is important not just to work appropriately with law enforcement, but to work with the appropriate law enforcement entities. This means having a relationship with federal, state and local enforcement agencies (or knowing entities with such relationships) long before there is an incident so you can establish trust and rules of engagement for incidents in the future. Since the threat actors are often operating beyond borders, you may need to enlist the support of counsel, investigators or law enforcement agencies abroad as well.

Fifth, explore options that don’t involve ransom payments. As noted, in the Atlanta and Baltimore cases, and in cases involving mission-critical or time-critical data, paying the ransom may be the cheapest, easiest and fastest way to restore your operations. But there are alternatives. Aside from having an effective anti-phishing and anti-malware program to reduce the risk of ransomware, companies should have a robust disaster recovery/business continuation planning (DR/BCP) capability including frequent and well-planned backups of data and programs, data recovery functionality and relationships with vendors and suppliers that will permit rebuilding and restoration of operations. In addition, some ransomware software packages may be unlocked without the key by highly sophisticated computer security procedures known to a few computer security researchers and some can be “brute-forced.” In short, there are options.

There is an adage in computer incident response that there’s no “good” way to respond to an incident—your job is to pick the least bad one. The Treasury Department has raised the stakes by threatening prosecution of computer crime victims. That’s only one of many legal issues associated with response to and payment of funds in ransomware cases. It’s important to take reasonable and measured steps to ensure that you comply with these regulations even during trying times.

Avatar photo

Mark Rasch

Mark Rasch is a lawyer and computer security and privacy expert in Bethesda, Maryland. where he helps develop strategy and messaging for the Information Security team. Rasch’s career spans more than 35 years of corporate and government cybersecurity, computer privacy, regulatory compliance, computer forensics and incident response. He is trained as a lawyer and was the Chief Security Evangelist for Verizon Enterprise Solutions (VES). He is recognized author of numerous security- and privacy-related articles. Prior to joining Verizon, he taught courses in cybersecurity, law, policy and technology at various colleges and Universities including the University of Maryland, George Mason University, Georgetown University, and the American University School of law and was active with the American Bar Association’s Privacy and Cybersecurity Committees and the Computers, Freedom and Privacy Conference. Rasch had worked as cyberlaw editor for SecurityCurrent.com, as Chief Privacy Officer for SAIC, and as Director or Managing Director at various information security consulting companies, including CSC, FTI Consulting, Solutionary, Predictive Systems, and Global Integrity Corp. Earlier in his career, Rasch was with the U.S. Department of Justice where he led the department’s efforts to investigate and prosecute cyber and high-technology crime, starting the computer crime unit within the Criminal Division’s Fraud Section, efforts which eventually led to the creation of the Computer Crime and Intellectual Property Section of the Criminal Division. He was responsible for various high-profile computer crime prosecutions, including Kevin Mitnick, Kevin Poulsen and Robert Tappan Morris. Prior to joining Verizon, Mark was a frequent commentator in the media on issues related to information security, appearing on BBC, CBC, Fox News, CNN, NBC News, ABC News, the New York Times, the Wall Street Journal and many other outlets.

mark has 222 posts and counting.See all posts by mark