Okay, so playing the #msdt 0-day a bit and here's what's happening: 1. The maldoc contains a linked HTML document 2. Word automatically retrieves the linked HTML document, which contains JS to reset the location to an ms-msdt protocol handler, which is present by default 1/
3. The protocol handler launches msdt, which launches a command using the IT_BrowseForFile parameter. The maldoc that triggered this whole event invokes this code (newlines and comments added). The doc was likely distributed with a .rar file. 2/
4. I don't have the ".rar" file, but we can still tell what it's doing. The findstr command is looking for "TVNDRgAAAA" which means it's looking for a base64 encoded string beginning with "MSCF" which is the file header for a .cab file. 5. The expand command unpacks the .cab 3/
6. The .cab file contains a file named rgb.exe, which is ultimately executed.
People have obviously found pieces of this before. This blog post discusses other URL handlers. I'm betting these are going to get a LOT more scrutiny in the coming days. 4/ blog.syss.com/posts/abusing-…
While researching msdt parameters used, I came across another blog noting the potential to abuse msdt. This post implies the action requires a user click (and as written, it does). Embedded in a word doc, it's zero click. 5/ sec.ud64.com/1-click-rce-in…
Here are the arguments to msdt (indented for ease of reading). The only two arguments I've found that are absolutely necessary to abuse the msdt handler *outside of word* are:
* IT_SelectProgram=NotListed
* IT_BrowseForFile=h$(<PowerShell>)
If you omit IT_SelectProgram=NotListed you won't get execution and will instead get a popup asking how you should be opening the file.
If the user just selects the default action, you'll still get execution. 7/
This only works because of the handler in HKCR\ms-msdt. If you delete this key, users will see the following if they open a payload document. Note that I haven't tested this to know other impacts but it absolutely prevents exploitation with known #msdt samples. 8/
You should probably be doing some detection engineering in your environment to understand how and where msdt.exe is used (e.g. what are the parent processes).
Also, the maldoc uses mpsigstub.exe, a legitimate Defender exe that is often excluded from logging. /FIN
The new #msdt 0-day can be mitigated by removing the protocol handler for ms-msdt (reg delete hkcr\ms-msdt /f).
Disclaimer: I haven't checked for impacts in a large production environment, but seems better than being exploited. MSDT is just a diagnostic tool, so likely safe.
When I say "haven't tested" I mean for second order impacts. I've tested that this is 100% effective as a mitigation.
FYSA. I haven't seen this on my test system yet, but in any case I'm still okay recommending removing the handler until I have another mitigation. Considering there will likely be a patch for this released long before relicensing is required.
I've had a chance, or let's say many catalysts, to think about friendship and what it really means.
True friends:
* Take that call even when it's not convenient
* Don't judge, because let's be real - we've all been there
* Try to make you laugh even when you'd rather not 1/
* Don't view things as transactional (e.g., what am I getting out of this?)
* Just listen if you need to vent
* Tell you the hard truth you honestly don't want to hear, even when they know speaking truth can harm the relationship
* Exemplifies empathy
I could go on, but... 2/
I've certainly failed at many of these points over the years.
Going forward, I'll be trying to do all these things in my friendships. If I've failed you specifically, I'm deeply sorry. If you've been there for me, I'm eternally grateful. 3/
In security, we talk a lot about CIA (confidentiality, integrity, and availability). Most of us also recognize the vast majority of the industry only cares about availability. When I call people on this, they always protest. This morning a great retort for this hit me. 1/
How often does IT refuse to update a security control (e.g. EDR agent) without testing because it might cause a compatibility issue (availability) and break something? Happens ALL THE TIME. "Can't upgrade until we test in every business unit for issues." 2/
But once the software is upgraded, how often do you see teams say "okay, now that we've updated, let's validate it's still catching everything we expect it to?" Almost never. We delay upgrades/updates, often increasing risk of a compromise to maximize availability. 3/
PSA 🧵 A threat actor "preparing for destructive cyberattacks" looks identical to "gaining access for intelligence operations." Like 100% identical. So much so that you *cannot* tell the difference. Be wary of anyone claiming they "know" a destructive attack is being prepared. 1/
Be similarly skeptical of anyone who claims they're sure a destructive attack *isn't* coming in a given situation.
I heard one such argument because "we saw them exfiltrating data, it's intelligence collection." If they're burning the network down, of course they'd exfil. 2/
In fact, it's intuitive to think that bulk intelligence collection could even accelerate before a destructive attack. They won't likely regain access to these networks in the immediate future and there's no incentive to be low and slow at this point in most cases. 3/
Quick 🧵on yesterday's FBI partial takedown of #CyclopsBlink. 1. Even for privacy types who fear government overreach (like me) this was a net positive. We should seek to degrade nation-state threat actor capabilities where it is possible to do so without collateral impact. 1/
2. The fact that WatchGuard assisted in the operation is critical. Obviously they have a vested interest in helping, but that's beside the point. It provides a level of private sector oversight that's often lacking in government operations. 2/
Now I'm mot an idiot. I know the FBI gets the final say in anything being done. But if they were abusing this access in any way during the op, there's a 1000% chance that will eventually leak given the private sector involvement. 3/
If you were starting a CTI program from the ground up at a new organization, what's the first thing you'd do?
I wasn't poisoning the well with an answer yesterday, but here we go: 1. Identify the *real* stakeholders (often harder than it seems) - who is my executive sponsor? What do *they* care about? 2. Ask what types of products they will find valuable. 1/
3. Create a formal charter documenting what my left and right limits of fire are (scoping the project) 4. Get the executive sponsor to agree to the charter (or adjust it until they do) 5. Work with stakeholders to determine PIRs 6. Document all PIRs 2/