Entries Tagged "tradecraft"

Page 1 of 4

FBI Had the REvil Decryption Key

The Washington Post reports that the FBI had a decryption key for the REvil ransomware, but didn’t pass it along to victims because it would have disrupted an ongoing operation.

The key was obtained through access to the servers of the Russia-based criminal gang behind the July attack. Deploying it immediately could have helped the victims, including schools and hospitals, avoid what analysts estimate was millions of dollars in recovery costs.

But the FBI held on to the key, with the agreement of other agencies, in part because it was planning to carry out an operation to disrupt the hackers, a group known as REvil, and the bureau did not want to tip them off. Also, a government assessment found the harm was not as severe as initially feared.

Fighting ransomware is filled with security trade-offs. This is one I had not previously considered.

Another news story.

Posted on September 22, 2021 at 9:30 AM • View Comments

Story of Gus Weiss

This is a long and fascinating article about Gus Weiss, who masterminded a long campaign to feed technical disinformation to the Soviet Union, which may or may not have caused a massive pipeline explosion somewhere in Siberia in the 1980s, if in fact there even was a massive pipeline explosion somewhere in Siberia in the 1980s.

Lots of information about the origins of US export controls laws and sabotage operations.

Posted on March 27, 2020 at 6:03 AM • View Comments

The CIA's "Development Tradecraft DOs and DON'Ts"

Useful best practices for malware writers, courtesy of the CIA. Seems like a lot of good advice.

General:

  • DO obfuscate or encrypt all strings and configuration data that directly relate to tool functionality. Consideration should be made to also only de-obfuscating strings in-memory at the moment the data is needed. When a previously de-obfuscated value is no longer needed, it should be wiped from memory.

    Rationale: String data and/or configuration data is very useful to analysts and reverse-engineers.

  • DO NOT decrypt or de-obfuscate all string data or configuration data immediately upon execution.

    Rationale: Raises the difficulty for automated dynamic analysis of the binary to find sensitive data.

  • DO explicitly remove sensitive data (encryption keys, raw collection data, shellcode, uploaded modules, etc) from memory as soon as the data is no longer needed in plain-text form. DO NOT RELY ON THE OPERATING SYSTEM TO DO THIS UPON TERMINATION OF EXECUTION.

    Rationale: Raises the difficulty for incident response and forensics review.

  • DO utilize a deployment-time unique key for obfuscation/de-obfuscation of sensitive strings and configuration data.

    Rationale: Raises the difficulty of analysis of multiple deployments of the same tool.

  • DO strip all debug symbol information, manifests(MSVC artifact), build paths, developer usernames from the final build of a binary.

    Rationale: Raises the difficulty for analysis and reverse-engineering, and removes artifacts used for attribution/origination.

  • DO strip all debugging output (e.g. calls to printf(), OutputDebugString(), etc) from the final build of a tool.

    Rationale: Raises the difficulty for analysis and reverse-engineering.

  • DO NOT explicitly import/call functions that is not consistent with a tool’s overt functionality (i.e. WriteProcessMemory, VirtualAlloc, CreateRemoteThread, etc – for binary that is supposed to be a notepad replacement).

    Rationale: Lowers potential scrutiny of binary and slightly raises the difficulty for static analysis and reverse-engineering.

  • DO NOT export sensitive function names; if having exports are required for the binary, utilize an ordinal or a benign function name.

    Rationale: Raises the difficulty for analysis and reverse-engineering.

  • DO NOT generate crashdump files, coredump files, “Blue” screens, Dr Watson or other dialog pop-ups and/or other artifacts in the event of a program crash. DO attempt to force a program crash during unit testing in order to properly verify this.

    Rationale: Avoids suspicion by the end user and system admins, and raises the difficulty for incident response and reverse-engineering.

  • DO NOT perform operations that will cause the target computer to be unresponsive to the user (e.g. CPU spikes, screen flashes, screen “freezing”, etc).

    Rationale: Avoids unwanted attention from the user or system administrator to tool’s existence and behavior.

  • DO make all reasonable efforts to minimize binary file size for all binaries that will be uploaded to a remote target (without the use of packers or compression). Ideal binary file sizes should be under 150KB for a fully featured tool.

    Rationale: Shortens overall “time on air” not only to get the tool on target, but to time to execute functionality and clean-up.

  • DO provide a means to completely “uninstall”/”remove” implants, function hooks, injected threads, dropped files, registry keys, services, forked processes, etc whenever possible. Explicitly document (even if the documentation is “There is no uninstall for this “) the procedures, permissions required and side effects of removal.

    Rationale: Avoids unwanted data left on target. Also, proper documentation allows operators to make better operational risk assessment and fully understand the implications of using a tool or specific feature of a tool.

  • DO NOT leave dates/times such as compile timestamps, linker timestamps, build times, access times, etc. that correlate to general US core working hours (i.e. 8am-6pm Eastern time)

    Rationale: Avoids direct correlation to origination in the United States.

  • DO NOT leave data in a binary file that demonstrates CIA, USG, or its witting partner companies involvement in the creation or use of the binary/tool.

    Rationale: Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USG operations and equities.

  • DO NOT have data that contains CIA and USG cover terms, compartments, operation code names or other CIA and USG specific terminology in the binary.

    Rationale: Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USG operations and equities.

  • DO NOT have “dirty words” (see dirty word list – TBD) in the binary.

    Rationale: Dirty words, such as hacker terms, may cause unwarranted scrutiny of the binary file in question.

