Entwurf: Anfrage zur Diskussion

Zusammenfassung

Dieses Dokument bietet eine Übersicht über Version 1 der OST C&C Specification. Es soll eine detaillierte Beschreibung der Nachrichten und der in diesen Nachrichten enthaltenen Felder liefern.

Einleitung

Die Motivation hinter dieser Spezifikation besteht darin, ein C&C-Nachrichtenprotokoll (einschließlich Tasking, strukturierter Ausgabe und Peer-to-Peer-Routing) bereitzustellen, das wörtlich implementiert werden kann oder Projektentwicklern einfach als Inspiration dient. Dieses Dokument soll nicht beschreiben, was C&C ist. Es wird vorausgesetzt, dass der Leser versteht, was es ist und wofür es verwendet wird.

Die Schlüsselwörter „MUST“, „MUST NOT“, „REQUIRED“, „SHALL“, „SHALL NOT“, „SHOULD“, „SHOULD NOT“, „RECOMMENDED“, „MAY“ und „OPTIONAL“ sind so zu interpretieren, wie in [RFC2119] beschrieben.

Umgebungsannahmen

Diese Spezifikation geht von den folgenden Annahmen aus:

Nachrichten werden über ein unverschlüsseltes Netzwerk gesendet.
Implant-Payloads sind mit dem öffentlichen RSA-Schlüssel versehen, der von dem Teamserver verwendet wird, mit dem sie kommunizieren sollen.

Glossar der Begriffe

Im Folgenden finden Sie eine Liste der in diesem Dokument verwendeten Begriffe.

Implant Metadata: Informationen, die ein Implant über sich selbst an einen Teamserver meldet.
Task Request: Ein Task, der einem Implant zur Ausführung übergeben wird.
Task Response: Der Status und die Ausgabe (falls vorhanden) eines bestimmten Tasks.
Session Key: Ein eindeutiger Verschlüsselungsschlüssel, den ein Implant verwendet, um seine Nachrichten zu verschlüsseln.

Task-Nachrichten

Task-Header

