There are thousands of files in WikiLeaks' dump of data from the Central Intelligence Agency's Engineering Development Group (EDG). This organization within the CIA's Center for Cyber Intelligence is responsible for creating the tools used to hack into digital devices around the world in support of the CIA's mission. The leaked documents come from an Atlassian Confluence server used by the EDG's developers to track and document their projects.

Many of the documents in the dump are unclassified—manuals provided by Lockheed Martin and other vendors, for example. Most are classified at the Secret level, including things as innocuous as a guide to getting started with Microsoft Visual Studio, apparently the preferred development tool of the EDG's Applied Engineering Department (AED). There's also a smattering of meme construction components and animated GIFs of the anime series Trigun.

But a tiny fraction of the data is highly classified, according to document marks. This cache sits at the Top Secret level, and it's marked as "Special Intelligence" (SI) and "NOFORN" (no foreign distribution). Out of the first batch of just over 1,000 documents, there are two paragraphs marked at that level. And those pieces describe minutiae of how the CIA's Network Operations Division wants the cryptographic features of its tools to work and how the CIA obtains and prepares phones for use in its exploit lab.

So for the most part, the damage done by the documents isn't what they expose about the CIA's hacking and network espionage capabilities. Instead, the problem is the extent to which these leaked documents reveal the technical specifications, practices, and other details of the CIA's internal hacking tool development teams. Now, anyone accessing the documents can know how the EDG used elements taken from malware found in the wild to build their own and what the CIA defines as the "dos and don'ts" for developing attack and espionage tools. In other words, much of the tradecraft of the CIA's internal hacking teams has been pulled from their collaboration server.

However, much of that tradecraft looks like Malware 101 upon inspection. In fact, some of the comments left by CIA developers in 2013 pointed out how dated the practices were. Many of these techniques do not qualify as secret.

To demonstrate this, we've annotated some excerpts from the AED developers' malware-writing wisdom. A good deal of these tips might apply to anyone writing a security-focused application. Much of the best practices focused on anti-forensics—making it more difficult for the adversary's information security teams to detect and decipher exactly what was going on with malware. And some of the chestnuts on overall coding practices include:

I. Don't leave a calling card

AED's developers were warned against doing things in developing tools that would make it easier for an adversary to figure out where the tool, implant, or malware they developed had come from.

"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)." Such artifacts have frequently been used by analysts as part of the process of attributing malware to Russian authors, for example.

AED developers were told to use UTC time for all time-dependent operations in code as well. This ensures that they performed consistently and didn't give up any particular time zone bias.

"DO strip all debug symbol information, manifests [left by Microsoft Visual C++], build paths, [and] developer usernames from the final build of a binary." Those sorts of things could be used in attribution as well. For similar reasons, the document exhorts developers to 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."

Then there's the basic operational security admonition: "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."

There's an additional warning about another item not to include in tools—bad language. "DO NOT have 'dirty words' in the binary. Dirty words, such as hacker terms, may cause unwarranted scrutiny of the binary file in question."

II. Don't break the target's computer

AED developers were next warned against rookie mistakes that would make it easier to reverse-engineer tools. The first rule of Malware Club was not to make the target's device unusable, therefore drawing unwanted attention to the malware's presence.

"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.," the document warns.

"DO NOT perform Disk I/O operations that will cause the system to become unresponsive to the user or alerting to a System Administrator." The last thing you want is for someone to look in a system monitor and see something called Notepad.exe consuming all of a system's CPU, network, and disk I/O cycles.

"DO have a configurable maximum size limit and/or output file count for writing… output files." This prevents collection jobs by a tool from filling up the disk storage of the target, for example. That occurrence would likely cause a support visit that could expose the tool's presence.

In a similar vein, the document commands, "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." Error codes work both ways: they can be useful in forensics as well as debugging. AED's developers are directed to force their code to crash during testing to verify that it won't give itself up.

Enlarge/ These guidelines are up to date like this IBM System/370 mainframe computer.

f8 Imaging/Hulton Archive/Getty Images)

III. Use some encryption, dude

Another part of keeping a low profile is encrypting data used by the tool—in memory, on disk, and over the network. One of the documents linked included the following guidelines:

"DO obfuscate or encrypt all strings and configuration data that directly relate to tool functionality," because somebody looking at a configuration file or an executable in a text editor or hex editor should not be able to figure out what your tool is doing and where it is sending things just from text embedded in the code. The document calls on AED developers to write code that only decrypts information as it's needed and to immediately remove the unencrypted data from memory as soon as it's not needed. "DO NOT RELY ON THE OPERATING SYSTEM TO DO THIS UPON TERMINATION OF EXECUTION."