Networking:

  • DO use end-to-end encryption for all network communications. NEVER use networking protocols which break the end-to-end principle with respect to encryption of payloads.

    Rationale: Stifles network traffic analysis and avoids exposing operational/collection data.

  • DO NOT solely rely on SSL/TLS to secure data in transit.

    Rationale: Numerous man-in-middle attack vectors and publicly disclosed flaws in the protocol.

  • DO NOT allow network traffic, such as C2 packets, to be re-playable.

    Rationale: Protects the integrity of operational equities.

  • DO use ITEF RFC compliant network protocols as a blending layer. The actual data, which must be encrypted in transit across the network, should be tunneled through a well known and standardized protocol (e.g. HTTPS)

    Rationale: Custom protocols can stand-out to network analysts and IDS filters.

  • DO NOT break compliance of an RFC protocol that is being used as a blending layer. (i.e. Wireshark should not flag the traffic as being broken or mangled)

    Rationale: Broken network protocols can easily stand-out in IDS filters and network analysis.

  • DO use variable size and timing (aka jitter) of beacons/network communications. DO NOT predicatively send packets with a fixed size and timing.

    Rationale: Raises the difficulty of network analysis and correlation of network activity.

  • DO proper cleanup of network connections. DO NOT leave around stale network connections.

    Rationale: Raises the difficulty of network analysis and incident response.

Disk I/O:

  • DO explicitly document the “disk forensic footprint” that could be potentially created by various features of a binary/tool on a remote target.

    Rationale: Enables better operational risk assessments with knowledge of potential file system forensic artifacts.

  • DO NOT read, write and/or cache data to disk unnecessarily. Be cognizant of 3rd party code that may implicitly write/cache data to disk.

    Rationale: Lowers potential for forensic artifacts and potential signatures.

  • DO NOT write plain-text collection data to disk.

    Rationale: Raises difficulty of incident response and forensic analysis.

  • DO encrypt all data written to disk.

    Rationale: Disguises intent of file (collection, sensitive code, etc) and raises difficulty of forensic analysis and incident response.

  • DO utilize a secure erase when removing a file from disk that wipes at a minimum the file’s filename, datetime stamps (create, modify and access) and its content. (Note: The definition of “secure erase” varies from filesystem to filesystem, but at least a single pass of zeros of the data should be performed. The emphasis here is on removing all filesystem artifacts that could be useful during forensic analysis)

    Rationale: Raises difficulty of incident response and forensic analysis.

  • DO NOT perform Disk I/O operations that will cause the system to become unresponsive to the user or alerting to a System Administrator.

    Rationale: Avoids unwanted attention from the user or system administrator to tool’s existence and behavior.

  • DO NOT use a “magic header/footer” for encrypted files written to disk. All encrypted files should be completely opaque data files.

    Rationale: Avoids signature of custom file format’s magic values.

  • DO NOT use hard-coded filenames or filepaths when writing files to disk. This must be configurable at deployment time by the operator.

    Rationale: Allows operator to choose the proper filename that fits with in the operational target.

  • DO have a configurable maximum size limit and/or output file count for writing encrypted output files.

    Rationale: Avoids situations where a collection task can get out of control and fills the target’s disk; which will draw unwanted attention to the tool and/or the operation.

