Digging Into Russian Disinfo Infrastructure

Disinformation and propaganda has been one of the key features of the war between Russia and Ukraine. One of the many groups that have sprung up to push pro-Russian propaganda narratives is a small hacktivist organisation called Beregini. This article by Givi Gigitashvili provides a useful introductory insight into the methods of Beregini by analysing the content of some of their recent leaks.

For this post I thought it would be interesting to see what insights might be gained from digging into the web infrastructure of the Beregini group website. It’ll also be a good opportunity to run through a few command line techniques to practice website investigation.

The Goal and The Tools

We’re going to start with a few passive recon techniques to help to identify where the main Beregini website is hosted, and what (if anything) this can tell us about the group.

Although Beregini are highly active on Telegram, they also have a website at bg14.ru. We can start by gathering a few data points about the website to see what we can find out.

As far as possible I’m going to use command line tools to find the information that I need. I’m a strong believer that OSINT practitioners who can use simple commands to gather and process raw data have a big advantage when it comes to intelligence collection. The main reason is that this makes it much easier to begin to scale and automate research in a way that is much more difficult to do with browser based methods. Let’s have a look at a few basic commands to get started.

Whois

Detailed Whois records with real personal data in them are largely a thing of the past, but that doesn’t mean that they aren’t useful. Here’s the Whois record for bg14.ru:

domain:        BG14.RU
nserver:       harleigh.ns.cloudflare.com.
nserver:       pablo.ns.cloudflare.com.
state:         REGISTERED, DELEGATED, UNVERIFIED
person:        Private Person
registrar:     PIN-RU
admin-contact: https://whois.pinspb.ru
created:       2022-03-09T12:40:12Z
paid-till:     2024-03-09T12:40:12Z
free-date:     2024-04-09
source:        TCI

Performing a Whois lookup with a web-based tool is quite straightfoward, but most versions of Linux and Mac OS have a command line whois tool built in. It has a lot more options than a regular web-based Whois lookup, but a basic enquiry looks like this:

whois bg14.ru

This returns the same data as in the web tool. Instead of taking a screenshot I can save the output to a text file for documentation purposes.

whois bg14.ru > whois_lookup.txt

Regardless of the method used, the Whois data doesn’t tell us who owns the site (of course) but it does reveal three useful snippets of information:

1. The site is using Cloudflare nameservers. This probably means that finding the true IP address of the website (and thus the real hosting company and server location) is going to require a little extra effort.
2. The admin contact for the site is associated to another domain – pinspb.ru. We’ll need to look at who this domain belongs to and what it is for.
3. The domain was created on 9th March 2022, which ties in with the site first being recorded by the internet archive on 16th March 2022. However Beregini have been active since at least 2016. This most likely means they have another web presence somewhere else that we’ll need to try and locate in due course, although we won’t cover that in this post.

DNS Records

Time to start using the command line again. To find where the domain is hosted we need to know the IP address. We can use the built in Unix tool dig to find this.

Here’s the basic command:

dig bg14.ru

Which returns:

; <<>> DiG 9.16.1-Ubuntu <<>> bg14.ru
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51636
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;bg14.ru.                       IN      A

;; ANSWER SECTION:
bg14.ru.                300     IN      A       172.67.163.61
bg14.ru.                300     IN      A       104.21.50.131

This is far too noisy to read effectively. We can trim the results by using the +noall and +answer options like this:

 dig bg14.ru +noall +answer

The results are now much easier to read. We have two DNS A records that show the IP addresses where the website is located:

bg14.ru.                300     IN      A       104.21.50.131
bg14.ru.                300     IN      A       172.67.163.61

We still need to think about documentating our research as we go along. To do this we can tidy up the output of the command a little bit more and save the output to a CSV file:

dig bg14.ru +noall +answer | awk '{sub(/\.$/, "", $1);print $1 "," $5}' > ipaddresses.csv

To save the data to a nice tidy CSV we can pass the result of the dig command using the pipe (|) symbol to the awk command. Awk is very powerful and lets us modify text output on the fly. In this case the first part of the awk command sub(/.$/, "", $1) removes the trailing dot from the domain name in the first field ($1) and replaces it with an empty value ("").

The next step of the awk command print $1 "," $5 will print fields 1 and 5 from the dig results, and place a comma between them. The output of this command is saved to a file ipaddresses.csv, which looks like this:

bg14.ru,172.67.163.61
bg14.ru,104.21.50.131

