## TL;DR
HTML smuggling hides the payload as encoded blobs inside an HTML file; the browser assembles it after delivery, so the attachment itself contains no recognisable malicious file. Sandboxes must execute or emulate the script and observe the generated download or page. Check whether your sandbox analyses HTML attachments behaviourally, enable script analysis, and treat external HTML attachments as a high-risk type in policy.

```text
html smuggling attachment failed to detonate in sandbox
```

## Use this when
- An HTML attachment opened to a fake login or triggered a download the sandbox never reported.
- The sandbox report on an HTML file shows no script execution.

## Not for this skill when
- The HTML attachment is a legitimate report export from a known internal system. Scope exceptions to that sender.
- The payload was a conventional executable attachment. Standard detonation handling applies.

## Steps
1. Submit the sample HTML to the sandbox and read the full report for script activity, blob construction and generated files. Verify: whether behavioural analysis ran is proven.
2. Check policy for HTML attachments from external senders, including whether they are in the detonate list at all. Verify: HTML is explicitly covered or explicitly exempted, by decision.
3. Enable script and behavioural analysis for HTML in the sandbox, or quarantine external HTML attachments if your tier cannot analyse them. Verify: the setting is active for the test group.
4. Search for other copies of the campaign by attachment hash and sender, and purge delivered copies. Verify: no unanalysed copies remain in inboxes.
5. Re-test with the original sample through normal mail flow. Verify: the new analysis reports the smuggled content or the message is quarantined.

## Variant phrasings
### html smuggling attachment sandbox behavioural analysis
The behavioural variant.
### smuggled html phish page blob download detection
The technique variant.

Compatibility: Gateway sandboxes with HTML script analysis, Defender Safe Attachments file type coverage.

## Why it happens
The attachment is a builder, not a payload, so signature and static checks see encoded text. Only execution reveals what it builds, which is why smuggling was designed to move assembly to the endpoint, past the detonation step.

## Edge cases / pitfalls
- Data URIs and blob downloads in the sandbox report are strong indicators even when the final payload is not retrieved.
- Some business systems legitimately send HTML reports. Whitelist by authenticated sender, never by file type alone.
- User guidance matters: an HTML file in mail should be treated like an executable, because functionally it is one.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Xj3XjeWTbbs26TDuwQSuTg