Dates/Time:

  • DO use GMT/UTC/Zulu as the time zone when comparing date/time.

    Rationale: Provides consistent behavior and helps ensure “triggers/beacons/etc” fire when expected.

  • DO NOT use US-centric timestamp formats such as MM-DD-YYYY. YYYYMMDD is generally preferred.

    Rationale: Maintains consistency across tools, and avoids associations with the United States.

PSP/AV:

  • DO NOT assume a “free” PSP product is the same as a “retail” copy. Test on all SKUs where possible.

    Rationale: While the PSP/AV product may come from the same vendor and appear to have the same features despite having different SKUs, they are not. Test on all SKUs where possible.

  • DO test PSPs with live (or recently live) internet connection where possible. NOTE: This can be a risk vs gain balance that requires careful consideration and should not be haphazardly done with in-development software. It is well known that PSP/AV products with a live internet connection can and do upload samples software based varying criteria.

    Rationale: PSP/AV products exhibit significant differences in behavior and detection when connected to the internet vise not.

Encryption: NOD publishes a Cryptography standard: “NOD Cryptographic Requirements v1.1 TOP SECRET.pdf“. Besides the guidance provided here, the requirements in that document should also be met.

The crypto requirements are complex and interesting. I’ll save commenting on them for another post.

News article.

Posted on March 13, 2017 at 12:00 PM • View Comments

NSA Using Cyberattack for Defense

These days, it’s rare that we learn something new from the Snowden documents. But Ben Buchanan found something interesting. The NSA penetrates enemy networks in order to enhance our defensive capabilities.

The data the NSA collected by penetrating BYZANTINE CANDOR’s networks had concrete forward-looking defensive value. It included information on the adversary’s “future targets,” including “bios of senior White House officials, [cleared defense contractor] employees, [United States government] employees” and more. It also included access to the “source code and [the] new tools” the Chinese used to conduct operations. The computers penetrated by the NSA also revealed information about the exploits in use. In effect, the intelligence gained from the operation, once given to network defenders and fed into automated systems, was enough to guide and enhance the United States’ defensive efforts.

This case alludes to important themes in network defense. It shows the persistence of talented adversaries, the creativity of clever defenders, the challenge of getting actionable intelligence on the threat, and the need for network architecture and defenders capable of acting on that information. But it also highlights an important point that is too often overlooked: not every intrusion is in service of offensive aims. There are genuinely defensive reasons for a nation to launch intrusions against another nation’s networks.

[…]

Other Snowden files show what the NSA can do when it gathers this data, describing an interrelated and complex set of United States programs to collect intelligence and use it to better protect its networks. The NSA’s internal documents call this “foreign intelligence in support of dynamic defense.” The gathered information can “tip” malicious code the NSA has placed on servers and computers around the world. Based on this tip, one of the NSA’s nodes can act on the information, “inject[ing a] response onto the Internet towards [the] target.” There are a variety of responses that the NSA can inject, including resetting connections, delivering malicious code, and redirecting internet traffic.

Similarly, if the NSA can learn about the adversary’s “tools and tradecraft” early enough, it can develop and deploy “tailored countermeasures” to blunt the intended effect. The NSA can then try to discern the intent of the adversary and use its countermeasure to mitigate the attempted intrusion. The signals intelligence agency feeds information about the incoming threat to an automated system deployed on networks that the NSA protects. This system has a number of capabilities, including blocking the incoming traffic outright, sending unexpected responses back to the adversary, slowing the traffic down, and “permitting the activity to appear [to the adversary] to complete without disclosing that it did not reach [or] affect the intended target.”

