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!
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 tocmd.exe /c {task}
, which spawns a newcmd.exe
process on the target and returns the output viastdout
&stderr
.- Heavy reliance on Golang's
os/exec
andos/user
packages for cross-platform compatibility and built-ins (whoami
,pwd
,ls
), may be OPSEC unsafe. inject
usesCreateRemoteThread
and doesn't check for architecture, may result in the process and/or shellcode crashing- useps
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 ๐คก)