In August 2016 an archive was released to the public by an unknown group calling itself Shadow Brokers. This archive contained material attributed to the Equation Group. The authenticity of this leak, its reason, attribution and content have already been widely discussed, by Bruce Schneier and Matthieu Suiche among others. Mustafa Al-Bassam has kept an inventory of the leak and has commented on Twitter.
This post is based on what can be extracted from the various procedures contained in the released material. Most of these procedures can be found in the “SCRIPTS” directory, with a few others scattered in various other directories. Using the aforementioned data, this post will focus on what can be deduced regarding Equation Group’s organisation, their modus operandi, and will list simple techniques to impede or detect their operations.
General remarks
The accessible material is in a “Firewall” directory and is comprised of tools, exploits, and the technical guides to use them. The identified target equipment includes Cisco Pix and ASA, Juniper, Netscreen (acquired by Juniper), TopSec, Fortigate, Huawei, and RapidStream (acquired by WatchGuard). These are either American or Chinese-made. The files seem to date back to 2013 (in addition to the properties, one file includes a changelog starting in 2010 with the last date in 2013).
Some files could have been tampered with: the beginning of some procedures appears to be missing (see “SCRIPTS/Feedtrough.txt” for example), and at least one other procedure refers to seemingly missing material (“SCRIPTS/FairvaultFix.txt”).
The first thing that one can note when skimming these files is the organisation transpiring behind them. The distribution in various roles is clear: the “DEV” team in charge of identifying, designing, testing the tools and exploits; and the “operations” team, which will target, deploy, collect. These procedures are read as technical guides written by the former and addressed to the latter. Shell commands and options are listed along with their expected returns, the phrasing and comments vary from one redactor to another, but are everywhere very informal.
In multiple procedures the developer specifies what the behaviour of the target equipment is anticipated to be when either confronted to the incoming exploit or to the action of the operator. For example in “FalseMorel.txt” the developer gives the log expected when not properly closing a connection. This displays a level of knowledge that can only be achieved by experimenting in a lab environment against the target equipment. It shows an organisation with the means to acquire, crack and design exploits against target equipment. There is even a reference to this lab environment to practice the procedure before deploying in the field.
Next, the operational organisation appears from time to time. One comment is particularly interesting:
“Second verify with the analyst if this target has a unilateral or multilateral implant on it”. This comment shows one person, the developer, talking to a second, the operator, about a third, the “analyst”. It could be inferred that the operator who is the recipient of this procedure is tasked with maintaining the deployment inside the target environment, while the analyst is a kind of “L2 operator”, more senior, in charge of the tactic of the attack, working in accordance with the intelligence aspect of the operation. This is consistent with the necessary compartmentalisation (working both ways) in any intelligence environment, in addition to the required technical specialisation.
There are multiple references to “ops” or “operations”. Although some tools might not appear as highly complex, what is interesting is the coherence between them. Their use in operational context implies a minimal reliability, which is not trivially achieved. This translates well into “military”.
Last but not least, these guides frequently contain warnings regarding stealth. Those can either be found as options implemented in the tools, as notifications linked to specific actions, or as procedures to follow (i.e open an additional channel, delete the tool, delete the logs, close the connection). In “EGBL_AND_BLATSTING.txt”, the developer indicates the network footprint that can be expected from bringing back information required to develop a specific “implant”: “if you can only get 12 MB. These types of comments, their frequency, and the level of concern they imply show the involvement of the developing team in the mission. This reflects the cohesion and drive toward a single objective, the single elite team mind-set that must exist in this division.
Only once does a comment seem to contrast with this. In “BG_upgrade_module_3100.txt”, the author writes: “Now, lets continue on the assumption you did everything correctly which you should have prepared and tested before your op!” The last part is literally the last sentence of the guide. Such a type of warning is usually best suited and useful for the beginning of a procedure. Some other comments also might translate a form of irritation towards the end user of the products, but those remain scarce.
To summarize, these files show discrepancies between redactors: some seem quite junior, while others appear as more seasoned veterans. It sheds a light on a segmented organisation, with enough resources and manpower to acquire and crack various types of equipment. The developers design and document tools usable by others, maybe entry-level operators, in an operational context.
Tactics, Techniques and Procedures
One tool that stands out among all the others is called BENIGNCERTAIN. This very specific tool is able to extract VPN private keys of IPSEC sessions. This function apparently works over the Internet. Mustafa al-Bassam talked about it, and other people must be looking at it as well.
The remainder of the material is comprised of command sets, privilege escalation tools, modules for “implants” and intrusion tools. The intrusion tools use Remote Code Execution (RCE) exploits. Obviously, Shadow Brokers only leaked what it wanted to leak. All of the exploits released seem to target the admin interface meaning that the operators would already need to be inside the target network to be able to use them. It means that the exploits still require the attacker to comply with a regular attack scheme, i.e server-side or client-side initial intrusion and then lateral movement.
What stands out in various procedures is that they turn the targeted equipment into access points. This means that firewalls, which are perimeter-defence equipment, are changed into gateways. Because your firewall usually is your last equipment, there is little way that you can find out someone is in here with you.
What follows is your classic APT team, executing an attack with precision and organisation.
They use rebounds to connect to target equipment and avoid connecting directly. There is a description of one such technique in “Install_PIX_OS.txt”. This guide describes the deployment of a rogue IOS operating system on a Cisco PIX. On multiple occasions the redactor stipulates using tunnels to avoid connecting directly to the target. These tunnels must go through “redirectors”, such as “pitchs” or “inside targets”.
Subsequently, when this new OS is deployed, the developer advises waiting “days/weeks/months” for a legitimate reboot. The equanimity with which this advice is delivered is clear: we have all the time in the world, in the end we will succeed, we’re playing the long run.
Various procedures define system reconnaissance as an almost reflex. This translates into various system commands being executed to gather the most information: OS, users, process running, configuration, etc. For instance, in “Bookishmute.txt”, the guide specifies a system check using ps, ifconfig, df and mount. “sampleman_commands.txt” is a collection of system commands for Pix, Juniper, Netscreen, Huawei. Their goal is system reconnaissance, again by collecting the most information.
Moreover, “sampleman_commands.txt” specifies what is logged depending on the configured logging level.
The first actions enable the attacker to check the presence of another connection, and details which connection types are visible. The file stipulates to abort if the operator is not alone. It also states connecting to the remote host in charge of the log collection to delete these if needed. These are few of the many occurrences found in these guides, which bring the focus on the permanent stealth imposed.
This stealth is enacted in multiple ways:
- specifying the logs generated by various actions, crossed with the logging level
- suppressing log entries and any evidence (files, directories used)
- respecting (no edition/deletion) hidden files (used for persistence or stealth)
- deleting tools once used (some tools apparently have a built-in “burn” option)
- aborting connection at two failed authentication attempts
- abort if the logs are redirected to another equipment, except if said equipment is compromised
- at least one module dedicated to the processing and deletion of logs (“
(BANANA|BAR)GLEE/*/BSLOG-XXXX.mod”) - calgon: tool solely designed for the purpose of processing and deleting logs
Finally, common remote access tools (RAT) communications usually hide alongside legitimate traffic. The most common way is disguising outside beaconing into HTTP traffic. These communications can be identified by “hunting” through the proxy logs (among other ways). Here, the technique of changing a firewall into a gateway can also be used inside the target environment. This turns into a broader tactic of setting up tunnels inside the target network headed to border firewalls, where a subsequent tunnel is set up. It enables routing from the target core assets to Equation Group’s staging servers. This makes proxy log analysis and signature detection useless.
Detection and defence
These tools and exploits do not change the path of a normal killchain. What we see here is reconnaissance (command sets), lateral movement (RCEs on admin interfaces), privilege escalation (EPICBANANA, ESCALATEPLOWMAN), persistence (JETPLOW, SCREAMINGPLOW, FEEDTROUGH). This leak contains no initial intrusion material. This means that regular detection and defence strategies still apply. Even if we assume the worst-case scenario of a remote code execution on the public interface of a border firewall, it still takes us back to a defence-in-depth doctrine. This needs to be put into perspective with the fact that Equation Group is suspected to leverage physical access into a cyber environment.
What the exploits, tools and procedures contained in the package show is that Equation Group is actively pursuing admin networks and infrastructures. In this respect, the fact that they abort if logs are sent to separate equipment unless they “own” this equipment is a tell-tale sign of their operational tactics. This pushes them into owning the alert chain, to then slowly creep across the target environment.
Therefore, enabling a close compartmentalisation of the admin infrastructure (separate networks, separate admin and Internet workstations, separate accounts) is not just a fancy consultant eccentricity, but rather the first thing that might slow Equation. Separating admin and security infrastructures will slow their action even more. Software patching is a must. Even though these vulnerabilities have been out there for years, some systems are still vulnerable.
The provided material shows that firewalls are common targets, but also that they pay really close attention to the logs they generate. The logs shown in the following screenshot are simple logs: authentication success and failure, plus ALERT and ERROR facility logs.
Furthermore, infrastructure equipment is not really very verbose when it comes to system logs. They are usually limited to “someone connected”, “someone disconnected”, “configuration was edited”, and “I have a problem”. Such equipment is rarely accessed or modified and therefore does not produce a significant volume of log traces – which aligns with Equations Group’s TTPs.
Hence, collecting, centralising and processing system logs from firewalls, routers, and switches seem like a very appealing idea. This does not even require large capacities: a simple server will do the trick. Monitoring can be done through a dashboard with auth success, auth fails, and error & alert log categories. The authentication activity needs to be checked against the admin activity. An admin can check his perimeter on such a dashboard once a week. This is assuming a rather clean and organised information system, but attackers generally take advantage of the opposite situation.
Lastly, the network aspect cannot be set aside. Signature-based detection is only useful if you have the signature. But even on ciphered network traffic, capture points can reveal the appearance of unusual ports or services, or a surge in network statistics. You can use numerous capture points to monitor network sections, and check the behaviour of firewalls (as in, “do my firewalls behave according to the network matrix they are supposed to follow?”). This can be achieved through traffic profiling. Then again, the monitored networks need to be appropriately designed, and have a normal “noise” volume limited to a minimum. Such a solution could be time-consuming, and seems worth considering mostly for stable networks with a tech-savvy admin team.
Conclusion
What this leak reveals, besides older-than-three-year-old-still-working exploits, is that Equation Group is human like everybody else. There is nothing ground-breaking, earth-shattering in this material. Expecting less than the TTPs found in this leak would have been an error.
What stand out are the professionalism, the organisation given to this task, and their focus on retaining stealth. As Rob Lee of SANS says, “It’s an army set-up to hack your organization”. That makes them a formidable opponent.
Finally, these files are only procedures from which the operator can divert. Equation Group’s doctrine limits this, but then defending against them still calls to basics, as a first mandatory step.