Jede Task-Request- und Task-Response-Nachricht MUSS den folgenden 16-Byte-Header haben.```text | Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | | -------------------------------------------------------------| | 0 | Type | Code | Flags | Label | | -------------------------------------------------------------| | 1 | Identifier | Length | | -------------------------------------------------------------|

- **Type**: 1-Byte-Integer.  Der 'Typ' der Aufgabe.  Siehe [[Aufgabentypen und Codes](https://github.com/rasta-mouse/ost-c2-spec?tab=readme-ov-file#task-types-and-codes)].
- **Code**: 1-Byte-Integer.  Ein 'Subcode' für den angegebenen Typ.  Siehe [[Aufgabentypen und Codes](https://github.com/rasta-mouse/ost-c2-spec?tab=readme-ov-file#task-types-and-codes)].
- **Flags**: 2-Byte-Integer.  Eine Menge von Bitflags, die den Zustand der Nachricht beschreiben.  Siehe [[Task-Flags](https://github.com/rasta-mouse/ost-c2-spec?tab=readme-ov-file#task-flags)].
- **Label**: 4-Byte-Integer.  Ein eindeutiges Label, um mehrere Nachrichten zu korrelieren, die zur selben Aufgabe gehören.
- **Identifier**: 4-Byte-Integer.  Ein sequenzieller Identifikator, der verwendet wird, um fragmentierte Nachrichten in der richtigen Reihenfolge zusammenzusetzen.
- **Length**: 4-Byte-Integer.  Die Gesamtlänge der Aufgabendaten.

## Aufgabentypen und Codes```text
|------------------|--------------------------|
| Type             | Code                     |
|------------------|--------------------------|
| 0 - NOP          | 0                        |
|------------------|--------------------------|
| 1 - Exit         | 0                        |
|------------------|--------------------------|
| 2 - Set          | 0 - Sleep/Jitter         |
|                  | 1 - SpawnTo              |
|                  | 2 - BlockDLLs            |
|                  | 3 - PPID                 |
|------------------|--------------------------|
| 3 - File         | 0 - Copy                 |
|                  | 1 - Move                 |
|                  | 2 - Delete               |
|                  | 3 - Upload               |
|                  | 4 - Download             |
|------------------|--------------------------|
| 4 - Directory    | 0 - Print                |
|                  | 1 - Change               |
|                  | 2 - Create               |
|                  | 3 - Copy                 |
|                  | 4 - Move                 |
|                  | 5 - List                 |
|                  | 6 - Delete               |
|------------------|--------------------------|
| 5 - WhoAmI       | 0                        |
|------------------|--------------------------|
| 6 - Process      | 0 - List                 |
|                  | 1 - Kill                 |
|                  | 2 - Inject Spawn         |
|                  | 3 - Inject Explicit      |
|------------------|--------------------------|
| 7 - Registry     | 0 - Query                |
|                  | 1 - Add                  |
|                  | 2 - Delete               |
|------------------|--------------------------|
| 8 - RPortFwd     | 0 - Start                |
|                  | 1 - Data                 |
|------------------|--------------------------|
| 9 - Environment  | 0 - Get                  |
|                  | 1 - Set                  |
|------------------|--------------------------|
| 10 - SOCKS       | 0 - Connect              |
|                  | 1 - Data                 |
|                  | 2 - Close                |
|------------------|--------------------------|
| 11 - Tokens      | 0 - List                 |
|                  | 1 - Make                 |
|                  | 2 - Steal                |
|                  | 3 - Use                  |
|                  | 4 - Revert               |
|                  | 5 - Delete               |
|                  | 6 - Purge                |
|------------------|--------------------------|
| 12 - Run         | 0                        |
|------------------|--------------------------|
| 13 - ItemStore   | 0 - List                 |
|                  | 1 - Add                  |
|                  | 2 - Delete               |
|                  | 3 - Purge                |
|------------------|--------------------------|
| 14 - LocalExec   | 0 - .NET                 |
|                  | 1 - BOF                  |
|                  | 2 - Managed PowerShell   |
|                  | 3 - Unmanaged PowerShell |
|------------------|--------------------------|
| 15 - PrintScreen | 0                        |
|------------------|--------------------------|
| 16 - RemoteExec  | 0 - WinRM                |
|                  | 1 - WMI                  |
|                  | 2 - PsExec               |
|                  | 3 - SSH                  |
|------------------|--------------------------|
| 17 - Link        | 1 - Link SMB             |
|                  | 2 - Link TCP             |
|------------------|--------------------------|
| 18 - Unlink      | 0                        |
|------------------|--------------------------|
| 19 - P2P         | 0 - Acknowledge          |
|                  | 1 - PassThru             |
|------------------|--------------------------|
| 20 - Jobs        | 0 - List                 |
|                  | 1 - Kill                 |
|---------------------------------------------|

Aufgaben-Flags

Einige Flags schließen sich gegenseitig aus und DÜRFEN NICHT gemeinsam gesetzt werden. Wenn keine Flags gesetzt sind, SOLLTE angenommen werden, dass eine Aufgabe erfolgreich abgeschlossen wurde und die zugehörige Ausgabe (falls vorhanden) NICHT fragmentiert ist.```text

Value	Description
0	No flags
1	Task Error
2	Task Running (as job)
4	Message is fragmented, more to follow

## Aufgabendaten

Die Aufgabendaten werden an den Header angehängt und bestehen – je nach spezifischem Aufgabentyp und Code – aus einer binären Struktur.  Jeder Aufgabenanfrage- und Antwortnachrichtentyp ist in [[Message Definitions](https://github.com/rasta-mouse/ost-c2-spec?tab=readme-ov-file#message-definitions)] definiert.

Es ist NICHT ZWINGEND ERFORDERLICH, dass eine Aufgabenanfrage oder -antwort Daten enthält, wenn keine benötigt werden.

## Verschlüsselte Aufgabennachricht

Vor der Übertragung werden der Aufgaben-Header und die Aufgabendaten kombiniert und mit dem Sitzungsschlüssel des Implants AES-verschlüsselt.```text
| Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| ------------------------------------ |
|  0   |            Iv                 |
|  8   |                               |
| ------------------------------------ |
|  16  |          Checksum             |
|  24  |                               |
|  32  |                               |
|  40  |                               |
| ------------------------------------ |
|  48  |           Data                |
|  ..  |                               |
| ------------------------------------ |

Iv: Ein 16-Byte-Initialisierungsvektor.
Checksum: Eine 32-Byte-HMAC256-Prüfsumme.
Data: Die verschlüsselten Daten.

Nachrichtenaustausch

