Windows Attachment Manager risk: verify user policies before changing prompts

What Is Windows Attachment Manager Risk?

Windows attachment manager risk is a file-handling policy question: which attachment receives a prompt or a block, for which user, in which application? A GPO inventory can identify settings worth reviewing, but closing the review requires evidence from the intended user workflow.

Two situations need different decisions. An inventory containing neither DefaultFileTypeRisk nor LowRiskFileTypes raises a question about explicit configuration. A policy selecting a low default risk or adding script extensions to a low-risk list raises a question about an explicit exception. Treating both as proof that every downloaded script runs silently would overstate the evidence.

This guide uses Microsoft Learn documentation and the reviewed etc-collector code. The Windows commands below are documentation-based reading examples, not commands executed against a Windows environment for this article. The pilot procedure is a proposed verification method; no successful test, affected workstation count or attack is claimed.

How It Works: Defaults, Lists and Application Context

Microsoft's Attachment Manager policy reference places these settings under User Configuration > Administrative Templates > Windows Components > Attachment Manager, with risk/list mappings in Software\Microsoft\Windows\CurrentVersion\Policies\Associations.

Its documented behavior distinguishes three risk classes:

An unconfigured or disabled default-risk policy retains moderate risk. An unconfigured low-risk policy retains default trust logic. Custom high-risk inclusion takes precedence over medium and low inclusion; medium precedes low. Low inclusion overrides the built-in high-risk list, so custom-list overlaps matter. Default trust logic prefers the handler; the separate trust-logic policy can change that assessment. Microsoft policy definitions

Application context is also part of the mechanism. Microsoft's IAttachmentExecute reference describes an interface used by client applications, including policy checks, prompts, save and execution operations. SetSource supplies source information and SetReferrer supplies zone context; the client also has its own attachment settings. This does not establish that every application uses the interface identically.

For a review, identify the application that receives the file, the action the user performs and the provenance available at that point. A finding cannot fill those gaps. Do not move from a domain-level policy string to a claim about an unknown browser, mail client, file association or launch path.

Detection: Inventory User Policies and Compare the Pilot

Step 1: Preserve the GPO configuration

Inventory the relevant GPOs before editing. Record each GPO's identity, links, user scope, filtering, collection time and raw policy values. Inspect User Configuration and decoded User\Registry.pol, rather than assuming a computer-policy report contains the attachment settings. Preserve any contradictory configurations for reconciliation.

The review worksheet should include:

Keep missing, empty, uncollected and failed reads separate. In particular, the parser used by the two EtcSec checks does not retain an empty LowRiskFileTypes string. A missing parsed field is therefore insufficient to reconstruct the original policy state.

Our four Active Directory GPO security checks explain the same discipline for other settings: retain configuration, identify the receiving scope and verify client evidence. Their LLMNR, WSUS, LSASS and UNC controls provide a useful review method, while this investigation concerns user attachment handling.

Step 2: Retrieve the target user's policy result

On the pilot computer, use the intended user's session and obtain the user-scope summary:

gpresult /scope user /r

For a more detailed record, run this separately:

gpresult /scope user /z

Microsoft's gpresult reference documents user scope, summary output and detailed policy output. Resolve disagreements between the GPO inventory and the reported result before interpreting local values. Preserve errors as errors; an unavailable report cannot stand in for proof that the intended GPO applied.

Step 3: Read the user registry values

Run each command separately in the intended user's context. These examples combine Microsoft's documented reg query syntax with the Associations key above:

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v DefaultFileTypeRisk

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v LowRiskFileTypes

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v HighRiskFileTypes

HKCU identifies the current user's hive. Running the query as a different administrator changes the subject of the observation. Retain the command, account, host, time, value type and output; distinguish an absent value from a command failure. Compare those reads with the owning GPO and policy result instead of replacing a missing output with an assumed safe or unsafe value.

Step 4: Compare configuration with observed handling