These defensive capabilities appear to be actively in use by the United States against a wide range of threats. NSA documents indicate that the agency uses the system to block twenty-eight major categories of threats as of 2011. This includes action against significant adversaries, such as China, as well as against non-state actors. Documents provide a number of success stories. These include the thwarting of a BYZANTINE HADES intrusion attempt that targeted four high-ranking American military leaders, including the Chief of Naval Operations and the Chairman of the Joint Chiefs of Staff; the NSA’s network defenders saw the attempt coming and successfully prevented any negative effects. The files also include examples of successful defense against Anonymous and against several other code-named entities.

I recommend Buchanan’s book: The Cybersecurity Dilemma: Hacking, Trust and Fear Between Nations.

Posted on February 22, 2017 at 6:21 AM • View Comments

El Chapo's Opsec

I’ve already written about Sean Penn’s opsec while communicating with El Chapo. Here’s the technique of mirroring, explained:

El chapo then switched to a complex system of using BBM (Blackberry’s Instant Messaging) and Proxies. The way it worked was if you needed to contact The Boss, you would send a BBM text to an intermediary (who would spend his days at a public place with Wi-Fi) this intermediary (or “mirror”) would then transcribe the text to an I-Pad and then send that over a Wi-Fi network (not cellular networks which were monitored constantly by law enforcement). This WiFi text was then sent to another cut-out who would finally transcribe the message into a Blackberry BBM text and transmit it to Guzman. Although Guzman continued to use his Blackberry, it was almost impossible to analyze the traffic because it now only communicated with one other device. This “mirror” system is difficult to crack because the intermediaries or proxies, can constantly change their location by moving to new WiFi spots.

This article claims he was caught because of a large food order:

After construction was complete, the safehouse was quiet. Until 7 January 2016, when a car arrives carrying unknown passengers. Security forces suspected that this was Guzman. There was one final indicator that someone important enough to require an entourage was inside. A white van went off, at midnight, to fetch enough tacos to feed a large group of people. The police raided the house 4 hours later.

Here’s more detail about El Chapo’s opsec at the time of his previous capture.

EDITED TO ADD (2/11): More on his opsec.

Posted on January 21, 2016 at 6:19 AM • View Comments

Sean Penn's Opsec

This article talks about the opsec used by Sean Penn surrounding his meeting with El Chapo.

Security experts say there aren’t enough public details to fully analyze Penn’s operational security (opsec). But they described the paragraph above as “incomprehensible” and “gibberish.” Let’s try to break it down:

  • Penn describes using “TracPhones,” by which he likely means TracFones, which are cheap phones that take calling cards so they’re not linked to a credit card or account. They’re often called burners, but you don’t actually throw it in the trash after a call; instead you might swap out the SIM card or use different calling cards for different people. Hollywood loves these! Katie Holmes reportedly used one to plan her divorce from Tom Cruise. They’re a reasonable security measure, but it still creates phone records that live with, and can be requested from, cell phone carriers.
  • Penn says he “mirror[ed] through Blackphones,” which are relatively expensive phones sold by Silent Circle that offer a more secure operating system than a typical off-the-shelf phone. It runs Internet through a VPN (to shield the user’s IP address and encrypt their Web traffic) and end-to-end encrypts calls and messages sent to other Blackphones. Unlike with the TracFone, Penn would have a credit card tied to the account on this phone. It’s unclear what Penn means when he says he “mirrored” through the phone; the phrase “mirrored” typically means to duplicate something. As he wrote it, it sounds like he duplicated messages on the secure Blackphone that were being sent some other, potentially less secure, way, which would be dumb, if true. “I’m not sure what he means.” said Silent Circle CEO Mike Janke via email. “It’s a strange term and most likely he doesn’t know what he is saying.”
  • Penn says he used “anonymous” email addresses and that he and his companions accessed messages left as drafts in a shared email account. That likely means the emails were stored unencrypted, a bad security practice. If he were sharing the account with a person using an IP address that was the target of an investigation, i.e. any IP address associated with El Chapo’s crew, then all messages shared this way would be monitored. For the record, that did not work out very well for former CIA director David Petraeus, who used draft messages to communicate with his mistress and got busted when her IP address was targeted in an online harassment investigation.
  • Elsewhere in the article, Penn says Guzman corresponded with Mexican actress Kate del Castillo via BBMs (Blackberry messages). Those only have unique end-to-end encryption if a user has opted for BBM Protected. Law enforcement has been able to intercept BBMs in the past. And Mexican officials have told the media that they were monitoring del Castillo for months, following a meeting she had last summer with El Chapo’s lawyers, before she had reached out to Penn. Law enforcement even reportedly got photos of Penn’s arrival at the airport in Mexico.
  • In the most impressive operational, if not personal, security on display, Sean Penn says that when he traveled to Mexico, he left all of his electronics in Los Angeles, knowing that El Chapo’s crew would force him to leave them behind.