Implant-Registrierung

Ein Implant MUSS sich bei einem Team-Server registrieren, bevor es Aufgaben-Daten empfangen oder senden kann.

Erzeugung von IMPLANT-METADATA

Das Implant erzeugt eine [IMPLANT-METADATA]-Nachricht, verschlüsselt sie mit dem öffentlichen RSA-Schlüssel des Team-Servers und sendet sie an den Team-Server.

Empfang von IMPLANT-METADATA

Der Team-Server verwendet seinen privaten RSA-Schlüssel, um die [IMPLANT-METADATA] des Implants zu entschlüsseln, und MUSS sie als neue Session/einen neuen Callback registrieren.

Implant-Check-in

Ein Implant MUSS sich beim Team-Server "einchecken", um ausstehende Aufgaben-Daten für sich selbst oder untergeordnete Implants zu empfangen.

Check-in-Anfrage

Die Methode des Check-ins ist C2-Kanal-spezifisch und wird von dieser Spezifikation nicht abgedeckt. Ein registriertes Implant DARF zum Einchecken nur seine ID senden. Wenn das Implant jedoch seitdem seinen Session-Schlüssel, seine Sleep- oder Jitter-Konfiguration geändert hat, MUSS es auch seine Metadaten erneut senden.

Check-in-Antwort

Wenn keine ausstehenden Aufgaben vorhanden sind, DARF ein Team-Server ohne Daten antworten oder mit Dummy-Daten in Form einer oder mehrerer [NOP]-Nachrichten. Andernfalls MUSS er mit einer Sammlung von Aufgabenanfragen antworten, die mit dem Session-Schlüssel des Implants AES-verschlüsselt sind.

Peer-to-Peer

Empfang von LINK-X-REQ

Ein Kind-Implant MUSS seine Metadaten in den P2P-Kanal (z. B. Named Pipe oder TCP-Socket) schreiben, sobald eine Verbindung mit einem neuen Parent hergestellt wurde.

Erzeugung von LINK-REP

Das Parent MUSS diese Metadaten lesen und sie in einer [LINK-REP]-Nachricht an den Team-Server zurücksenden.

Empfang von LINK-REP

Der Team-Server MUSS die Metadaten des Kind-Implants entschlüsseln und es als neue Session/einen neuen Callback registrieren oder im Fall eines Unlink & Link die bestehenden Parent-Kind-Beziehungen aktualisieren.

Erzeugung von LINK-ACK

Der Team-Server MUSS eine [LINK-ACK]-Nachricht an das neue Parent zurücksenden, um die ID des Kind-Implants zu bestätigen. Das Parent SOLLTE das Label der Nachricht verwenden, um diesen Vorgang zuzuordnen.

Kind-Aufgaben

Aufgaben für Kind-Implants sind in einer oder mehreren [LINK-PASS-THRU]-Nachrichten verpackt. Diese werden mit dem Session-Schlüssel des Parents verschlüsselt. Beim Empfang MUSS das Parent die Nachricht entschlüsseln und die verpackten Daten an das Kind-Implant weiterleiten, das durch das Feld child-id angegeben ist.

Die verpackten Daten können die Aufgabe selbst oder eine weitere LINK-PASS-THRU-Nachricht sein, wenn das Kind eine weitere Ebene tiefer in der Kette steht.

Nachrichtendefinitionen

Zeitstempel-Felder

Alle Timestamp-Felder werden als vorzeichenbehaftete 64-Bit-Ganzzahlen (Int64) übertragen, die die UNIX-Epoche repräsentieren (die Anzahl der Sekunden, die seit dem 1. Januar 1970 vergangen sind).

Optionale Felder

Manche Sprachen unterscheiden nicht zwischen einem ausgelassenen Wert und einem übertragenen Wert von Null. Zur Konsistenz MÜSSEN Implementierungen OPTIONALEN Feldern ein 1- oder 0-Byte (d. h. TRUE oder FALSE) voranstellen, um anzugeben, ob der Wert vorhanden ist oder nicht.

Längenpräfix-Felder

Es ist nicht immer möglich zu wissen, wann ein Feld endet und ein anderes beginnt, wenn Daten aus einem binären Datenstrom gelesen werden. Diese Spezifikation schreibt vor, diesen Feldern einen Längenwert voranzustellen, damit Implementierungen wissen, wie viele Bytes oder wie viele Elemente das Feld enthält. Die folgenden Datentypen MÜSSEN mit einem Längenpräfix versehen werden:

String (DARF auch nullterminiert sein, ist aber nicht erforderlich).
SEQUENCEs, deren Länge nicht statisch definiert ist.
IPV4-ADDRESS.
IPV6-ADDRESS.

Erweiterung der Spezifikation

Implementierungen DÜRFEN Nachrichtentypen, Steuercodes und Flags enthalten, die in dieser Spezifikation nicht definiert sind, je nach ihrem individuellen Design und ihrer Funktionalität. Es wird jedoch EMPFOHLEN, Werte am oberen Ende des unvergebenen Pools zu verwenden, um die Wahrscheinlichkeit zu verringern, dass sie in einer zukünftigen Revision vergeben werden. Implementierungen DÜRFEN einen Typ, Code oder ein Flag, der/das für etwas anderes als seinen vorgesehenen Zweck definiert ist, NICHT verwenden.

Nicht erkannte Nachrichten

Implementierungen SOLLTEN den Empfang einer Nachricht mit Feldern oder Flags, die sie nicht erkennen, ordnungsgemäß behandeln und eine geeignete Fehlermeldung zurückgeben.

IMPLANT-METADATA```text

IMPLANT-METADATA { id [1] UInt32 session-key [2] SEQUENCE of Byte (32) sleep [3] UInt32 OPTIONAL jitter [4] UInt32 OPTIONAL username [5] String OPTIONAL host-id [6] String OPTIONAL hostname [7] String OPTIONAL domain [8] String OPTIONAL ipv4-ips [9] SEQUENCE of IPV4-ADDRESS OPTIONAL ipv6-ips [10] SEQUENCE of IPV6-ADDRESS OPTIONAL process-name [11] String OPTIONAL process-id [12] UInt32 OPTIONAL architecture [13] [Architecture] OPTIONAL platform [14] [Platform] OPTIONAL os-description [15] String OPTIONAL integrity [16] [Integrity] OPTIONAL }

### IPV4-ADDRESS```text
IPV4-ADDRESS {
  address  [1]  SEQUENCE of Byte (4)
}

IPV6-ADDRESS```text

IPV6-ADDRESS { address [1] SEQUENCE of Byte (16) }

IP-Adressen MÜSSEN in Netzwerk-Bytereihenfolge übertragen werden.

### Plattform```text
Platform {
  Linux   = 0,
  MacOS   = 1,
  Windows = 2
}

TASK-ERROR```text

TASK-ERROR { error-code [1] UInt32 message [2] String OPTIONAL }

## NOP-Definitionen

### NOP```text
NOP {
  padding  [1]  SEQUENCE of Byte  OPTIONAL
}

Set-Definitionen

SET-SLEEP-REQ```text

SET-SLEEP-REQ { interval [1] UInt32 jitter [2] Byte OPTIONAL }

### SET-SPAWNTO-REQ```text
SET-SPAWNTO-REQ {
  spawnto  [1]  String  OPTIONAL
}

Wenn das Feld spawnto nicht gesetzt ist, SOLLTE der Implantat auf seine Standardkonfiguration zurückgreifen.

SET-BLOCKDLLS-REQ```text

SET-BLOCKDLLS-REQ { blockdlls [1] Boolean OPTIONAL }

Wenn das Feld `blockdlls` *nicht* gesetzt ist, SOLLTE das Implant zu seiner Standardkonfiguration zurückkehren.

### SET-PPID-REQ```text
SET-PPID-REQ {
  ppid  [1]  UInt32  OPTIONAL
}

Wenn das ppid-Feld nicht gesetzt ist, SOLLTE das Implantat auf seine Standardkonfiguration zurückfallen.

Dateisystem-Definitionen

FILE-COPY-REQ```text

FILE-COPY-REQ { source [1] String destination [2] String force [3] Boolean OPTIONAL }

### FILE-MOVE-REQ```text
FILE-MOVE-REQ {
  source       [1]  String
  destination  [2]  String
}

FILE-DELETE-REQ```text

FILE-DELETE-REQ { path [1] String }

### FILE-UPLOAD-REQ```text
FILE-UPLOAD-REQ {
  destination  [1]  String
  content      [2]  SEQUENCE of Byte
}

