The Proud Boys Email scams, and why it should have never worked

Recently, a political group that goes by the name “The Proud Boys” lost access to their domain (officialproudboys.com) and then some bad actors took control of this domain in some form to send spam emails to US voters in an attempt to push voters to vote for a particular party. This particular writeup is an attempt to stay politically unbiased, and to instead point out the technical failures that lead to any of this being possible, but I want to make clear, these emails are fake, they have seemingly no affiliation with The Proud Boys, and should not be a reason to not vote.

First thing’s first, we should discuss what exact techniques can be used to prevent Email spam. The main techniques at play involve DNS, as those are the best way to verify the intent of the domain owner, especially if DNSSEC is used and the proper DS records are pushed to the authoritative servers. Below there will be a list of different records used in DNS to verify mail, and a somewhat technical explanation of how they are used.

• MX
  • MX records are the foundation of mail. The MX records are one of the simplest DNS records to understand and consist of both a weight and a hostname. The hostname (think of a domain name) has to point to an SMTP server configured to accept mail destined to that domain. The weight is there in case you have multiple MX records and you do not want the client to randomly choose a mail server. Below is an example for a domain I own, and I’ll break down the answer section.

  • clickable.systems. 599 IN MX 10 smtp.clickable.systems.

    
    

    clickable.systems. 599 IN MX 20 build.ops-netman.net.

    
    In this example, I have two mail servers for this DNS Zone (for the uninitiated, think domain) where one of them I intend to be the main mail server and the secondary I intend for backup purposes only.
  • The first number you see denotes the TTL, which tells you how long before that record is no longer “guaranteed” to be valid, which is followed by IN, a legacy element since DNS predates the internet’s superiority over legacy items like chaosnet.
  • After that, you see MX, which is the record type for this record.
  • Lastly, you see the last number, which tells you what the weight is for that mail server (lower is higher priority) and the specific mail server that record applies to. It is up to the client/resolver to resolve the hostname of the mail server.
  • With this in mind, you should also know that MX records are only used for sending mail TO the domain, but are also used later on as shorthands, and can tell you a lot about a domains mail information (whether or not they accept mail is a good way to know if they might send mail as well, though this is not something done procedurally by mail servers.)
• TXT
  • TXT records are exactly as they seem, they store text! They can actually store any text you really want, which is important to keep in mind, and can make it difficult to determine the purpose of any specific record.
  • With that previous statement in mind, TXT records are used for a lot of parts involved in mail verification, as are listed below.
  • SPF
    • SPF records are an easy thing to understand, particularly if you simplify a few of the unused features. Before we get to that, however, we need to go over the basic formatting of an SPF record.
    • "v=spf1 mx ~all" A few things to notice about this example, you should note that this was trimmed from the full output I showed you for MX records to be less repetitive.
    • The first part of the SPF portion of the record is a version tag. The version tag is currently only used for identifying an SPF record from normal TXT records.
    • Next, you see mx, which is that shorthand I pointed out before. Since there is not a - or ~ in front of it, it means that anything that is also an MX record will not be marked as spam on its own.
    • At last, you see ~all, which is prefaced by the - or ~ as seen before, meaning it is blocked. With that in mind, it means that anything that was not previously excluded will be blocked and should either be marked as spam or not shown to the user.
    • It should be noted, there is a difference in SPF between ~ and -, however it is not something that is used much today.
    • This record is a pretty simple example, but shows a safe and common option for SPF records that can be easily copy and pasted between all managed DNS zones.
  • DKIM/DMARC
    • DKIM/DMARC are part of a system to use cryptography in order to verify mail authenticity. This works by adding a cryptographic signature into the header of any email and pointing to a DNS record where you can verify it with the public key. This is fairly simillar to before and I will not be demonstrating it here as it’s a bit harder to write out, but if you are still confused, it’s simillar to how your browser knows you are visiting the correct website because the certificate/signature my server provided to your browser matches a certificate authorized by your computer, except in DKIM this is done via DNS instead of certificates embedded in your consumer devices.
      • These same certificates your browser do exist for email as well, but with a few small exceptions, if the server does not have a valid certificate then it will downgrade itself to unencrypted and probably not notify the user.