Define an authorized pilot with benign representative files and application owners. Record extension, provenance, zone information where available, receiving application, selected action and whether access was blocked, prompted or allowed. Retain unexpected results for investigation; do not insert an expected prompt into the record as if it had been observed.

Use a matrix with one row per tested workflow. Include a before/after configuration reference and the actual result. A result obtained through one mail-client action supports that specific observation; it does not demonstrate every local launch path or every user population. These sources do not establish a universal Windows Event ID for this configuration review.

Remediation: Review Exceptions Before Changing Prompts

Step 1: Assign ownership to the configuration

Identify the administrator responsible for the winning user policy and the owners of applications requiring exceptions. Bring the raw default value and all relevant inclusion lists into the same review. Keep the initial export so the decision can be traced to a real configuration rather than a shortened finding description.

Classify the case as absence of explicit configuration, explicit weakening, conflicting policy or incomplete evidence. Do not apply the same corrective action to all four. An absent setting needs a decision about intended behavior; an existing exception needs justification and compatibility review; a collection failure needs a successful measurement.

Step 2: Remove unjustified weakening in a pilot policy

For a GPO-managed pilot, review Default risk level for file attachments and the inclusion settings at the Attachment Manager path above. Review DefaultFileTypeRisk = 6152, the value tested by the weakening detector, and every script entry in LowRiskFileTypes. Remove unjustified exceptions through the owning policy and document any retained dependency.

Choose the intended default and lists after reviewing the application and provenance requirements. Avoid substituting a blanket low default for an application-specific compatibility decision. Check custom high and moderate inclusions alongside low entries before predicting the result. The presence of a script substring in the collected low string is a review trigger, not a complete Windows risk evaluation.

Step 3: Recollect user evidence and exercise the workflow

Repeat the user-scope gpresult and registry reads after policy application, using the same pilot identity. Re-run the agreed benign workflows and record actual outcomes with application owners. If the configuration changed but the observed behavior did not match expectations, investigate the application path, provenance and policy conflict before expanding deployment.

Step 4: Maintain complementary execution controls

Attachment risk policy alone cannot establish comprehensive script control. Our Defender ASR rules via GPO guide covers complementary behavior rules, with endpoint rule identifiers, actions and exclusions verified separately. A successful attachment-policy review does not validate ASR or AppLocker.

Close the scoped remediation only with the policy decision, resulting user configuration, reviewed application behavior and exception ownership attached. Keep broader deployment coverage as a separate evidence question. A completed GPO edit or a changed collector count does not demonstrate fleet-wide protection.

How EtcSec Detects This

The two reviewed etc-collector implementations are Medium GPO checks. They inspect collected registry fields, with these exact branches:

For the second check, the tested substrings are .hta, .js, .vbs, .wsf, .wsh and .ps1. The code adds one reason for default risk 6152 and one combined reason when any of those substrings occur. Several matched extensions still contribute a single list reason. This is substring matching, not strict extension-list parsing; a longer token containing .js, for example, can match.

Each field is selected independently. The detectors search Machine registry settings first and consult User settings only if the Machine result for that field is nil. The Machine helper prioritizes Default Domain Controllers Policy, then Default Domain Policy, then another available GPO. The User helper returns the first non-nil value encountered in a Go map. That map traversal supplies no stable Windows policy precedence.

The registry parser maps a valid DWORD named defaultfiletyperisk under a key containing associations; it maps lowriskfiletypes only when the parsed string is nonempty. The reviewed checks do not evaluate the high or moderate inclusion lists, client trust logic or application behavior. Because the two fields are selected separately, their values can also originate from different GPOs.

Any non-nil value in either selected field suppresses the absence count, without validating its security. Likewise, a zero weakening count does not establish complete collection, correct policy application or safe attachment handling. Neither check measures universal execution without warnings, validates AppLocker or ASR, or demonstrates fleet security. Neither finding establishes an attack.

Use the finding to open the scoped review described above. Keep policy inventory, user-result evidence and the pilot's actual observations together so the editor or administrator can distinguish a configuration signal from a demonstrated behavior.