FILE-DOWNLOAD-REQ```text

FILE-DOWNLOAD-REQ { path [1] String }

### FILE-DOWNLOAD-REP```text
FILE-DOWNLOAD-REP {
  current-chuck  [1]  UInt16
  total-chunks   [2]  UInt16
  chunk-content  [3]  SEQUENCE of Byte
}

DIR-PRINT-REP```text

DIR-PRINT-REP { path [1] String }

### DIR-CHANGE-REQ```text
DIR-CHANGE-REQ {
  path  [1]  String  OPTIONAL
}

Wenn das path-Feld nicht gesetzt ist, SOLL das Implant sein Arbeitsverzeichnis in einen 'Standard'-Speicherort ändern (z. B. das Home-Verzeichnis des Benutzers).

DIR-CREATE-REQ```text

DIR-CREATE-REQ { path [1] String }

### DIR-CREATE-REP```text
DIR-CREATE-REP {
  entry  [1]  [FileSystemEntry]
}

DIR-COPY-REQ```text

DIR-COPY-REQ { source [1] String destination [2] String }

### DIR-MOVE-REQ```text
DIR-MOVE-REQ {
  source       [1]  String
  destination  [2]  String
}

DIR-LIST-REQ```text

DIR-LIST-REQ { path [1] String OPTIONAL access-control [2] Boolean OPTIONAL }

Falls das Feld `path` *nicht* gesetzt ist, sollte der Implant sein aktuelles Arbeitsverzeichnis auflisten.

### DIR-LIST-REP```text
DIR-LIST-REP {
  entries  [1]  SEQUENCE of [FileSystemEntry]
}

DIR-DELETE-REQ```text

DIR-DELETE-REQ { path [1] String recurse [2] Boolean OPTIONAL }

### FileSystemEntry```text
FileSystemEntry {
  path            [1]  String
  length          [2]  UInt32                      OPTIONAL
  attributes      [3]  [FileAttributes]            OPTIONAL
  owner           [4]  String                      OPTIONAL
  created         [5]  Timestamp                   OPTIONAL
  last-accessed   [6]  Timestamp                   OPTIONAL
  last-written    [7]  Timestamp                   OPTIONAL
  access-control  [8]  SEQUENCE of [FileSecurity]  OPTIONAL
}

FileAttributes

Bitweise Flags.```text FileAttributes { Normal = 1, Archive = 2, Compressed = 4, ReadOnly = 8, Hidden = 16, Directory = 32, System = 64 }

### FileSecurity```text
FileSecurity {
  identity     [1]  String
  access-mask  [2]  Int32
  inheritance  [3]  [Inheritance]  OPTIONAL
  propagation  [4]  [Propagation]  OPTIONAL
}

Vererbung

Bitweise Flags.```text Inheritance { None = 0, ContainerInherit = 1, ObjectInherit = 2, }

### Verbreitung

Bitweise Flags.```text
Propagation {
  None               = 0,
  NoPropagateInherit = 1,
  InheritOnly        = 2,
}

WhoAmI-Definitionen

WHOAMI-REP```text

WHOAMI-REP { primary [1] String impersonation [2] String OPTIONAL }

## Prozessdefinitionen

### PROC-LIST-REP```text
PROC-LIST-REP {
  processes  [1]  SEQUENCE of [ProcessEntry]
}

PROC-KILL-REQ```text

PROC-KILL-REQ { process-id [1] UInt32 force [2] Boolean OPTIONAL }

### PROC-INJ-REQ```text
PROC-INJ-REQ {
  shellcode   [1]  SEQUENCE of Byte
  capability  [2]  SEQUENCE of Byte
  process-id  [3]  UInt32            OPTIONAL
}

ProcessEntry```text

ProcessEntry { process-name [1] String process-id [2] UInt32 parent-process-id [3] UInt32 OPTIONAL session-id [4] Byte OPTIONAL owner [5] String OPTIONAL architecture [6] [Architecture] OPTIONAL integrity [7] [Integrity] OPTIONAL }

### Architektur```text
Architecture {
  X86   = 0,  // 32-bit Intel
  X64   = 1,  // 64-bit Intel
  Arm   = 2,  // 32-bit ARM
  Arm64 = 3,  // 64-bit ARM
  Wasm  = 4   // WebAssembly
}

