interpretation of nsa's perspective on apt organization

Posted by lipsius at 2020-03-12

00x0 Preface

Recently, CRYSYS lab and ukatemi jointly released a safety report. Based on NSA data leaked by shadow brokers, researchers found the NSA team, codenamed "territorial dispute" (tedi). This report shows that NSA will detect traces of other apt organizations on the attack target while conducting the invasion operation, so as to avoid multiple hacker organizations fighting with each other on the same attack target and minimize the risk of NSA operation leakage. In addition, analysts also found other information in the leaked data, which further revealed the internal risk control behavior of NSA. I have translated the safety report and shared the main parts with you. Due to my own level, there are inevitably many defects. Welcome to point out.

00x1 report structure

Main contents of 00x2 Report

I. Introduction

This report is based on some specific data leaked by "shadow broker". The unknown group, which calls itself the shadow broker, has leaked information that they stole data from NSA several times. See Wikipedia ('shadow'brokers).

There are some interesting modules in the fifth disclosure, which are called "territorial disputes". The leaked data is generally believed to be stolen from NSA, so we map the source to NSA. Although we have no evidence for this, we will not discuss the possible attribution further.

This time, the leaked data is not a single toolset, and there are at least two different toolsets in the leaked data with partial duplication. However, the goal is clear. These tools are used by operators to scan the attacked computers (NSA targets) to check whether the targets have been hacked by external hackers (targeted attack organizations with national background). If an external attack is detected, the operator will be asked to pay special attention (in some related cases, the wording is "please back" or request the superior's advice).

There are dozens of different tools and modules, most of which are used to infect computers, retrieve data and other similar behaviors. But some of them are designed to acquire the general knowledge of the attacked computer, especially the installed software, security software and malware.

Although in other parts of the leaked data, the attacker (NSA) is looking for signs of traditional cyber criminal software (malware) attacks, the "territorial dispute" part is the most interesting. We believe that they have the same goal: to avoid the fight between hacker organizations and minimize the risk of detection of attacks by government organizations. However, our focus on apt detection information will help us understand all this, and what NSA knows about targeted attack organizations of foreign governments.


These tools and scripts that NSA uses to discover other third-party hacking organizations (government roles) on target computers are very simple. They check for the presence of specific files, Windows registry entries, and other tags, which can indicate the presence of external attackers (targeted, country background hackers) on real computers. These inspections are considered IOC in the security community, i.e. violation indicators.

For an apt attack, we can usually define dozens or hundreds of IOC, but NSA tools usually only contain a few IOC, about 1-5, which is very strange. Why do they trust information from such a closed set of indicators rather than expand it through multiple experiments? Generally speaking, if we find a malware and look for similar malware, we will try to define 5-10 or even more different features and signatures to detect similar attacks. Then, the features will be fixed. If 6 of 10 features are found in the sample, the search tool should only mark those important parts. It can also represent the characteristics of an infected computer: a single registry key or a single file with a name (such as IPFilter. DLL). It may not be a good idea to detect based on such characteristics. However, as we mentioned, "territorial disputes" test a very limited number of IOC.

An unimportant explanation is that while they may have more information and ideas for testing, they use this process to give operators as little information as possible. Operators of leaking tools can check the source code, so they can check the internal IOC. Therefore, operators have the opportunity to find clues about the attack. But once operators can find out that sig8 is an attack on Iran's nuclear program, who should inform them to keep it secret? This is a good idea to avoid this kind of situation: limit the available information and reduce the number of IOC in the tool as much as possible. However, there is a question here. If NSA may also be involved in geoviruses, why are geoviruses listed as external attacks (if these sigs only represent directed attacks from external sources)? It is possible that the seismovirus is so hidden that only a few people in NSA know about it, and they really mistakenly classify their own attacks as external hacker organizations, which leads to the fact that the seismovirus is part of the attack list of external organizations.

The discovered naming rules also reflect this fact. All of these tests are called sigx, where X represents 1-45. Operators should not know the name of the operation. They should handle the situation according to the plan.

As mentioned before, "detection engine", i.e. IOC scanning tool, is very simple. They only look for a few indicators and find that it is not impossible for them to infect some external enemies, but they cannot detect other intruders. It's a very strange decision, but maybe within the organization they've done a risk analysis and shown that there's a risk that external organizations can steal, use or disclose relevant information. Attackers may think it's a good idea to limit the presence of IOC in their tools to reduce risk.

2、 IOC, scanners and public information

From the leaked information, we can extract IOC information (illegal indicators or in normal words, what they are looking for). But the territorial disputes module looks for targeted apt attacks, and there's a lot of public information about targeted attacks that have been exposed. This module contains the detection of samples that we are already familiar with, as the Duqu attack revealed by BME CRYSYS laboratory. CRYSYS lab has done miniduke, teamspy, duqu2 or other work. Because security professionals have found a series of public information about apt attacks in a limited range, there must be a lot of information about the same attacks in the intelligence community.

This disclosure can reveal the gap between the public information and other organizations (public information refers to publications published through the safe community, which is mainly the contribution of anti-virus companies and research laboratories like our BME CRYSYS), and reveal the size of knowledge differences between these organizations. About 20 years later, it was known how many math experts had been hired by the National Security Bureau. Later, it was understood that the National Security Bureau was at least 10 years ahead of the current public password research results. However, the extent to which NSA (and other organizations) are leading the way in gathering information about apt attacks is unclear. The leaked information helps us to reveal how NSA finds traces of attackers on the time axis and the availability of public information in the same attack.

Please note that all types of stakeholders on the Internet can see the leaked data in the past year, so this report will not add new information to most government agencies, so we do not think it will affect the security of any country. However, a general understanding of the situation at the public level is essential to avoid confusion and to help the public make democratic decisions about the procedures of government institutions. In contrast, it can be expected that if based on the leaked information, previously unknown apt attacks may have been exposed, and even some apt events that are still using zero day vulnerabilities may have been identified by professionals according to the leaked data. In addition, it is a question whether it is a good idea not to disclose the apt information discovered by government agencies that can help avoid further attacks.

Of course, sharing information about ongoing attacks is debatable. First, sharing information can affect attackers and change their policies and tools, so institutions cannot continue to watch their activities closely. In addition, too much exposure could prompt other governments to deal with similar attacks by building NSA like capabilities. Finally, analyzing the advantages and disadvantages of sharing may have a positive impact on hidden information, because hidden information should be the default strategy of these organizations.

3、 Working methods

The goal of our work is to increase interest in this topic and help other researchers to study the results. This means that we can't check thousands of traces generated by 45 IOC in the leaked data. We try to go further after the initial information and expand the results by sharing this report.

For some known apt attacks, these findings can extend knowledge by, for example, adding the name of a new known kernel driver to a Stuxnet attack.

For some attacks, there is only a small amount of information available for public release, but the malware samples based on IOC may find more information and increase relevant public knowledge, although the information about the victims is unlikely to be disclosed.

For some attacks, some extra IOC can be used to expose these attacks. Because these traces were not available before, this also led to the conclusion of the previous apt research with a very short report, which stated that "XY uses this attack as a targeted attack, from now on we call it w", just like the news report.

In some IOC, we have never had any public knowledge about targeted attack (APT) classification. According to the current results, some attacks, samples and even hundreds of samples will be identified as part of some previously unknown or partially unknown apt attacks.

Initially we tried to collect information from traditional open source OPSEC resources, such as Google search. We also tried to gather information by applying Yara rules to our malware library, which consists of at least 150 TB of known malicious binaries.

Of course, information from one source is the basis for finding more information from previous results; therefore, we will continue to track these traces. However, this information set is too extensive. We absolutely don't agree with the label of "extensive research" or "full research". Part of our work is doing "preliminary research".

In the rest of the document, we mainly publish links, SMS and hash values. This means that we may publish the next steps, speculate on the source of the attack and all other information that can help others to further study. We don't think that we can or could have produced the best documents based on the existing facts, so we would be very grateful if anyone made efforts in this regard and expanded public knowledge through their achievements.

As a result, we are happy to help others post their extensions on our work. The current document plans to share information with professionals. Therefore, in addition to the public information (multiple types), the hash value of the sample is also included in the result. These hashes may be partially available, and it is not clear whether the samples found are really related to the attack.


Tools related to "territorial disputes" and other apt related information can be found in the following documents and directories leaked by "shadow broker":

The directory windows \ resources \ tedi \ pyscripts \ contains many files. Three of them are utility scripts, and the most interesting Python program is, which contains a very simple "signature" (named sig1-sig45), which is associated with known and unknown apt activities in recent years. The subroutines in this file are find ABCD 01 through find ABCD 45.

For example, find_isrelated to Stuxnet attacks. As an example, subroutines are very simple and short:

A piece of code can be used to analyze abbreviations, 'tedi' to territorial dispute, that is, territorial dispute:

In addition to the tedi scanner, some other files contain important information about targeted attacks. Another directory, windows \ resources \ EP \ scripts \ malfind, contains separate tools for scanning apt attack signs and extracting information:

For example, we found that sig25 is probably an apt attack called "dark Hotel". The relevant scan tool is a very simple script:

As we can see, the script looks for the existence of the file "winver32. Exe" in the specific $docsandsettings \ \ $subkey \ \ application data \ \ winver32.exe path. Interestingly, using Google to search the connection between winver32.exe and dark Hotel, no relevant information is displayed at present, so this link relationship may be based on the new discovery of leaked information.

Related "get" information collection scripts are also interesting. For example, a script related to Stuxnet (sig8) contains the following file names:

If a file is found on the destination, the operator may decide to get a copy of the file. (note the "Dropbox API" call, which is most likely the channel for file transfer.). Related code:

Another tool for scanning uses an external file with definitions to find the relevant sig: Windows / resources / EP / scripts / ifthen / gwdef_other_peeps.txt contains most of the same detection rules, but in a different format. Example screenshot of the tool:

The file driverlist. DB (windows \ resources \ OPS \ databases \ driverlist. DB) contains a list of drivers related to apt attacks, as well as antivirus product drivers, hardware drivers, and some interesting information, such as: information about NSA related attack tools, including comments / commands for operators. A similar file in text format can be found in Windows \ resources \ OPS \ data \ drv_lis t.txt, and the copied file can be found in Windows \ resources \ EP \ drv_list t.txt.

The list of drivers is most likely to contain known windows kernel drivers, and comments show associations with some apt attacks. For example, it seems that "biosfix" and "bitcheck" may be related to sig25 apt attacks. From the perspective of indicators, we believe that sig25 is an apt attack known as "dark Hotel".

There are notes about your tools:

“mscnsp”,“*** FORMALRITE / UNITEDRAKE ***”

 “mscoreep”,“*** FOGGYBOTTOM / UNITEDRAKE ***” 

And other interesting notes:

"Msfcvr32", "* * * dangerous malware - get help as soon as possible"

"Msrsfler", "* * * unknown - please recall ***" "wmiapvrr",

"* * * friendly tools - get help as soon as possible" "bsdnfs",

"* * * ask for help now * * *"

More similar comments can be found at the end of this article.

SIG tagged attack and timeline summary

4、 Details

This part is the IOC, type method and relevant information of all sig1-45. It is not posted here for the limited space. There are not many translatable parts in this part. Please refer to the original report for details.

For example, the following is the details of sig1.

This may be agent.btz, an old-fashioned attack related to the waterbug / turla organization, which is generally considered to be a Russian hacker organization.

Please use the hash value list to check each file. Note that there should be a lot of false positives.

5、 Related examples found in malware Library

Based on the results of SIG detection, we made Yara rules and scanned our malware database. The database contains approximately 150 TB of malware samples. After the scanning process, about 290000 malware samples were collected. Many of them are obviously false positives, such as the string adobe.dll, which can be found in thousands of samples.

The Yara rule we use is based on IOC. However, since the malware sample does not contain the entire path, we have to convert IOC to some strings that may be found in the malicious binary.

We tried to clean up what seemed likely to be the result of false positives. Finally, we collected 5162 samples that may be relevant. The following table shows the possible related hash values found by this method for each sig.

Note that the list does not contain all the known samples for each attack (for example, there are thousands of known files in Stuxnet), it only contains those samples that contain IOC known in the shadow brokers leak.

Many of these files may still be false positives, but there are still a few files that can be used to launch a detailed investigation of previously unknown apt activities and find other traces.

A complete Hash list with some basic tags is attached to the text file for ease of use. These tags are from Yara matching rules. For information, see:

6、 Interesting drivers from drivelist.db

The file driverlist.db contains a list of windows kernel driver files with interesting comments for some driver files.

When to seek help

In some cases, the operator is asked for help:

When to pull back

In some cases, operators are required to withdraw:

Internal tools

The files listed below may be related to NSA's own operations and tools:

The website of the report in English:

*Author: tempest, no reprint without permission