Brian Krebs published this very detailed article today:
While AWS and Azure were referenced specifically, it isn’t particular to just them. This happens also with Cloudflare that fronts many scam operations. Just like Amazon and Microsoft, upon receiving notices of broken terms of service, they typically respond quickly, but not always as I’ll show you with a specific example.
DNS as the root of trust
With Zero Trust connectivity, the ADAMnetworks application of the Principle of Least Privilege as it applies to egress traffic, one way to view it is to look at it as DNS as the root of trust.
It is a combination of all of these properties:
- Protective DNS resolver offering DNS resolutions to verified destinations only (this is what adam:ONE does)
- DNS clients use encrypted DNS (adam:ONE is RFC9462 compliant and offers DoH and DoT to internal endpoints)
- Any traffic which did not begin with a permitted DNS query is blocked (we call it Don’t Talk To Strangers)
Let’s explore how this would work with an actual Pig Butchering Scam that uses the same Infrastructure as a legitimate website. Incidentally, this site has been operational for over six months and Cloudflare is still protecting them at the time of this writing:
app\.mhbcoin.com
For comparison, let’s use a random domain that is a legitimate offering that uses the exact same Cloudflare service:
www.virginlimitededition.com
Both of these FQDNs resolve to this IP address of Cloudflare public IPv4 frontend:
172.64.80.1
Let’s see how a regular user of Zero Trust connectivity is protected by using DNS is used as a root of trust, a protective resolver and policy that simply doesn’t resolve unverified destinations:
curl -v -k https://app.mbhcoin.com
* Could not resolve host: app.mbhcoin.com
* Closing connection
curl: (6) Could not resolve host: app.mbhcoin.com
However, let’s say that it attempts to connect directly by IP address like this:
$ curl -v -k https://172.64.80.1
* Trying 172.64.80.1:443...
* Connected to 172.64.80.1 (172.64.80.1) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* LibreSSL/3.3.6: error:1404B410:SSL routines:ST_CONNECT:sslv3 alert handshake failure
* Closing connection
curl: (35) LibreSSL/3.3.6: error:1404B410:SSL routines:ST_CONNECT:sslv3 alert handshake failure
Whether by domain or directly-by-IP, the connection fails as it should.
And yet, if attempting to visit a legitimate website at that infrastructure, no problem:
$ curl -v -k https://www.virginlimitededition.com
* Host www.virginlimitededition.com:443 was resolved.
* IPv6: (none)
* IPv4: 172.64.80.1
* Trying 172.64.80.1:443...
* Connected to www.virginlimitededition.com (172.64.80.1) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
* subject: CN=virginlimitededition.com
As an aside, what makes the pig butchering scams like this work is that they are highly sophisticated by allowing invitation-only signups and then offer a mix of real and fake currencies. There’s always a WhatsApp “professor” that guides the victims (and bots that appear have had huge wins) to buy crypto currencies with leverage. Confidence is built with some actual long or short positions with the likes of BTC and ETH, the victim is then convinced to go all in on a “whale alliance” trade of a never-before-seen coin and gets rug-pulled at a time when they’re all in. Here’s an example of the rug-pull that happened to one of their victims:
This IHTA coin is fake as is the entire trading history. Take a look at where this victim was liquidated with a fake drop in the coin price in the middle of a leveraged long position.
Note that we specifically are not IP-blocking. Sometimes IP-based blocks are an additional defense in depth, but that’s not what is relied upon here.
Conclusion
Infrastructure Laundering is a technique that need not be successful as long as leak-proof egress control is applied, which is finally practical.