timwhitez starred OST-C2-Spec
2024-8-5 14:53:42 Author: github.com(查看原文) 阅读量:0 收藏

Draft: Request for Discussion

This document provides an overview of Version 1 of the OST C&C Specification. It is intended to provide a detailed description of messages and the fields within those messages.

The motivation behind this specification is to improve interoperability between C&C frameworks without requiring cumbersome translation layers. The goal is for frameworks to implement a standard set of message structures so that implants generated from one framework can be controlled natively from another. This includes tasking, structured output, and peer-to-peer routing.

This document is not intended to describe what C&C is. It is assumed the reader understands what it is and what it is used for.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].

Environmental Assumptions

This specification makes the following assumptions:

  • Messages are sent over an unencrypted network.
  • Implant payloads are embedded with the public RSA key used by the team server it is intended to communicate with.

Glossary of Terms

Below is a list of terms used throughout this document.

  • Implant Metadata: Information that an implant reports about itself to a team server.

  • Task Request: A task given to an implant to perform.

  • Task Response: The status and output (if any) of a given task.

  • Session Key: A unique encryption key used by an implant to encrypt its messages.

Task Header

Each task request and response message MUST have the following 16-byte header.

| Byte |   0  |   1  |   2  |   3  |   4  |   5  |   6  |   7  |
| -------------------------------------------------------------|
|  0   | Type | Code |    Flags    |           Label           |
| -------------------------------------------------------------|
|  1   |         Identifier        |           Length          |
| -------------------------------------------------------------|
  • Type: 1-byte integer. The ‘type’ of task this is, e.g. ‘change directory’, ‘list processes’, etc. See [Task Types and Codes].

  • Code: 1-byte integer. A ‘sub code’ for the given Type, e.g ‘connect’, ‘read’, ‘write’, and ‘close’ for SOCKS. See [Task Types and Codes].

  • Flags: 2-byte integer. A set of bitwise flags to describe the state of the message. See [Task Flags].

  • Label: 4-byte integer. A unique label to correlate multiple messages related to the same task.

  • Identifier: 4-byte integer. A sequential identifier used to construct fragmented messages in the correct order.

  • Length: 4-byte integer. The total length of the task data.

Task Types and Codes

|------------------|--------------------------|
| 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 - Bind                 |
|                  | 1 - Read                 |
|                  | 2 - Write                |
|                  | 3 - Close                |
|------------------|--------------------------|
| 9 - Environment  | 0 - Get                  |
|                  | 1 - Set                  |
|------------------|--------------------------|
| 10 - SOCKS       | 0 - Connect              |
|                  | 1 - Read                 |
|                  | 2 - Write                |
|                  | 3 - 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             |
|------------------|--------------------------|

Task Flags

Some flags are mutually exclusive and MUST NOT be set together (e.g. the encoding flags). If no flags are set, a task SHOULD be assumed to have completed successfully and NOT fragmented.

| Value | Description                              |
| ----- | ---------------------------------------- |
| 0     | No flags                                 |
| 1     | Task Error                               |
| 2     | Task Running (as job)                    |
| 4     | Message is fragmented, more to follow    |
| 8     | Message is fragmented, no more to follow |
| 16    | Data is JSON encoded                     |
| 32    | Data is XML encoded                      |
| 64    | Data is Protobuf encoded                 |

Task Data

The task data is appended to the header and will consist of a serialised structure, depending on the specific task type and code. Each task request and response message type are defined in [Message Definitions].

It is NOT MANDATORY for a task request or response to have any data if it is not required.

Encrypted Task Message

The task header and task data are combined and AES-encrypted with the implant’s session key.

| Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| ------------------------------------ |
|  0   |            Iv                 |
|  8   |                               |
| ------------------------------------ |
|  16  |                               |
|  24  |          Checksum             |
|  32  |                               |
|  40  |                               |
| ------------------------------------ |
|  48  |           Data                |
|  ..  |                               |
| ------------------------------------ |
  • Iv: A 16-byte initialisation vector.
  • Checksum: A 32-byte HMAC256 checksum.
  • Data: The encrypted data.

Implant Registration

An implant MUST register itself with a team server before it can receive or send any task data.

Generation of IMPLANT-METADATA

The implant generates an [IMPLANT-METADATA] message, encrypts it with the team server’s public RSA key, and sends it to the team server.

Receipt of IMPLANT-METADATA

The team server uses its private RSA key to decrypt the implant’s [IMPLANT-METADATA] and MUST register it as a new session/callback.

Implant Check In

