Discover and read the best of Twitter Threads about #msdt
Most recents (2)
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.
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.
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/
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/
5. The expand command unpacks the .cab 3/
