Following on from @neurovagrant’s post in the same vein, I think it’s a good point of conversation for the community to share how they’re tackling this and similar problems, and what tools they’re using to achieve it.
From my perspective, I have always had greater-than-most agency over the length and breadth of the security controls I put in. To this effect, I’ve typically taken the following stance:
Deny by Default, allow explicitly (no, really, don’t roll your eyes)
This is hard. I get it, but it’s one of the only tools we have in our arsenal that’s largely cost-free (aside from time), and really, and I mean really hard to circumvent. But it needs to be layered up and down the stack.
If there isn’t a functional requirement for the behaviour. Disable it or block it.
Why does your finance team’s endpoint need access to GitHub or similar? That’s my point.
When we think about the TXT smuggling issue, how do you combat this?
Well, do your endpoints really need to fetch TXT zone file entries? Almost certainly not. This sounds terrifying in principle.
“You’re asking me to block a whole category of DNS requests?!”
Well, yeah. BUT…
Think about what a TXT record is used for:
- Email sender verification
- Domain Validation
- Delivering fileless malware payloads to your endpoints
- Not much else
Per the RFC a TXT record should be no longer than 255 characters. ‘Should’ being the operative word. Many providers are more permissive, or allow nesting with escaped characters to accommodate what I can only assume is absolutely cursed technical debt in the bowels of some well known software vendor we definitely all trust.
It’s basically a free text field. Have at it. Cue DooM-over-TXT.
An end user compute would almost never need to fetch this information. In fact, I’d wager that most of your server infrastructure doesn’t either. Seriously, go pull some numbers, I think you’ll be surprised.
Deny proactively
Here comes the difficult part. We are limited by the tools at our disposal. How we approach this in a layered fashion is entirely down to that. I’m interested in how others handle it
I’m hard-line on this. If a device doesn’t need a service or software installed, it shouldn’t be. If it doesn’t need to communicate on a protocol, it shouldn’t. Same with config, the settings exist to make most endpoints pretty water-tight before we even look at actual security tooling.
But specifically regarding the TXT issue?
- Native OS host firewall usually can’t discriminate on DNS type
- EDR host firewall (usually piggybacks OS, but useful as a policy enforcer)
- Application firewalling (the ones I’ve seen in action to varying degrees of success)
– Windows Applocker (deprecated)
– Windows Application Control (Kernel Level)
– Threatlocker (Kernel Level)
– Carbon Black (depends on implementation)
– Heimdal (Application level) - DNS resolver blocking
– Windows Server DNS Policy can ignore TXT requests in lookup zones
– Bind can do similar - North/South, East/West firewalling. Inspecting and dropping based on request
- SASE solutions typically allow these sorts of blocks
All of the above ignore DoH/DoT.
You’re probably wondering why I’m not including correlation-based solutions here. Well…
Reactive-as-failover
EDR solutions are great at some things, but not so great at most others. Many EDR bypasses exploit armed and disarmed states of the running service, there is a point, no matter what your favourite vendor will tell you, that endpoint protections are disarmed, until they’re not.
I’m generalising here, but properly configured OS-level config controls are set that way, and don’t typically need ‘activation’ before being, well, active.
I see EDR as the auxiliary necessary evil that should, in theory catch the things that fall between the cracks.
Reason being, if you’re using a modern EDR/SIEM/Money Pit, you’ll likely know the scenario…
- Event happens. Allowed.
- Event happens again. Allowed.
- Even happens a third time. The walls are closing in, the sky is falling, this is in fact The Rapture, call the Power Rangers.
Unless you’re explicitly setting correlations and blocks, there’s a good chance that the bad thing will happen before being blocked by your 100 bucks and endpoint tooling stack
So a few rules and runbooks wouldn’t go amiss.
Anyway, just a short post to get the conversation going. I could talk in detail about the rest of this, but I’ll refrain on this occasion.
Thoughts, feelings, limericks, and folk songs welcome.