Integrität```text

Integrity { Untrusted = 0, Low = 1, Medium = 2, // user High = 3, // sudoers System = 4 // root }

## Registrierungsdefinitionen

### REG-QUERY-REQ```text
REG-QUERY-REQ {
  hive            [1]  [RegistryHive]
  key             [2]  String          OPTIONAL
  value           [3]  String          OPTIONAL
  access-control  [4]  Boolean         OPTIONAL
}

REG-QUERY-REP```text

REG-QUERY-REP { values [1] SEQUENCE of [RegistryValue] keys [2] SEQUENCE of [RegistryKey] }

### REG-ADD-REQ```text
REG-ADD-REQ {
  hive   [1]  [RegistryHive]
  key    [2]  String
  name   [3]  String               OPTIONAL
  kind   [4]  [RegistryValueKind]  OPTIONAL
  value  [5]  SEQUENCE of Byte     OPTIONAL
}

REG-DELETE-REQ```text

REG-DELETE-REQ { hive [1] [RegistryHive] key [2] String }

### RegistryHive```text
RegistryHive {
  ClassesRoot   = 0,
  CurrentUser   = 1,
  LocalMachine  = 2,
  Users         = 3,
  CurrentConfig = 4
}

RegistryKey```text

RegistryKey { name [1] String access-control [2] [RegistrySecurity] OPTIONAL }

### RegistryValue```text
RegistryValue {
  name            [1]  String
  type            [2]  [RegistryValueKind]
  data            [3]  SEQUENCE of Byte
  access-control  [4]  SEQUENCE of [RegistrySecurity]  OPTIONAL
}

RegistryValueKind```text

RegistryValueKind { None = 0, // REG_NONE String = 1, // REG_SZ ExpandString = 2, // REG_EXPAND_SZ Binary = 3, // REG_BINARY DWord = 4, // REG_DWORD MultiString = 5, // REG_MULTI_SZ Qword = 6 // REG_QWORD }

### RegistrySecurity```text
RegistrySecurity {
  identity     [1]  String
  access-mask  [2]  Int32
  inheritance  [3]  [Inheritance]  OPTIONAL
  propagation  [4]  [Propagation]  OPTIONAL
}

Definitionen für Reverse Port Forwarding

RPORTFWD-START```text

RPORTFWD-START { bind-port [1] UInt16 localhost-only [2] Boolean OPTIONAL forward-host [3] String forward-port [4] UInt16 }

### RPORTFWD-DATA```text
RPORTFWD-DATA {
  data  [1]  SEQUENCE of Byte
}

Umgebungsdefinitionen

ENV-GET-REQ```text

ENV-GET-REQ { key [1] String }

### ENV-GET-REP```text
ENV-GET-REP {
  value  [1]  String
}

ENV-SET-REQ```text

ENV-SET-REQ { key [1] String value [2] String }

## SOCKS-Definitionen

### SOCKS-CONNECT-REQ```text
SOCKS-CONNECT-REQ {
  id      [1]  UInt32
  target  [2]  SEQUENCE of Byte (4)
  port    [3]  UInt16
}

SOCKS-DATA```text

SOCKS-DATA { id [1] UInt32 data [2] SEQUENCE of Byte }

### SOCKS-CLOSE-REQ```text
SOCKS-CLOSE-REQ {
  id  [1]  UInt32
}

## Token Definitions

### TOKEN-LIST-REP

```text
TOKEN-LIST-REP {
  tokens  [1]  SEQUENCE of [TokenEntry]
}```

### TOKEN-CREATE-REQ

```text
TOKEN-CREATE-REQ {
  username  [1]  String
  domain    [2]  String  OPTIONAL
  password  [3]  String  OPTIONAL
}```

### TOKEN-STEAL-REQ

```text
TOKEN-STEAL-REQ {
  process-id   [1]  UInt32
  access-mask  [2]  UInt32  OPTIONAL
}```

### TOKEN-USE-REQ

```text
TOKEN-USE-REQ {
  index  [1]  Byte
}```

### TOKEN-DELETE-REQ

```text
TOKEN-DELETE-REQ {
  index  [1]  Byte
}```

### TokenEntry

```text
Token {
  index       [1]  Byte
  username    [2]  String
  handle      [3]  String  OPTIONAL
  process-id  [4]  UInt32  OPTIONAL
}```

## Implant Store Definitions

### STORE-LIST-REP

