Some very interesting information continues to make its way to me. Here's the topics du jour:
- Partial Netcraft Forgiveness
- Malware Analysis
- Verizon Wireless - Shady happenings
Partial Netcraft Forgiveness:
I just want to throw Netcraft a bone here and let them know that, while I still think their scorched earth policy really sucks for the site operator, it does accomplish its mission. Had I been on their team, I might do the same and call the site operator an incompetent loon (despite the fact that it is nearly impossible to defend against a veritable army of ne'er-do-wells ranging from skill levels of "in their mom's basement" to "state funded actors".) I'll discuss this more in the next section but yes, the malware they identified was indeed malware, very sophisticated too, and perhaps it was best that they tried (and failed, by the way, thanks to my redundancy systems) to prevent access to it.
No forgiveness to OVH, by the way. They're still morons.
Malware Analysis:
Here is a sample of the reports I got that gave me a clue as to why they thought what they did and why Clamscan didn't catch shit:
https://incident.netcraft.com/7a0/7a033604c0a7/
Yes, it was malware. It was the intermediate stage of a (unconfirmed info) very sophisticated Korean banking trojan. It was not, itself, executable, it was actually meant to be pulled once a suitable loader, executable, or exploit was popped on a machine, because the file itself without a decrypter/decoder/interpreter is useless. You can get an idea of what was going on via the Netcraft report, and a few extra links I uncovered here:
https://twitter.com/luc4m/status/1432807697364230147
https://www.joesandbox.com/analysis/475297/0/html
I have a sample of the file if anyone is interested. I will not be publishing a public link to it.
My best guess of the perpetrators: https://www.riskiq.com/blog/external-threat-management/yanbian-gang-malware-distribution/
Verizon Wireless - Shady Happenings:
The information in the following section is unconfirmed, but certainly raises an eyebrow.
It would appear that, due to the malware incident, something has gone amiss with Verizon's DNS service for specifically Verizon Wireless customers. Based on my analysis, querying for "pomf.lain.la" on Verizon's default LTE DNS returns a false NXDOMAIN reply. Here's the data points I got that determine this to be the case:
- Resolving ghostbin.lain.la (or any other subdomain of mine) works fine on Verizon LTE, but resolving pomf.lain.la specifically does not.
- Switching cellular DNS on my Verizon phone to Google immediately fixed the issue.
- Switching to WiFi or any VPN also immediately fixed the issue.
- Attempting to use explicit DNS wildcard overrides had no effect (as a method to reconfigure DNS and kick loose the issue - didn't help so not a DNS config problem).
- Reports of this occurring are limited to a few dozen Verizon Wireless customers (that I know of, myself included) and nobody else.
- Traffic on pomf.lain.la continues to exceed 500 mbit consistently - meaning this is limited to a subset of users, such as Verizon Wireless users.
It is difficult to determine the Verizon LTE DNS servers and structure from an end user perspective. Android DNS resolution is all over the place when it comes to cellular networks. Using nslookup, dig, or any other standard query tool works fine, but try using the system resolver and you'll get an unknown host or NXDOMAIN error, so there's clearly another layer at play. DNS Leak tests provide an IP address that does not actually respond to direct DNS queries.
The only thing I can do is scream and shout from the rooftops at Verizon to see if they have some proactive malware protection system, or see if they are using a downstream source that automatically tabulates threat intelligence feeds (like from Netcraft!) and then contact them instead. I'll start working on that next. DNS is meant to be generally federated, as in the users can choose what servers to use and which servers not to use, hence why OpenNIC exists. This is also why a billion DNS services, filtered and unfiltered exist, and why VPNs exist. But when companies make the choice on behalf of the uncaring user that uses default DNS, it makes accessibility to my otherwise squeaky clean pomf clone tough when a company brings down the hammer. The joys of running this thing knows no bounds.
If anyone wishes to offer insight on what to actually DO about the above findings, drop me an email at 7666@lain.la. I'll keep poking the bear in the meantime.