With this in mind, there are multiple other ways to detect spam without examining the message body, however this is subject to other issues and are not authorized by the domain owner themselves.

Focusing back on topic, unfortunately I do not have the email headers for any of these scam emails (see the whoami if you have one and can share the headers!), but I can observe what these servers do have configured and how those conform to standards.

First thing’s first, we should look at SPF records, as these are the simplest things to check and are very easy to explain….

"v=spf1 -all"

And… Wow, they did this well! They do not allow for MX records, but we can cycle back to that later.

Next, we can check DKIM, and… well they do fail to have DMARC (focused on having mail servers notify webmasters if there is a bad configuration), but without email headers to play with, I cannot make any assumptions beyond that DKIM also doesn’t exist.

One for two, not bad, but with not much else to see, how about we just scan more of their DNS zone? These people have reportedly lost their domain recently, so let’s see if there’s anything notable. In DNS, there is a “deprecated” query called ANY, which usually dumps all of the records for that particular DNS key. It was deprecated because it was not defined well, and was used often for DDOS attacks, due to its large response and how UDP works. I use quotes though since no one but Cloudflare is really eager to work on that, and even my domains support it because Bind9 (my DNS server software of choice) doesnt support blocking those requests yet, though I may be doing something about this in the future.

With this in mind, let’s crack open these people’s DNS zone, for transparency I am trimming the DNSSEC (which they use!) just so I can make it more readable. Consider this my pat on the back for using DNSSEC, before I go back to being disappointed again.

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> any officialproudboys.com @ns4.epik.com +nodnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15367
;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;officialproudboys.com.		IN	ANY

;; ANSWER SECTION:
officialproudboys.com.	300	IN	CAA	1 issue "letsencrypt.org"
officialproudboys.com.	300	IN	CAA	1 issue "usertrust.com"
officialproudboys.com.	300	IN	NS	ns3.epik.com.
officialproudboys.com.	300	IN	NS	ns4.epik.com.
officialproudboys.com.	300	IN	TXT	"v=spf1 -all"
officialproudboys.com.	3600	IN	SOA	ns3.epik.com. support.epik.com. 2020102109 10800 3600 604800 3600

;; Query time: 30 msec
;; SERVER: 91.149.194.188#53(91.149.194.188)
;; WHEN: Fri Oct 23 01:52:53 EDT 2020
;; MSG SIZE  rcvd: 225

Alright, so this is… interesting… ignoring the 2 CAA records, the only other thing is showing that they are using epik.com for DNS… but who is epik.com?

Epik.com describes themselves as cheap domain registration, and that is 100% true. Let’s look at who ns3 and ns4 point to…

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> any ns4.epik.com +nodnssec @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16735
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 6
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns4.epik.com.			IN	ANY

;; AUTHORITY SECTION:
epik.com.		172800	IN	NS	ns1.epik.com.
epik.com.		172800	IN	NS	ns3.epik.com.
epik.com.		172800	IN	NS	ns4.epik.com.

;; ADDITIONAL SECTION:
ns1.epik.com.		172800	IN	A	52.55.168.70
ns1.epik.com.		172800	IN	A	91.149.194.88
ns3.epik.com.		172800	IN	A	52.55.168.70
ns4.epik.com.		172800	IN	A	172.107.216.250
ns4.epik.com.		172800	IN	A	91.149.194.188

;; Query time: 23 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Fri Oct 23 01:56:54 EDT 2020
;; MSG SIZE  rcvd: 171

Alright, so this is a really interesting and bad time, so much so I’m going to list it out because it is 2 in the morning and this stupidity is not worth my writing.