An implant MUST “check in” with the team server to receive any pending task data for itself or child descendants.

Check in Request

The method of check in is specific to the C2 channel and not covered under this specification. A registered implant MAY only send its ID to check in. However, if the implant has since changed its session key, it MUST also re-send its metadata.

Check in Response

If there are no pending tasks, a team server MAY respond with no data, or dummy data in the form of one or more [NOP] tasks. Otherwise, it MUST respond with a collection of task requests that are AES-encrypted with the implant’s session key.

Peer-to-Peer

Receipt of LINK-X-REQ

A child implant MUST write its metadata to the P2P channel (e.g. named pipe or TCP socket) once a connection is established with a new parent.

Generation of LINK-REP

The parent MUST read this metadata and send it back to the team server in a [LINK-REP] message.

Receipt of LINK-REP

The team server MUST decrypt the child’s metadata and register it as a new session/callback or update the existing parent-child relationships in the case of an unlink & link.

Generation of LINK-ACK

The team server MUST send a [LINK-ACK] message back to the new parent to confirm the ID of the child. The parent SHOULD use the message Label to correlate this process.

Child Tasks

Tasks for child implants are wrapped in one or more [LINK-PASS-THRU] messages. These will be encrypted with the parent implant’s session key. Upon receipt, an implant MUST decrypt the message and forward the wrapped data to the child implant ID indicated by the child-id field.

The wrapped data may be the task itself or another LINK-PASS-THRU if the child is another level down the chain.

Optional Integer Fields

Some languages do not distinguish between an omitted integer value and a transmitted value of zero. For consistency, implementations SHOULD treat omitted values as having been transmitted with a value of zero.

Timestamp Fields

Timestamps are unsigned 64-bit integers which represents the UNIX epoch (the number of seconds that have elapsed since 1 January 1970).

Extending the Specification

Implementations MAY include message types, control codes, and flags that are not defined in this specification, as per their unique design and functionality. It is RECOMMENDED to use values that are on the higher end of the unreserved pool to reduce the chance of them being assigned in a future revision. Implementations MUST NOT use a type, code, or flag that is defined for anything other than its intended purpose.

Unrecognised Messages

Implementations SHOULD gracefully handle receiving a message with fields or flags that it does not recognise and return an appropriate error message.

IMPLANT-METADATA

IMPLANT-META {
  id             [1]   Uint32
  sleep          [2]   UInt32                   OPTIONAL
  jitter         [3]   UInt32                   OPTIONAL
  session-key    [4]   SEQUENCE of Byte (32)
  username       [5]   String
  hostname       [6]   String
  internal-ips   [7]   SEQUENCE of Byte (4)
  process-name   [8]   String
  process-id     [9]   UInt32
  architecture   [10]  [Architecture]
  platform       [11]  [Platform]
  os-description [12]  String                   OPTIONAL
  integrity      [13]  [Integrity]
}

Platform

Platform {
  Linux   = 0,
  MacOS   = 1,
  Windows = 2
}

TASK-ERROR

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

NOP Definitions

NOP

NOP {
  padding  [1]  SEQUENCE of Byte  OPTIONAL
}

Set Definitions

SET-SLEEP-REQ

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

SET-SPAWNTO-REQ

If the spawnto field is NOT set, the implant SHOULD revert to its default configuration.

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

SET-BLOCKDLLS-REQ

If the blockdlls field is NOT set, the implant SHOULD revert to its default configuration.

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

SET-PPID-REQ

If the ppid field is NOT set, the implant SHOULD revert to its default configuration.

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

FileSystem Definitions

FILE-COPY-REQ

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

FILE-MOVE-REQ

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

FILE-DELETE-REQ

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

FILE-UPLOAD-REQ

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

FILE-DOWNLOAD-REQ

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

FILE-DOWNLOAD-REP

FILE-DOWNLOAD-REP {
  file-length    [1]  UInt32
  current-chuck  [2]  Byte
  total-chunks   [3]  Byte
  chunk-content  [4]  SEQUENCE of Byte
}

CHANGE-DIR-REQ

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

CREATE-DIR-REQ

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

CREATE-DIR-REP

CREATE-DIR-REP {
  entry  [1]  [FileSystemEntry]
}

COPY-DIR-REQ

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

MOVE-DIR-REQ

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

LIST-DIR-REQ

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

LIST-DIR-REP

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

DELETE-DIR-REQ

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

FileSystemEntry

FileSystemEntry {
  path            [1]  String
  length          [2]  UInt32
  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]  [FileSecurity]    OPTIONAL
}

