A case study tracking adversary infrastructure through SSL certificate use featuring Fancy Bear/APT28/Sofacy.
A long time ago, in a galaxy... No. Stop. We're not doing that anymore. Instead, we're pivoting to Game of Thrones, or A Song of Ice and Fire for you bookworms, because the fantastical realm provides great material we can relate to cybersecurity.
This research builds off our previous work using SSL certificates and splash pages to proactively identify Fancy Bear infrastructure. We identified a SSL certificate subject string that Fancy Bear has used consistently since 2016, which further illuminates their infrastructure and registration tactics. Our hope is that in addition to the indicators themselves, our readers will apply these techniques to their research on other adversaries.
We'll walk through the process of how we conducted this research, which used ThreatConnect, Censys, Farsight Security Passive DNS, RiskIQ, and DomainTools. To date, this line of research has identified 47 IPs, 46 domains, 33 registrant email addresses, and 47 SSL certificates shared in ThreatConnect in Incident 20180209C: "C=GB, ST=London, L=London, O=Security, OU=IT" Certificate Infrastructure. It also underscores consistent Fancy Bear tactics including:
- Use of small or boutique hosting service providers such as Domains4Bitcoins, ITitch, and NJALLA.
- Minimizing the reuse of email addresses to register domains.
- Regular use of email domains sapo[.]pt, mail[.]com, centrum[.]cz, and cock[.]li or privacy protection services.
- Domain registration and SSL certificate creation times that are consistent with an actor operating in Moscow.
The Watchers in the Night
Everybody thinks they are House Stark material, but we would assert cybersecurity personnel are more like the sworn members of the Night's Watch. You are the watchers on the firewall, the sword in the dark web, and the shield that guards the networks of your organization.
If we're being honest, the ThreatConnect Research team and cyber threat intelligence analysts at large, are most like... wait for it... Samwell Tarly (none of us harbors the delusion of being Jon Snow). Tarly is dedicated to aggregating and analyzing intelligence on threats beyond the wall -- the Night King and his White Walkers -- to better understand how the Night's Watch can react to them and proactively address them.
Looking for Adversary Infrastructure Using a Common SSL Certificate Subject String
In our recent efforts to proactively address Fancy Bear, we reviewed SSL certificate information in Censys for domains and IPs using a "Coming soon" splash page consistent with previously identified Fancy Bear infrastructure. We found the same subject field used repeatedly -- "C=GB, ST=London, L=London, O=Security, OU=IT, CN=(domain name)" -- as shown below for space-delivery[.]com and webversionact[.]org.
Censys SSL certificate information showing consistent use of subject string.
This subject line indicates a SSL certificate likely created using OpenSSL, where the creator assigns values for the country (C), state (ST), location (L), organization (O), organizational unit (OU), and common name (CN). It is important to note that the common name is intended to reflect the domain name where the SSL certificate is being used, but in our research we found several instances where this domain name was misspelled or altogether different from the domain where it was used. More on that later.
Radiating out: how common is that subject string?
Next, we needed to get an idea of how widely this string is used and what other infrastructure is using similar SSL certificates to gain insight into more possible Fancy Bear infrastructure. Again using Censys, we found 47 certificates that have the same SSL string. In Censys we also queried for IP addresses that host a server using a SSL certificate with that string. The latter provides a view of active infrastructure, while the former can be used to find both historical and active infrastructure.
Censys certificate search results for identified subject string.
Careful though: other individuals could easily use OpenSSL to create certificates with the same subject fields; this alone is not sufficient to identify Fancy Bear. Using ThreatConnect's Analyze function we saw that at least 23 of the specified common names have been associated with Fancy Bear attacks. Many of the remaining domains have also been identified through our ongoing research into name servers that Fancy Bear uses. This increases our confidence in assessing that SSL certificates with that subject string probably are associated with Fancy Bear activity.
ThreatConnect Analyze results showing indicators that already have information in ThreatConnect.
Stitching together certificates, IP addresses, and the right domains
Censys SSL certificate information for 46ce0b05f302e0d855e9cc751100299345466581.
At least 39 of the certificates identified in the previous query are no longer in use, but we used RiskIQ to search for the SHA-1 hash and identified the IP addresses that previously hosted a server using that certificate. For example, searching for the previously used SSL certificate 46ce0b05f302e0d855e9cc751100299345466581, we saw that it was used at the IP 184.108.40.206.
RiskIQ SSL certificate information for 46ce0b05f302e0d855e9cc751100299345466581.
Reviewing this IP address in ThreatConnect using our integration with Farsight DNSDB, we saw that this IP address hosted the domain remsupport[.]org. This is a notable finding as well because the domain does not correspond to the ecitcom[.]net that was specified in the common name field in the certificate subject, so we took an extra step to make sure we matched up the right certificate to the right domain.
ThreatConnect's Farsight Security Passive DNS integration results for 220.127.116.11.
Conducting this same process for all of the SSL certificates, we came up with the following list sorted by the SSL certificate's create date/time:
|SSL Certificate SHA-1||IP Hosting Certificate||SSL Certificate Create Date/Time||Domain Hosted At IP or Common Name in SSL Certificate|
Once that we had a list of the domains, we further enriched this information by identifying the WHOIS information for these domains. Doing so provided historical information on how these domains were registered.
Gathering Intelligence: Layering on WHOIS Data
To do so, we used some capabilities and integrations from our friends at DomainTools. Specifically, we were looking to identify registrant email addresses, name servers/hosting providers, and creation timestamps. We started by doing a DomainTools Iris search for the domains listed above.
DomainTools Iris search for identified domains.
This provided the current WHOIS information for those domains. However, some of the domains have been taken over since they were operational or the WHOIS has otherwise changed since it was registered for use in operations. For any domains where we thought this was the case, we reviewed the WHOIS history in our DomainTools Spaces app to identify the original registration information that corresponds to the timeframe in which the domain was operational.
ThreatConnect's DomainTools Spaces App WHOIS history for adobeupdatetechnology[.]com.
Ultimately, we identified the below registration information for these domains.
|Domain||Original Registrant||Original Nameserver||Create Date||Create Time|
We have shared this information, including the domains, IPs, and email addresses, with our Common Community in Incident 20180209C: "C=GB, ST=London, L=London, O=Security, OU=IT" Certificate Infrastructure.
There are Fancy Bear tactics that we can glean and proactively exploit to identify their activity going forward in addition to monitoring for new domains/IPs that use the aforementioned SSL certificate subject string.
Hosting Service Providers/Name Servers
The domains' original name servers helps identify the hosting service providers that the actors used to procure the infrastructure. These include several providers that we've previously called out, such as Domains4Bitcoins, ITitch, Nemohosts, Carbon2u and NJALLA. We can proactively monitor for newly registered domains using these name servers and with other consistencies to Fancy Bear to potentially identify their infrastructure before it is used in operations.
We used DomainTools Reverse WHOIS to search for any additional domains registered using the email addresses above. As it turns out, only one of the email addresses -- iflatley@openmailbox[.]org -- registered a second domain (rndversion[.]net). This minimal reuse of email addresses suggests an operational security (opsec) effort to deter efforts to trace out their infrastructure based on known registrants.
DomainTools Reverse WHOIS results for iflatley@openmailbox[.]org.
While some of the domains were registered using privacy protection services, for those that aren't we see the consistent use of sapo[.]pt, cock[.]li, centrum[.]cz, and mail[.]com. For those email domains that are less common, like cock[.]li, we can create a Track in ThreatConnect that will alert us to any new domains registered using that email domain.
Creating a Track in ThreatConnect.
When reviewing the SSL certificates, we identified several possible opsec mistakes that would either arouse suspicion or allow defenders to trace out some of their infrastructure. As we mentioned earlier, the common name in the SSL certificate field is intended to correspond to the domain name where it is being used; however, for ten of the identified certificates, that wasn't the case. In some cases, the domain name was misspelled, like the below certificate for cdnverify[.]net. This mistake would be a red flag for defenders looking to verify the legitimacy of encountered domains based on their SSL certificate.
Censys SSL certificate information for 43df735cfea482ffc27252ae08c94f359c499f69.
In other certificates, a completely different common name was used, as was the case for the aforementioned ecitcom[.]net. It turns out that ecitcom[.]net was the specified common name for five of the certificates listed above. When we search Censys for other certificates using that common name, we find four more certificates that were created from February 2016 to September 2016. This helps us identify the additional infrastructure 51.254.158[.]57, dowstem[.]com, 18.104.22.168, 22.214.171.124, and 126.96.36.199. Researchers can exploit mistakes like these to expand their understanding of adversary infrastructure.
Finally, we can make use of the creation timestamps for the identified certificates and domains. As the chart below shows, a large majority of the certificates and domains were registered between 0600 and 1400 GMT. This is consistent with a 0900 to 1700 standard work day in Moscow. While not definitive -- other countries in the Middle East, Eastern Europe, and Western Africa are in the same timezone -- in conjunction with the previous associations to Fancy Bear this finding increases our confidence in the attribution to Fancy Bear.
Chart showing the number of domains and SSL certificates that were created by hour relative to Moscow's time zone (MSK).
The registration and certificate creation times is of limited use to identify additional Fancy Bear domains proactively - especially for a single indicator - but the consistency of the data set over time has value for defenders and researchers.
Conclusion: To the Citadel!
We are sometimes asked why we share out these findings publicly, the argument being that we are revealing research methodologies that Fancy Bear can now incorporate into their opsec and avoid in future operations. That's a fair concern, but in response we argue that by publicizing these findings and methodologies, we are hoping to show our readers ways to research not only Fancy Bear, but the other Night Kings that keep them up at night.
Additionally, as we've stated before, in publicly outing or sharing these indicators and tactics, organizations can ultimately increase the actors' costs and push them to spend more time and resources on procuring infrastructure. The more this is done, the better. Eventually, you might get to the point where you become a factor in the actor's decision making or cost benefit analysis.
Samwell Tarley's main source of intelligence, Castle Black's library, ultimately proves to be insufficient for determining how to best the Night King. He then travels to the Citadel, a huge library of intelligence consolidated from a variety of sources, in hopes of garnering knowledge that will help defend the realm. For threat intelligence researchers and cybersecurity personnel, ThreatConnect acts as a metaphorical Citadel, consolidating, aggregating, and analyzing intelligence from a range of internal and external sources. However, whereas the maesters at the Citadel seem unencumbered by what happens outside of Oldtown, ThreatConnect gives users the ability to actually act on the intelligence they receive and integrate with the defensive tools they have in place to mitigate their threats. If you want to learn more, check out our platform.
ThreatConnect Dashboard showing users recent intelligence from our Citadel on Fancy Bear.