"DO NOT write plain-text collection data to disk," because that could get awkward fast. "DO encrypt all data written to disk," and "DO utilize a secure erase [overwriting the file with zeros at least once] when removing a file from disk." That way, there's nothing left in the trash can to retrieve.

"DO use end-to-end encryption for all network communications"—because passive collection of unencrypted data leaving the network would ruin the operation's day.

Use standard Internet protocols for "blending" communications with the rest of the target's network traffic—not some custom protocol trying to fake its way through as something else. Bad protocols will show up as broken traffic in a network monitor like Wireshark, which would will draw attention.

"DO NOT solely rely on SSL/TLS to secure data in transit"—because SSL proxies might be able to man-in-the-middle the network session and decrypt it. This is a lesson that even some secure messaging applications have learned the hard way.

"DO use variable size and timing (aka jitter) of beacons/network communications. DO NOT predicatively send packets with a fixed size and timing. DO proper cleanup of network connections. DO NOT leave around stale network connections." In short, varying the size and time of communications back to a command and control server will make the packets you send over the network less of an announcement of your tool's presence.

IV. Don't make the job of the adversary's forensics team any easier

A lazy espionage tool coder is an unsuccessful espionage tool coder. The "DOs and DON'Ts" guide calls out a number of coding hygiene rules aimed at preventing sloppiness from exposing CIA operations:

"DO strip all debugging output...from the final build of a tool"—because there's nothing like leaving a little instrumentation behind to help someone else figure out what the tool is for.

"DO NOT explicitly import/call functions that is not consistent with a tool's overt functionality." In other words, if you're disguising an implant as notepad.exe, don't have it call Windows processes that notepad.exe wouldn't call—it'll raise suspicion and make it easier for someone to figure out what your tool is really doing through static analysis.

"DO NOT export sensitive function names; if having exports are required for the binary, utilize an ordinal or a benign function name." Because having a line of code like "__declspec( dllimport ) void DoVeryBadThings()" might draw the attention of an analyst.

"DO NOT read, write and/or cache data to disk unnecessarily." Writing too much to disk makes the forensic footprint of a tool more obvious.

Keep it small: "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."

"DO NOT allow network traffic, such as C2 packets, to be re-playable." That means communications between the tool and the command and control server running it should be time-and-date sensitive so that the adversary can't record the traffic and send it back at the tool in an attempt to reverse-engineer what it's doing.

V. Test against antivirus products FTW

One of the categories of things to do or avoid in the CIA document refers to "PSP/AV products." PSP is an acronym for "personal security products"—one previously referenced in the NSA tools exposed by the Shadowbrokers dump.

Part of the AED's development cycle, according to the documents in the leak, involves extensive testing in a virtualized environment called DART. That system was built by Lockheed Martin, based on VMware instances and some automated deployment and testing software. But this environment may not be ideal for totally testing tools developed by AED, particularly when it comes to checking for how well they avoid detection by anti-malware products.

That means developers need to configure tests against real-world products—and not just ones they can download for free. "DO NOT assume a 'free' PSP product is the same as a 'retail' copy," the best-practices document warns. "Test on all SKUs where possible."

Additionally, that testing has to happen with recently updated anti-virus systems to be reliable, since vendors regularly ship new data down to clients. "DO test PSPs with live (or recently live) Internet connection where possible," the document recommends. However, it also warns, "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."

In other words, testing against a tool with too live a connection to the Internet could result in the details of the tool being tested getting uploaded to the vendor's threat library—and potentially then being shared to a threat intelligence platform like VirusTotal. That could render a tool dead on arrival if it isn't carefully developed.

Content expired

It's not clear how closely tool developers at the CIA followed the tradecraft advice in the leaked document—in part because they realized how dated some of the advice was. Back in 2013, two users of the system said so in the comments area: "A lot of the basic tradecraft suggestions on that page seem flawed," wrote one. Another followed, "Honestly, that stuff is probably already dated." There's no indication of how recently any of the recommendations were updated.

Four years later, some of the recommendations have become even more stale. That's largely because of the advances made in malware detection and security tools, including those built into many operating systems. But it's also because the tradecraft used by everyday malware authors without the benefit of state sponsorship have surpassed these sorts of tradecraft suggestions. Of course, whether with the CIA or otherwise, there's no guarantee everyone out there has their security tradecraft up to date.