```text
STORE-LIST-REP {
  items  [1]  SEQUENCE OF [StoreItem]
}```

### STORE-ADD-ITEM Definition

```text
STORE-ADD-ITEM-REQ {
  item  [1]  SEQUENCE of Byte
  name  [2]  String
  type  [3]  [StoreItemType]
}```

### STORE-DELETE-ITEM Definition

```text
STORE-DELETE-ITEM-REQ {
  index  [1]  Byte
}```

### StoreItem

```text

StoreItem { index [1] Byte name [2] String type [3] [StoreItemType] }


### StoreItemType

```text
```csharp
StoreItemType {
  Assembly = 0,
  BOF      = 1,
  Script   = 2,
  Generic  = 3
}

Local Execution Definitions

RUN-REQ

RUN-REQ {
  program    [1]  String
  arguments  [2]  String  OPTIONAL
  token      [3]  Byte    OPTIONAL
}```

### RUN-REP

```text
RUN-REP {
  output  [1]  String
}```

### EXEC-ASM-REQ

Either store-index or assembly MUST be provided.

```text
EXEC-ASM-REQ {
  store-index  [1]  Byte                OPTIONAL
  assembly     [2]  SEQUENCE of Byte    OPTIONAL
  arguments    [3]  SEQUENCE of String  OPTIONAL
  bypass-amsi  [4]  Boolean             OPTIONAL
  bypass-etw   [5]  Boolean             OPTIONAL
}```

### EXEC-ASM-REP

```text
EXEC-ASM-REP {
  output  [1]  String
}```

### EXEC-BOF-REQ

Either store-index or bof MUST be provided.

```text
EXEC-BOF-REQ {
  store-index  [1]  Byte              OPTIONAL
  bof          [2]  SEQUENCE of Byte  OPTIONAL
  arguments    [3]  SEQUENCE of Byte  OPTIONAL
  bypass-amsi  [4]  Boolean           OPTIONAL
  bypass-etw   [5]  Boolean           OPTIONAL
}```

### EXEC-BOF-REP

```text
EXEC-BOF-REP {
  output  [1]  String
}```

### EXEC-POSH-REQ

Either store-index or script MUST be provided.

```text
EXEC-POSH-REQ {
  cmdlet       [1]  String
  store-index  [2]  Byte              OPTIONAL
  script       [3]  SEQUENCE of Byte  OPTIONAL
  bypass-amsi  [3]  Boolean           OPTIONAL
  bypass-etw   [4]  Boolean           OPTIONAL
}```

### EXEC-POSH-REP

```text
EXEC-POSH-REP {
  output  [1]  String
}```

## Screenshot Definitions

### SCRNSHOT-REP

```text
SCRNSHOT-REP {
  data  [1]  SEQUENCE of Byte
}```

## Remote Execution Definitions

### WINRM-REQ

```text
WINRM-REQ {
  target     [1]  String
  program    [2]  String
  arguments  [3]  String  OPTIONAL
}```

### WMI-REQ

```text
WMI-REQ {
  target     [1]  String
  program    [2]  String
  arguments  [3]  String  OPTIONAL
}```

### PSEXEC-REQ

```text
PSEXEC-REQ {
  target               [1]  String
  service-name         [2]  String
  service-description  [3]  String  OPTIONAL
  bin-path             [4]  String
}```

## Peer-to-Peer Definitions

### LINK-SMB-REQ

```text
LINK-SMB-REQ {
  target    [1]  String
  pipename  [2]  String
}```

### LINK-TCP-REQ

```text
LINK-TCP-REQ {
  target  [1]  String
  port    [2]  UInt32
}```

### LINK-REP

```text
LINK-SMB-REP {
  child-metadata  [1]  SEQUENCE of Byte
}```

### LINK-ACK

```text
LINK-ACK {
  child-id  [1]  UInt32
}```

### LINK-PASS-THRU

```text
LINK-PASS-THRU {
  child-id  [1]  UInt32
  message   [2]  SEQUENCE of Byte
}```

## JOB Definitions

### JOB-LIST-REP

```text
jobs  [1]  Sequenz von [JobEntry]```

### JOB-KILL-REQ

```text
index  [1]  UInt32```

### JobEntry
```text
index  [1]  UInt32
  type   [2]  Byte
  code   [3]  Byte```

OST-C2-Spec

Beliebteste