You might be thinking at this point that this all looks quite nerdy and so far you haven’t got any extra data that you couldn’t have grabbed from a tool like DNSDumpster. If you’re only looking at one single domain that is possibly true (depending on your typing speed and willingness to rely on cached results instead of live data…), but what if you want to grab the same information for 5, 10, 500, or 10000 domains at once? Collecting data this way is much faster and easily repeatable than manually copying and pasting domain names into Central Ops or View DNS to get the same data.

Who Owns The IP Address?

So far we have two IP addresses for the Beregini website, but who do they belong to? Since Whois records are published for IP addresses as well as for domains we can stay in the command line and find that out who these IP addresses belong to with another Whois lookup.

A word of caution at this point: IP address whois records only show the ISP or hosting company that a particular IP address was allocated to. It does not tell you which of that organisation’s clients or customers was using that IP address at any particular time. This means that we can’t use IP whois records to identify individuals, but we can at least know which ISP or hosting organisation they use.

Here’s the command to find who owns one of the bg14.ru IP addresses:

whois 172.67.163.61

This query returns a lot of information, including details about who owns this IP address:

NetRange:       172.64.0.0 - 172.71.255.255
CIDR:           172.64.0.0/13
NetName:        CLOUDFLARENET
NetHandle:      NET-172-64-0-0-1
Parent:         NET172 (NET-172-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       AS13335
Organization:   Cloudflare, Inc. (CLOUD14)
RegDate:        2015-02-25
Updated:        2021-05-26

As we suspected from the original Whois lookup, the organization field reveals that Beregini are using an IP address belonging to Cloudflare. This means finding their true IP address will be a little bit difficult, but it is still possible.

Finding The IP Address Behind Cloudflare

There’s a common misconception among internet investigators that Cloudflare are a hosting company. They are not. Cloudflare is a Content Delivery Network (CDN). Cloudflare relays content that is hosted elsewhere all across the world through its vast global network of servers. This speeds up the delivery of content to users and also means that Cloudflare can use its huge resources to protect sites from DDOS and malicious traffic. It’s a great resource but the unfortunate side affect for investigators is that when you query the IP address of a domain that uses Cloudflare you only get the IP address of a Cloudflare CDN server that is near(ish) to your location. This effect also explains why if you used the same dig command that I used earlier, you probably got different IP addresses to the ones shown above.

So we need to find a way to find the real IP address for bg14.ru. This is a complex topic and there isn’t one single method that works every time. I gave a talk on this subject called “Finding Fraudsters Behind Cloudflare” at the 2022 SANS OSINT Summit that goes into this in a lot more detail. For now we’ll focus on one quick and easy(ish) method that actually works to find the Beregini website’s real IP address by using Censys.

Censys Query

Censys is a a huge collection of thousands of different data points collected from all across the web. It constantly gathers information about the services, open ports and other data that it finds at each IP address it visits. As well as host data, Censys also logs the details of security certificates and parses them into a searchable format. The result is a vast collection of useful datapoints that we can query to find information about sites and services that we are looking for. It’s beyond the scope of this article to discuss Censys in more depth, but you can read more about their collection methods here.

Censys isn’t Google. You’re unlikely to be able to throw keywords into the search bar and hope you can find what you’re looking for (although sometimes you might). Censys has it’s own query language that we can use to search for specific types of data, so we’ll need to think carefully about exactly which datapoints we want to look for.

There’s a few places we could start, but I’m going to see if any IP addresses can be linked to any certificates that mention bg14.ru.

My rationale for starting here is that the certificate transparency log for bg14.ru shows that many certificates have been issued for the site by Let’s Encrypt and that Beregini have opted not to use Cloudflare’s own certificate service. There’s nothing unusual about this, but it might mean that we can use Censys to search for hosts where there is a Let’s Encrypt certificate with a common name that matches bg14.ru. If Censys has previously found this certificate and associated it to a non-Cloudflare host we might be able to find a little gap that leads to the real IP address.

The Censys query will looks something like the one below. It tells Censys to show any hosts where there is a security certificate containing the common name “bg14.ru”:

services.tls.certificates.leaf_data.subject.common_name:bg14.ru

Sure enough, our hunch was correct. Censys has logged at least one certificate for bg14.ru and they’ve associated it to an IP address…and this one doesn’t belong to Cloudflare.

Could 91[.]243[.]50[.]197 be the real IP address for the Beregini website? It’s possible. We’ll look at a method for verifying this shortly, but let’s see what other information Censys found first.

There’s some Whois information included in the Censys entry. It tells us that the IP address where bg14.ru is hosted belongs to an ISP based not in Ukraine, but in St Petersburg, Russia.

Remember that Beregini purport to be dissatisfied Ukranians – but the infrastructure they are using certainly isn’t based in Ukraine, it’s in Russia. This is an important point although it isn’t completely conclusive. There doesn’t have to be a firm geographic link between an organisation and the hosting arrangements for its website. Yet of all the countries in all of the world where Beregini could have chosen to host their server, they chose a hosting company based in St Petersburg.

The hosting company website at pindc.ru refers visitors to their main website at pinspb.ru. If this second domain sounds familiar that’s because we came across it the in the admin contact email for the bg14.ru Whois entry. It looks like Beregini are using the St Petersburg company for both their hosting and domain registration arrangements. Thanks to a user-uploaded photo, we can even see what the inside of the data centre looks like courtesy of Google Street View.

On the balance of probabilities this tends to support the hypothesis that the Beregini group are Russian based and backed, rather than the dissident Ukranians of their public persona. This finding is not conclusive by itself, but it is certainly an interesting place to begin further enquiries.

Final Verification

So far we’ve used completely passive techniques to find information about the Beregini website and we’ve got a fairly decent hunch about the true IP address for their website and its hosting arrangements. We can still do better than “decent hunch” and actually verify whether or not the website really is located there. These techniques are active and involve connecting to the website directly, so consider OPSEC measures like a VPN when undertaking research like this.

We’re going to use the command line one last time. It seems likely that the true IP address for the Beregini website is 91[.]243[.]50[.]197, so we’re going to use the curl command to see if we can grab the bg14.ru website content directly from that IP and either confirm or rule out our theory.

First let’s grab the website content directly with a URL. curl will default to the IP address returned by a DNS request, so this will be directly from Cloudflare.

curl -k https://bg14.ru -vv

The -vv option provides more verbose output so we can see what curl is doing when it retrieves the webpage. The -k option tells curl to skip any issues caused when connecting via https.

As expected, we get all the raw CSS and HTML from the webpage as served via Cloudflare:

*   Trying 172.67.163.61:443...
* TCP_NODELAY set
* Connected to bg14.ru (172.67.163.61) port 443 (#0)
*snip*
< server: cloudflare
< cf-ray: 7ef83309897874b1-LHR
< alt-svc: h3=":443"; ma=86400

...

<link rel="pingback" href="https://bg14.ru/xmlrpc.php">

<title>BEREGINI</title>

etc...

What if we try and grab the site content directly from the IP address? This won’t always work, especially when a webserver has been configured to ignore direct connections to the IP address or if multiple sites share the same IP, but we can see if it’s still possible. Here’s the command:

curl -k https://91.243.50.197 -vv

And the result:

*   Trying 91.243.50.197:443...
* TCP_NODELAY set
* Connected to 91.243.50.197 (91.243.50.197) port 443 (#0)

...

 SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=bg14.ru
*  start date: Jun 17 02:19:31 2023 GMT
*  expire date: Sep 15 02:19:30 2023 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.

We don’t get the full web page content this way, but we do pull back the security certificate for bg14.ru. It looks like our hunch is proving to be correct. There’s one more technique to try.

We can tell curl to ignore the Cloudflare IP address returned by DNS records and instead force it to try and resolve the website at our target IP. If it can, the site content should appear in the terminal. If it can’t, we’ll get nothing back.

curl -k https://bg14.ru --resolve bg14.ru:443:91.243.50.197 -vv

The addition of the --resolve option tells curl to use our target IP address to connect to the site on port 443 (HTTPS). Here’s the result:

 Added bg14.ru:443:91.243.50.197 to DNS cache
* Hostname bg14.ru was found in DNS cache
*   Trying 91.243.50.197:443...
* TCP_NODELAY set
* Connected to bg14.ru (91.243.50.197) port 443 (#0)

...

* Server certificate:
*  subject: CN=bg14.ru
*  start date: Jun 17 02:19:31 2023 GMT
*  expire date: Sep 15 02:19:30 2023 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.

...

<link rel="pingback" href="https://bg14.ru/xmlrpc.php">

<title>BEREGINI</title>

etc...

Success! We’ve managed to retrieve the bg14.ru site content directly from the original hosting server and verified what we found with Censys. This means we can be confident about the site’s true IP address, ISP, and server location. It also reveals useful additional information about Beregini’s infrastructure and vendor choices that we can use in further research/

I’m an experienced investigator and OSINT practitioner and I’m currently looking for new work. If you think my skills could help you or your organisation, then please get in touch.