A Day Phishing

Scripting Interpreters

Interpreters are a great method to achieve command or shellcode execution

• Are not Native to Windows

• Not always easy to use

• Limited to command or shellcode execution, some have both!!

• We require these to not be installed on the Users workstation

Python

Python is a strong language to demonstrate the capabilities of these interpreters the following screenshot demonstrates how just printing out STRINGS in their language will not get flagged, it seems that this behavior is caused because AMSI has a better grasp on Windows Native Files see the example below:

Python AMSI Test

To make python feasible to our needs we have to consider this:

• Size

• Modules

• Version

  
  

A compiled portable version of python will give us enough for execution such as the following:

Python simple execution

We encounter the issue that some Modules are missing when trying to go beyond to executing Win32 API's now the challenge is to:

• Compile a portable version with the needed modules

The idea for these techniques came from this Stack Overflow post.

stackoverflow.com

How to make python portable?

I want to make a portable app that would have some code and python executable that would run on any Windows even if python is not installed. I would like it to be python 3.6 and so it has only pip...

Now with some debugging and lots of banging the portable version of python works correctly and the modules that I needed were in the binary

python.exe -c "import ctypes; MessageBox = ctypes.windll.user32.MessageBoxW; MessageBox(None, 'Hello, this is a simple message box!', 'Message Box', 0x40)"

Python and Win32 API's

With this fully functional we can utilize the portable version of python, a loader and call our payload, since the files and binary won't run our files via double-click we need to use a file format or program that will call these, and a great alternative is LNK files

ADS

Alternate Data Streams store additional information about a file, such as metadata or comments, without changing the file itself APT actors are known to use this Data Stream to deliver payloads, now we will use this to deliver our Initial Access attachments

Now when delivering payloads with ADS we encounter some issues:

• Data is stripped if sent remotely

• ADS cannot be reached via double-click, or can it?!

• We need another parent file to call our ADS Stream

With these in consideration we can see how ADS works first in the image below will demonstrate how a TEXT file sent over the internet is stripped away from its ADS data when sent from A -> B

ADS Data

Once the ADS data was being removed, it was considered a useless techniques but with a little more research we found out that the ADS data can be contained in certain container file formats, which were WinRAR files and WIM files (Created via 7z).

WinRAR Advanced Tab

7z options

In the previous screenshot we demonstrate how WIM files do not strip the data if told by 7z and WinRAR has the option to keep the Data stream from files, with this we have a method to hide our payloads in ADS, now to get a full demo on this technique will use a script file (BAT) to grab the ADS data and reconstruct it to build our Initial Access Payload and when taking a look at the ADS, there is no Zone.Identifier on the payload

ADS Technique

WSL Files

When looking into possible new file formats for Initial Access, one really grabbed my attention. By using the following PowerShell one-liner, you can find file extensions available on the workstation. When reviewing the results, you might notice that some extensions do not have a designated program for execution:

Get-ChildItem Registry::HKEY_CLASSES_ROOT | Where-Object { $_.Name -match '^.*\\\.' } | ForEach-Object { $_.PSChildName }

From the output, the WSL file extension was interesting. We are already familiar with WSL as the Windows Subsystem for Linux (WSL), which allows developers to run a GNU/Linux environment on Windows. While powerful, WSL is traditionally limited to terminal-based interactions. Users can run Linux on the Windows workstation with some capabilities that are limited to the terminal. Reading the documentation for WSL, I found an interesting paragraph highlighting WSL file extensions.

To create a weaponized WSL file, three components are required:

1. An OS (root filesystem)

2. A WSL configuration file

3. A payload that connects back to a C2 server

   
   

Initially, I was concerned about the file size. My first demo was around 100MB, which was excessive since I didn't need full OS capabilities just a way to run a command or payload. Thanks to a tweet, I discovered Alpine Linux, a great choice due to its minimal file size (8MB).

The WSL configuration file, which only needs the [oobe] tag and a default name to function. This config file must be placed under the /etc directory.

[oobe]
defaultName = CalcWSL

This part was tricky. While the WSL config file supports a command tag, it didn’t reliably execute across distributions (Ubuntu, Debian, Alpine).

For example:

• Debian: I could simply replace the .bashrc file with my commands/payload and it worked.

• Alpine: This didn’t work on the first run. To make it reliable, I had to modify the passwd file.

By editing the passwd file, I ensured that every time the WSL instance launched as root, it would execute a script instead of opening a shell.

Modified /etc/passwd line:

root:x:0:0:root:/root:/root/launch.sh # <- Path to Script

And the script simply contained a one-liner calling executing the beacon

#!/bin/sh
exec /root/beacon_x64.exe 

Once you have:

• The OS (e.g., Alpine Linux)

• The wsl-distribution.conf configuration file

• The payload and launch script

You can compile everything into a WSL compatible tarball:

tar --numeric-owner -cf Alpine.tar -C /tmp/alpine/ .

This results in a small .tar which we simply rename to the WSL extension.