initial Apollo yml

[moohax]

AI-Generated Summary

PR Summary

Overview of Changes

This PR introduces the apollo.yml file, constituting a comprehensive addition to the cybersecurity offensive toolkit, specifically for command and control (C2) operations. Aimed at enhancing SpecterOps training offerings, Apollo is a C#-based Windows agent utilizing the .NET Framework 4.0, designed for integration with the Mythic C2 server. It incorporates a wide array of functionalities ranging from file management, process control, registry manipulation, networking commands, to advanced exploitation techniques such as DLL injection, privilege escalation, and credential theft, among others.

Key Modifications

1. Introduction of Apollo Agent: The core addition is the Apollo agent's configuration and capabilities, tailored for offensive cybersecurity training and operations.
2. .NET Assembly Execution: Execution capabilities for .NET assemblies in remote processes have been implemented, allowing for versatile post-exploitation actions.
3. BlockDLLs Control: A function to control the blocking of non-Microsoft signed DLLs from loading into processes, enhancing operational stealth and anti-forensic measures.
4. Credential Access & Manipulation: Features such as mimikatz command execution, DCSync operations, and Pass-the-Hash techniques have been included, targeting credential theft and lateral movement.
5. Process Injection & Management: Various methods for process injection (e.g., shinject, inject, assembly_inject) are introduced alongside process control operations (e.g., kill, steal_token), facilitating deep system access and manipulation.
6. File and Directory Operations: Commands for managing files and directories (ls, cp, mv, mkdir, rm) are incorporated, essential for file system exploration and data exfiltration.
7. Networking and System Reconnaissance: Implements commands for network reconnaissance (ifconfig, netstat) and system information gathering (whoami, ps), crucial for situational awareness and targeting.

Potential Impact

• Enhanced Operational Capabilities: With Apollo's integration, operators can leverage a wide gamut of attack techniques, significantly broadening the scope of possible cyber operations.
• Training and Skill Development: The inclusion of Apollo stands to greatly enhance the quality and effectiveness of SpecterOps training courses, providing trainees with hands-on experience in contemporary offensive techniques.
• Operational Security Risks: The broad capabilities of Apollo necessitate careful handling to avoid detection and mitigate potential misuse, emphasizing the importance of operational security and proper authorization in training and operational deployments.

---

This summary was generated with ❤️ by rigging

[github-actions]

Validation Results (2024-11-28T04:38:23.141Z)

✅ Validation successful

Please ensure your contribution follows the required format.

🔍 View Full Validation Details

---

Run ID: 12062606645
Workflow: Validate Contributions

[GangGreenTemperTatum]

Suggested change

	description: Task agent to exit.
	description: Task agent to exit.
	parameters:
	exit:
	type: boolean
	description: Exit the agent.

[GangGreenTemperTatum]

in the validation, parameters is a required field so i'd suggest perhaps a boolean here :)

[GangGreenTemperTatum]

there's also a problem in my validation workflow i'll look at fixing: (see here, i think it may be a regression from #24)

Status: Downloaded newer image for dreadnode/robopages:latest
docker.io/dreadnode/robopages:latest
[2024-11-28T04:38:22Z ERROR] error while parsing "/workspace/apollo.yml": functions.exit: missing field `parameters` at line 161 column 5

logged in eng-323

[GangGreenTemperTatum]

fixed the workflow in #28 and tested

[GangGreenTemperTatum]

same as per above below this description, there's a few others

[GangGreenTemperTatum]

same as per above below this description :)

[evilsocket]

too generic, would be better placed in a shell.yml maybe?

[evilsocket]

same as above, might be worth creating a shell.yml with these commands, ideally relying on the platforms conditional like here

[evilsocket]

all these blocks seem auto generated ... i'm not sure i understand how these are intended to work tho, most don't seem like commonly available shell commands, but specific commands for apollo, while robopages execute their tools via a standard shell (wether on host, in a container or via ssh somewhere else)

[evilsocket]

Maybe we could add a new type of execution adapter that would execute a specific yml by interacting with a custom target process/shell?

If i understand the intention here all these commands are supposed to do Apollo what to do, effectively using an LLM agent as its C2, so it could make sense to have what we have right now:

• Shell execution - default behaviour, executes cmdline as a shell command on the host)
• SSH execution - same as above but executing on a different host
• Docker execution - runs the cmdline inside the specified container image (for tools that are not installed by default on the host and/or to limit what the agent can do)

Plus a new:

• Custom execution adapter - that would cover these cases (another I can think of is msfconsole for instance, or bettercap).

So before we can merge this we have to answer:

1. How would the code sending these commands to Apollo look like?

Especially as part of this namespace https://github.com/dreadnode/robopages-cli/tree/main/src/runtime

2. How can we generalize that?

So that we don't have to implemen dozens of specific interactions with things like Apollo but just one that works for all (as an objective, if we can generalize to both Apollo and msfconsole that'd be great). Maybe an integrated plugin system and/or scripting engine? I'd like to avoid this complexity unless strictly needed, like if we see that we can't generalize the code easily.

3. How do we differentiate with normal robopages cmdlines (that execute via shell)?

How do we define in the YML file that we need this custom adapter rather than a standard shell? Maybe something like:

adapter:
    type: stdin # writes the cmdline to the stdin of a target process
    target: /path/to/msfconsole # or the apollo_executable?

or

adapter:
    type: rest # sends the cmdline as a json request to an API
    target: https://example.com:8080/v1/api/something

or

adapter:
    type: tcp # sends the cmdline as a tcp buffer to and endpoint
    target: tcp-server-ip:1234

etc etc