• No IPv6 addresses
• A third NS record not assigned to the client website, also what happened to 2?
  • What happened to 5?
• Duplicating IP addresses across records

Now, if you’re more familliar in this field, you may notice that I havent actually looked at who those IP addresses are yet, but dont worry, I saved the best for last later. For transparency, I am only showing the subnet and organization for the ip addresses, since I want this post to be more than DNS and whois records.

NetRange:       52.32.0.0 - 52.63.255.255
CIDR:           52.32.0.0/11
NetName:        AT-88-Z
NetHandle:      NET-52-32-0-0-1
Parent:         NET52 (NET-52-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       
Organization:   Amazon Technologies Inc. (AT-88-Z)
RegDate:        2015-09-02
Updated:        2015-09-02
Ref:            https://rdap.arin.net/registry/ip/52.32.0.0



inetnum:        91.149.194.0 - 91.149.194.255
org:            ORG-AI208-RIPE
netname:        ANONYMIZE-NETWORK
country:        PL
admin-c:        RM20995-RIPE
tech-c:         RM20995-RIPE
status:         ASSIGNED PA
mnt-by:         mnt-us-anonymize-1
mnt-by:         MARTON-MNT
mnt-routes:     mnt-us-anonymize-1
mnt-routes:     MARTON-MNT
mnt-domains:    mnt-us-anonymize-1
mnt-domains:    MARTON-MNT
created:        2019-10-07T10:43:01Z
last-modified:  2019-10-10T12:45:25Z
source:         RIPE


NetRange:       172.106.0.0 - 172.107.255.255
CIDR:           172.106.0.0/15
NetName:        PSYCHZ-NETWORKS
NetHandle:      NET-172-106-0-0-1
Parent:         NET172 (NET-172-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       AS40676
Organization:   Psychz Networks (PS-184)
RegDate:        2015-06-22
Updated:        2015-06-22
Ref:            https://rdap.arin.net/registry/ip/172.106.0.0


inetnum:        91.149.194.0 - 91.149.194.255
org:            ORG-AI208-RIPE
netname:        ANONYMIZE-NETWORK
country:        PL
admin-c:        RM20995-RIPE
tech-c:         RM20995-RIPE
status:         ASSIGNED PA
mnt-by:         mnt-us-anonymize-1
mnt-by:         MARTON-MNT
mnt-routes:     mnt-us-anonymize-1
mnt-routes:     MARTON-MNT
mnt-domains:    mnt-us-anonymize-1
mnt-domains:    MARTON-MNT
created:        2019-10-07T10:43:01Z
last-modified:  2019-10-10T12:45:25Z
source:         RIPE

Now, this could easily look like witchcraft to the untrained eye, but here’s the pattern you should see, not only are these all public cloud, they’re all different and not in nearly the same ballpark. If this was one in Azure, one in AWS, and one in GCP, then atleast someone could make the excuse that this sysadmin really wants to prevent downtime, but this is not the case here. When I said these people were cheap, I was not exaggerating.

But what about NS5?

Oh I am so glad you asked.

NS5 resolves to 45.79.4.83, which resolves to Linode…

WHY? Who decided Linode was a good idea for a name server? Actually, I probably know who, someone aiming to be the lowest bidder, and who is riding off free accounts and possibly stolen credit cards, meaning they would need to have backup name servers in case one of their accounts get shut down.

This, out of everything else, is where I threw in the towel as I sat, disappointed in what had become of us as a society. This is just hard to watch, and really a good example on how bad people are at networking.

My conclusion, however, has to do with mail servers and systems administrators.

• Verify ALL incoming mail with SPF and DMARC, if your mail software cant handle this then you should really not be putting any server on the internet
• Configure SPF on all of your domains
• If you are an active sysadmin, setup DMARC to another mailbox so you can monitor for suspicious activity
• Stay up to date and with the times