Winton is an open-source cross-platform C2 framework written for the purposes of learning adversary emulation and C2 infrastructure.

🐒 Winton was designed solely for educational purposes, it is still nowhere close to being operationally functional for red team engagements!

• Winton
  • Table of Contents
  • Features
    • Teamserver
    • Implant
    • Client
  • Installation
    • Teamserver
    • Implant
    • Client
  • Usage
    • Teamserver
    • Client
  • OPSEC Considerations
    • Implant
    • Client
    • Teamserver

Written in Golang 1.21.1 with Gin (stable on Windows 11 x64/AMD64 & Debian 12.x / Kali 2023.3)

• Support for multiple listeners (HTTP implemented)
• Multiplayer-mode
• Cross-platform binary

Written in Golang 1.21.1 (Windows only*)

• Process migration and process injection
• In-memory .NET assembly execution (creds to: @ropnop)
• Built-ins via os/exec & os/user

Dark themed UI written in Python with Tkinter

• Multi-player
• In-memory .NET assembly execution via execute-assembly
  • creds: SharpAwareness by @CodeXTF2
  • for some reason, if you try to load .NET assemblies that are too large, the CLR will just not load lol.
• Updated list of supported commands available: here

git clone https://github.com/gatariee/Winton
cd Winton

cd teamserver
make linux # or windows
cd ./bin && chmod +x ./teamserver-x64

cd ./implant
make windows

cd ./client
python3 -m pip install -r requirements.txt
chmod +x ./winton.py

./teamserver-x64 <ip> <port> <password>

./winton.py

• The stable implant is written in Go and produces a binary of ~7,747,072 bytes, or ~7.38MB.
• shell pipes the input of the operator to cmd.exe /c {task}, which spawns a new cmd.exe process on the target and returns the output via stdout & stderr.
• Heavy reliance on Golang's os/exec and os/user packages for cross-platform compatibility and built-ins (whoami, pwd, ls), may be OPSEC unsafe.
• inject uses CreateRemoteThread and doesn't check for architecture, may result in the process and/or shellcode crashing- use ps to check for architecture before injection.
  • VirtualAllocEx is called with PAGE_EXECUTE_READWRITE & unbacked memory allocation
  • Thread start address is 0x0

⚠️ Beacon instability mainly caused by the implementation of task queuing and tagging in the teamserver, there is a permanent race condition between the teamserver and the implant that causes the implant to crash if the teamserver sends a task to the implant while the implant is still processing a task.

• Unencrypted communication with the teamserver over HTTP
• Authentication with teamserver not implemented yet
• Interacts with the listener rather than the teamserver, the operator should be interacting with the internal teamserver API instead of the listener. (modularity)

• Unencrypted communication with the implant over HTTP
• Teamserver expects agent to be legitimate and doesn't check for authentication (in fact, the password param used to start the teamserver is completely unused 🤡)