[DesktopECHO]

I'm not too surprised, as the malware goes out of its way to use ycxrl.com -- Going to extents like using 8.8.8.8 instead of the default DNS server, and trying a DNS server on port 5353.

Using those techniques, nobody would get a chance to see this second fall-back.

EDIT to clarify: Thanks for listing this, it's definately good to list these addresses as 'bad' for others to be aware, but DNS blocking won't slow down this malware, not even a bit.

Here's what it took for me to see cbpheback.com -- Install Pi-hole on the Android device and add these rules to iptables:

  adb shell iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 127.0.0.1:53
  adb shell iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 127.0.0.1:53
  adb shell iptables -t nat -A OUTPUT -p tcp --dport 5353 -j DNAT --to 127.0.0.1:53
  adb shell iptables -t nat -A OUTPUT -p udp --dport 5353 -j DNAT --to 127.0.0.1:53

[ignoramous]

> ..but DNS blocking won't slow down this malware, not even a bit.

Yep, in a world of encrypted DNS transports, it is a folly to believe that DNS-based blocks would be affective at thwarting any sort of malware. That said, some IoC (indicators of compromise) setups do rely on it nevertheless.

[dylan604]

just because something new comes along doesn't mean you stop doing the thing that worked for all of the older/existing things. otherwise, the existing things start working.

you make it sound like people dumb for relying on something that works in certain situations. that's just hubris on your part if that's what you actually feel.

[ignoramous]

You make it sound like I compared DNS-based security to snake oil. That's just futuristic thinking on your part (:

[dylan604]

>setups do rely on it nevertheless.

this is where I'm drawing my conclusion. no snake oil accusations necessary. the sentence is read with an implied "nevertheless, [dumbasses|idiots|noobies]" type of ending