There has been lots of speculation about whether this was enough, or whether Mexican officials tracked El Chapo down because of his meeting with Penn.

Posted on January 14, 2016 at 6:32 AM • View Comments

NSA Classification ECI = Exceptionally Controlled Information

ECI is a classification above Top Secret. It’s for things that are so sensitive they’re basically not written down, like the names of companies whose cryptography has been deliberately weakened by the NSA, or the names of agents who have infiltrated foreign IT companies.

As part of the Intercept story on the NSA’s using agents to infiltrate foreign companies and networks, it published a list of ECI compartments. It’s just a list of code names and three-letter abbreviations, along with the group inside the NSA that is responsible for them. The descriptions of what they all mean would never be in a computer file, so it’s only of value to those of us who like code names.

This designation is why there have been no documents in the Snowden archive listing specific company names. They’re all referred to by these ECI code names.

EDITED TO ADD (11/10): Another compilation of NSA’s organizational structure.

Posted on October 16, 2014 at 6:22 AM • View Comments

FOXACID Operations Manual

A few days ago, I saw this tweet: “Just a reminder that it is now *a full year* since Schneier cited it, and the FOXACID ops manual remains unpublished.” It’s true.

The citation is this:

According to a top-secret operational procedures manual provided by Edward Snowden, an exploit named Validator might be the default, but the NSA has a variety of options. The documentation mentions United Rake, Peddle Cheap, Packet Wrench, and Beach Head-­all delivered from a FOXACID subsystem called Ferret Cannon.

Back when I broke the QUANTUM and FOXACID programs, I talked with the Guardian editors about publishing the manual. In the end, we decided not to, because the information in it wasn’t useful to understanding the story. It’s been a year since I’ve seen it, but I remember it being just what I called it: an operation procedures manual. It talked about what to type into which screens, and how to deal with error conditions. It didn’t talk about capabilities, either technical or operational. I found it interesting, but it was hard to argue that it was necessary in order to understand the story.

It will probably never be published. I lost access to the Snowden documents soon after writing that essay—Greenwald broke with the Guardian, and I have never been invited back by the Intercept—and there’s no one looking at the documents with an eye to writing about the NSA’s technical capabilities and how to securely design systems to protect against government surveillance. Even though we now know that the same capabilities are being used by other governments and cyber criminals, there’s much more interest in stories with political ramifications.

Posted on October 15, 2014 at 6:29 AM • View Comments

Eavesdropping by Visual Vibrations

Researchers are able to recover sound through soundproof glass by recording the vibrations of a plastic bag.

Researchers at MIT, Microsoft, and Adobe have developed an algorithm that can reconstruct an audio signal by analyzing minute vibrations of objects depicted in video. In one set of experiments, they were able to recover intelligible speech from the vibrations of a potato-chip bag photographed from 15 feet away through soundproof glass.

In other experiments, they extracted useful audio signals from videos of aluminum foil, the surface of a glass of water, and even the leaves of a potted plant.

This isn’t a new idea. I remember military security policies requiring people to close the window blinds to prevent someone from shining a laser on the window and recovering the sound from the vibrations. But both the camera and processing technologies are getting better.

News story.

Posted on August 8, 2014 at 11:50 AM • View Comments

1 2 3 4

Sidebar photo of Bruce Schneier by Joe MacInnis.