阿塔卡 - 快速运行漏洞利用。

项目说明

Ataka

Runs exploits, fast.

> See .env for ctf selection. See ataka/ctfconfig/ for ctf config code. This directory is mounted into the docker container, not copied. Edits can be applied .

> Check out the cheat sheet file for the most important commands as a quick TL;DR after installing

Server

1. Edit .env file to set:
- DATA_STORE: Absolute path to a folder to store player exploit related files.
- USERID: The user:group id tuple to use for ataka. Note that write access write access to both the docker socket and the data directory has to be provided. You'll want to set this to the user id of the owner of the data directory and the group id of the docker group.
- CTF: The name of the ctfconfig to use.
2. Edit the ctfconfig in ataka/ctfconfig/
3. Run docker-compose up -d --build

> The ctfconfig is mounted into the containers. When editing the config while ataka is running, run ./ataka-cli reload to hot-reload the ctfconfig.

Player-CLI

The player-cli is a tool written in python to help players interact with *ataka* and create, upload and manage exploits and targets.

Setup

The player-cli is a .pyz file (Python Zipped Executable).

> This only needs to be done once.

Reloading Player-CLI

When the ctfconfig is modified and ./ataka-cli reload is run, the local offline copy of the ctfconfig needs to also be reloaded. For that run:

This o the old player-cli with the new one.

How to write an exploit

An exploit can be any executable or script.

It will receive two en :

Your exploit should print the captured flags.
They will be matched by a regular expression, so the output doesn't have to be clean.

Create and template a new exploit

This asks you for a template. Choose one.

As a next step, it asks you for the directory. If the current directory is empty, it skips this phase and just generates the exploit here, elseways lists the contents and prompts for a path.

Then it asks for the service and exploit name.

Finally it asks for your name. Give your username, or real name; this is for the sysadmin to identify you in case your exploits mess up.

This templates a new directory, creates a remote exploit, and stores the metadata into .ataka

Testing a local exploit

Get the name of your service:

Run the exploit:

Where:

This will test the exploit against the NOP team: exploit runlocal is supposed to be used for testing, not for actual attacks, which should be centralized to allow the captain to manage them.

By default, all output will be shown, to limit this, use the -l/--limit flag.

If you only want to run a fixed number of attack rounds, you can use -c/--count (e.g., -c 1 is a one-shot attack).
By default, the command attacks fore manually terminated.

Instead of an executable, you can also specify a directory containing a Dockerfile.
The runner will try to execute the command from the Dockerfile (locally, outside Docker), with the specified directory as the working directory.
This is useful in combination with exploit download, described in the next section.

The local runner can run exploits against the real targets (--all-targets, or subsets via -T/-N).

Deploying a centralized exploit

To run on the centralized attacker, exploits must be wrapped in a Docker container and uploaded to the server.

The CLI provides templates for common containers, see the abo.

If you need it, you can edit the Dockerfile to specify e.g. custom (e.g., python:3.12-slim, ubuntu:20.04, and so forth).

To upload your exploit directory:

This will take care of uploading the exploit.
It also launches a job against the default target (NOP team) and shows you the output before acti it.
You can check it with atk exploit ls ..

Whenever you want to update your exploit to a new , just issue the exploit upload command again.
The attacker will assign progressi to the , such as NAME-1, NAME-2, and so forth.

Uploaded exploits can be downloaded by anyone with atk exploit download EXPLOIT_ID OUTPUT_DIR.

(De)acti exploits

You can use atk exploit activate/deactivate to activate/deactivate an exploit.
The commands accepts a history ID or an exploit ID.
Generally, you should use them with history IDs, and use exploit switch (see next section) for switching between different .

When exploit activate gets a history ID, it activates the most recent exploit in the history.
If an exploit is already active, it does nothing.

When exploit deactivate gets a history ID, it deactivates all the exploits in the history.

Switching exploit

List the exploits to find the exploit ID:

Now switch to the desired :

We can confirm it worked:

Checking exploit logs

You can check logs (including stdout/stderr) for a centralized exploit using atk exploit logs [NAME], where NAME is a history or exploit ID.
If you pass an exploit ID, it will show logs for that specific .
If you pass a history ID, it will show logs for acti in the history.
If you pass auto or ., this resolves to the current exploit directory [auto is the default]
You can pass more than one ID and mix exploit and history IDs.

By default, it will show logs from the current round.
You can show logs from the last NUM rounds by passing -n NUM.

Target management

Ataka supports per-history target control.
By default, all targets are enabled.

To see which targets are enabled for a history, use atk exploit target ls.
You can enable/disable targets for a history with atk exploit target on/off (they both support --all to mean "all known targets").

Enabling one or multiple targets also schedules a new job for immediate central execution for the specified target(s), even if said target is already enabled.
You can use this to re-run a central execution if necessary.

Manual flag submission

You can manually submit flags:

The flags can be dirty, they will be matched using the flag regex.

If you don't specify flags, flag submit will read from stdin until EOF and then submit (i.e., it is not streaming):

Emergency mode

In the CLI as atk -b/--bypass-tools ... will bypass the centralized Ataka service and connect directly to the gameserver to get attack targets, flag IDs and to submit flags.
In this mode, only

A typical emergency scenario will invol exploits locally with exploit runlocal --all-targets (and/or -N/-T if finer target control is required).

项目信息

开发语言：Python

Star 数：128

技术要点

该项目属于CTF思路方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Runs exploits, fast.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。