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
Fantastic coverage of the Microsoft Storm-0558 post mortem from @lilyhnewman.
A few thoughts: 1. @msftsecurity is amazing. Investigations like this are amazingly complex and performed under pressure that few in the field will ever experience. 1/ wired.com/story/china-ba…
And long before the investigation, there's the planning. Ensuring you have the data, with the retention, to perform an investigation like this doesn't happen by accident. It requires planning. And it also requires diplomacy. *Lots* of diplomacy. 2/
Even at an organization that knows it's a target, there will always be discussions of "how much retention is enough."
Any incident response consultant will tell you this is a LOT of telemetry with impressive retention. It's not cheap to maintain this. 3/
If you're starting out in security and find the breadth of stuff you "need to know" daunting, I want to give you some perspective: 1. The field has broadened - dramatically. The "baseline knowledge" grows every year. Anyone saying otherwise is lying or uninformed. 1/
2. You don't have to "know everything" to make a significant impact. 3. All the people you are looking up to now stand on the shoulders of giants, whether they admit it or not. I know I sure do. 4. Stop measuring yourself by what you don't know. You'll never know it all. 2/
5. This is a field where you need to be comfortable with lifetime learning. Your skills will quickly become irrelevant (despite Microsoft's best efforts) if you stand still. 6. I spend at least an hour a day reading/practicing new skills. Still. It's my antidote to stagnation. 3/
More notes: I'm aware of the CBS story stating that their experts reviewed a copy of the Biden laptop with no modification. I presume they received their copy from a different source, since their findings are inconsistent from mine and @matthew_d_green. 1/ cbsnews.com/news/hunter-bi…
In the image I examined, it was clear from filesystem timestamps alone that files and folders had been opened and created long after it was abandoned at the shop. I'm confident any forensic analyst would see that, so it's easy to conclude we're looking at different evidence. 2/
I will also note that there's no forensic software that is built to identify intentional offline modification by a sophisticated adversary. That requires a lot of in-depth analysis and cross-view validation we don't have enough characters for here. 3/
Regarding the Hunter Biden forensic analysis: 1. I personally am not a fan of the fact that it took so long to get an independent analysis of the data. 2. I wish the evidence had been made available, without strings, to reputable media organizations in 2020. 3. It wasn't. 1/n
When political operatives shop evidence of a "bombshell story" weeks before an election, but dictate publication timelines as a condition of providing the evidence, skepticism is fully warranted.
Publishing without validation in that case is journalistic misconduct IMO. 2/
Whether you agree with what Twitter did in suppressing the story is a separate issue from the integrity of the evidence.
Anyone discussing the @nypost stories without acknowledging evidence was manipulated BEFORE being passed to the NY Post is being disingenuous. 3/
Your airline pilot started in a single engine Cessna. Nobody called it gatekeeping. And before that, they learned lots of "mostly irrelevant" facts in ground training.
Cyber is one of the only fields where we pretend that skipping the basics is okay to put butts in seats. 1/4
Do you really want an incident responder that doesn't understand the implications of a "non-standard" subnet mask (whatever that actually means, don't get me started)? Sure, it's only like .1% of IR where that's relevant, but just highlighting an example. 2/4
I don't have the answers for "how much knowledge is enough" for a given task. But given the number and cost of ongoing security incidents, I suspect that if we don't answer the question, regulatory (read licensing) boards will answer for us. 3/4
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.