Microsoft Support Diagnostic Tool

What the tool does and why that matters

Microsoft Support Diagnostic Tool is a troubleshooting utility that gathers system facts, logs and configuration data into a support package. Its value comes from breadth, because support engineers can inspect a single bundle instead of asking users for scattered artefacts.

That same breadth creates handling risk: diagnostic bundles often include more than the visible problem description, so the package can become sensitive evidence in its own right. A collector built for support can therefore be useful, but it should be treated as content-rich diagnostic material rather than a harmless transcript of a fault.

What can be captured in a support bundle

Diagnostic collection tools typically pull from multiple layers at once, including application logs, Windows event data, network settings, registry values, installed component details and traces that help reproduce a fault. When those sources are combined, the package can reveal operating context that would not be obvious from a single log file.

For that reason, the security issue is often not the collection itself but the scope of what gets captured. A support archive may include account names, host details, internal endpoints, session artefacts or tokens that were present during troubleshooting, which makes careful scoping and review important before anything leaves the endpoint.

Exposure paths and handling assumptions

The risk is usually introduced after collection, when the bundle is stored, attached to a case, shared with a third party or moved into a ticketing system. If the package is copied without review, the organisation may unintentionally disclose sensitive operational data to people who only needed the original fault description.

That is why support utilities should be treated as data-moving tools as much as diagnostic tools. A package that is safe to create can still be unsafe to transmit, especially when it travels outside the endpoint owner’s direct control or lands in a support queue with broader visibility than intended.

How to think about secure use of diagnostic tools

Use the output as evidence, not as a convenience file to distribute broadly. The practical question is whether the bundle is being reviewed, minimised and sent only to the party that needs it, with any secrets, sessions or other sensitive artefacts removed or redacted before onward sharing.

If a diagnostic archive is retained for longer than necessary, it becomes another sensitive record that must be governed like other operational evidence. That means limiting access, reducing copies and remembering that support material can outlive the incident that created it.

Risk and Threat Considerations

Support bundles are attractive because they concentrate useful troubleshooting data in one place, but that concentration also makes them valuable to an attacker or careless recipient. If the collected package contains credentials, session details or internal configuration, a single mishandled export can create a broader exposure than the original fault.

Failure mechanism: The tool gathers high-value artefacts for diagnosis, then the package is copied, forwarded or stored without review, allowing sensitive material to escape the intended support boundary.

Impact: Exposure can enable account compromise, session replay, internal reconnaissance or further social engineering, especially if the archive is shared through email, ticketing systems or third-party support channels.

Practitioner Guidance

Why practitioners should care: Troubleshooting tools are often granted trust by users and help desks, which makes their output easy to overshare. The operational judgment is to treat the resulting package as sensitive evidence and to decide in advance who may receive it, how long it may persist and what must be removed before transfer.

What to watch for: Large diagnostic exports, ad hoc sharing through chat or email, and bundles created during account or authentication incidents deserve extra scrutiny because they are more likely to contain material that should not leave the endpoint unchanged.

Related resources from NHI Mgmt Group

• Is CVE-2022-34713 (Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution) being exploited in the wild?
• Is CVE-2022-30190 (Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution) being exploited in the wild?
• How do you patch or mitigate CVE-2022-34713 (Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution)?
• How do you patch or mitigate CVE-2022-30190 (Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution)?