FileAttributes

Bitwise flags.

FileAttributes {
  Normal     = 1,
  Archive    = 2,
  Compressed = 4,
  ReadOnly   = 8,
  Hidden     = 16,
  Directory  = 32,
  System     = 64
}

FileSecurity

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

Inheritance

Bitwise flags.

Inheritance {
  None             = 0,
  ContainerInherit = 1,
  ObjectInherit    = 2,
}

Propagation

Bitwise flags.

Propagation {
  None               = 0,
  NoPropagateInherit = 1,
  InheritOnly        = 2,
}

WhoAmI Definitions

WHOAMI-REP

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

Process Definitions

PROC-LIST-REP

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

PROC-KILL-REQ

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

PROC-INJ-SPAWN-REQ

PROC-INJ-SPAWN-REQ {
  shellcode  [1]  SEQUENCE of Byte
  technique  [2]  [InjectionTechnique]  OPTIONAL
}

PROC-INJ-EXPLIC-REQ

INJECT-EXPLIC-REQ {
  process-id  [1]  UInt32
  shellcode   [2]  SEQUENCE of Byte
  technique   [3]  [InjectionTechnique]  OPTIONAL
}

ProcessEntry

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
}

Architecture

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

Integrity

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

InjectionTechnique

InjectionTechnique {
  CreateThread        = 0,
  QueueUserApc        = 1,
  SetThreadContext    = 2,
  RtlCreateUserThread = 3
}

Registry Definitions

REQ-QUERY-REQ

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

REQ-QUERY-REP

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

REQ-ADD-REQ

REG-ADD-REQ {
  hive   [1]  [RegistryHive]
  key    [2]  String
  value  [3]  [RegistryValueKind]
  type   [4]  String
  value  [5]  SEQUENCE of Byte
}

REG-DELETE-REQ

REG-DELETE-REQ {
  hive   [1]  [RegistryHive]
  key    [2]  String
  value  [3]  String          OPTIONAL
  force  [4]  Boolean         OPTIONAL
}

RegistryHive

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

RegistryKey

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

RegistryValue

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

RegistryValueKind

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

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

Reverse Port Forward Definitions

RPORTFWD-BIND

RPORTFWD-BIND {
  port       [1]  UInt32
  localhost  [2]  Boolean
}

RPORTFWD-READ

RPORTFWD-READ {
  data  [1]  SEQUENCE of Byte
}

RPORTFWD-WRITE

RPORTFWD-WRITE {
  data  [1]  SEQUENCE of Byte
}

Environment Definitions

ENV-GET-REQ

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

ENV-GET-REP

ENV-GET-REP {
  value  [1]  String
}

ENV-SET-REQ

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

SOCKS Definitions

SOCKS-CONNECT-REQ

SOCKS-CONNECT-REQ {
  target  [1]  SEQUENCE of Byte  (4)
  port    [2]  Uint32
}

SOCKS-WRITE-REQ

SOCKS-WRITE-REQ {
  data  [1]  SEQUENCE of Byte
}

SOCKS-READ-REQ

SOCKS-READ-REQ {
  data  [1]  SEQUENCE of Byte
}

Token Definitions

TOKEN-LIST-REP

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

TOKEN-CREATE-REQ

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

TOKEN-STEAL-REQ

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

TOKEN-USE-REQ

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

TOKEN-DELETE-REQ

TOKEN-STEAL-REQ {
  index  [1]  Byte
}

TokenEntry

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

Implant Store Definitions

LIST-STORE-REP

LIST-STORE-REP {
  items  [1]  SEQUENCE of [StoreItem]
}

ADD-STORE-ITEM Definition

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

StoreItem

StoreItem {
  index  [1]  Byte
  name   [2]  String
}

StoreItemType

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

RUN-REP {
  output  [1]  String
}

EXEC-ASM-REQ

Either store-index or assembly MUST be provided.

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

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

EXEC-BOF-REQ

Either store-index or bof MUST be provided.

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

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

EXEC-POSH-REQ

Either store-index or script MUST be provided.

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-POST-REP

EXEC-POST-REP {
  output  [1]  String
}

Screenshot Definitions

SCRNSHOT-REP

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

Remote Execution Definitions

WINRM-REQ

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

WMI-REQ

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

PSEXEC-REQ

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

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

LINK-TCP-REQ

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

LINK-REP

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

LINK-ACK

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

LINK-PASS-THRU

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

文章来源: https://github.com/rasta-mouse/OST-C2-Spec
如有侵权请联系:admin#unsafe.sh