DOCSEARCHbyAlgolia
Submit Docs

Cobalt Strike Wiki

repository·master·Indexed 24 days ago

https://github.com/aleenzz/cobalt_strike_wiki

A technical guide focused on Cobalt Strike usage, specifically documenting techniques for shellcode loading, obfuscation, and AV evasion. It covers strategies such as packing, encrypted shellcode loading, and the use of evasion frameworks like Veil, Phantom-Evasion, and shellter. The documentation provides implementation examples in C and Python, including memory allocation via VirtualAlloc, inline assembly, and HTA-based loading using DotNetToJScript.

Tokens
25.9K
Snippets
59
Records
120
Agent score
81%

What's inside cobalt_strike_wiki

  1. Common Windows persistence methods

    master

    The following methods are commonly used for maintaining persistence on Windows systems to ensure Cobalt Strike sessions are re-established:

    • Registry: Modifying registry keys (e.g., Run/RunOnce).
    • Startup Items: Placing files in startup folders.
    • Scheduled Tasks: Using the Task Scheduler to trigger execution.
    • Services: Creating or hijacking Windows Services.
    • Accessibility Features: Utilizing shift key or Magnifier triggers.
    • Hijacking: Various forms of DLL or process hijacking.
    • Software Exploitation: Leveraging existing installed software for execution.

  2. Introduction to Malleable C2 Profiles

    master

    Malleable C2 Profiles in Cobalt Strike are used to disguise network traffic, making Command and Control (C2) communications more stealthy and harder to detect.

    Key concepts:

    • HTTP Communication: The HTTP traffic generated by a Beacon is governed by the Malleable C2 profile.
    • Loading Profiles: A profile is specified when starting the teamserver.
    • Single Profile Constraint: Each Cobalt Strike instance can only load one profile at a time. To use multiple different profiles, you must start multiple teamserver instances.

  4. Common strategies for AV evasion in Cobalt Strike

    master

    To bypass Antivirus (AV) detection (which targets files, memory, traffic, and behavior), several common evasion strategies can be employed:

    1. Packing (加壳): Using packers to obfuscate the executable.
    2. Multi-platform/Multi-language Shellcode Generation: Generating shellcode using different languages or for different platforms.
    3. Encrypted Shellcode Loading: Encrypting the shellcode and decrypting it only during the loading process in memory.
    4. File Injection: Inserting malicious code into legitimate, normal files.
    5. Whitelist Loading: Utilizing trusted/whitelisted processes or methods to load the payload.

  5. Use `transform-x86` and `transform-x64` to modify Beacon payloads

    master

    The transform-x86 and transform-x64 blocks allow you to modify the Beacon Reflective DLL for the specific architecture. These blocks support three commands:

    • prepend: Inserts a string/bytes at the beginning of the Reflective DLL.
    • append: Adds a string/bytes to the end of the Reflective DLL.
    • strrep: Replaces a specific string within the Reflective DLL (useful for changing unique strings like ReflectiveLoader to evade signature-based detection).

    Warning: When using prepend or append, ensure the data provided is valid code for the target architecture (x86 or x64), as c2lint does not validate the code integrity of these transformations.

  6. Configure http-post blocks

    master

    The http-post block defines how the Beacon performs POST requests. It is similar to http-get but often uses the id block for data transmission instead of metadata.

    Client Configuration

    • id: Used to transmit data via parameters. You can use parameter "name" to insert a random value or parameter "name" "value" to use a specific value. This typically results in the data being appended to the URI as a query parameter.
    • output: Defines how the data being sent by the client is transformed (e.g., base64;).

    Server Configuration

    • header: Sets response headers.
    • output: Defines how the server's response is handled (e.g., print).
    http-post{
    set uri "/hdq=&query=1";

    client {
        header "Accept" "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8";
        header "Host" "www.sogou.com";
        header "X-Requested-With" "XMLHttpRequest";
        header "Referer" "https://www.qq.com/";


        id {
            parameter "aleen";
        }
        
        output {
            base64;
            print;
        }

    }

    server {
        header "Server" "nginx";
        header "X-Log-Ext" "antiforbidden=1&exp_1=1&exp_2=1";

        output {
        print;
        }
    }

}

  7. Configure http-get blocks

    master

    The http-get block defines how the Beacon performs GET requests to the C2 server. It consists of a client section (defining what the Beacon sends) and a server section (defining how the server responds).

    Client Configuration

    • set uri: Defines the request URI.
    • header: Sets specific HTTP headers (e.g., Accept, Host, Referer).
    • metadata: Defines how Beacon metadata is transformed and transmitted. Common transformations include base64 encoding and prepend for adding prefixes. The result can be placed in a header using header "HeaderName".

    Server Configuration

    • header: Sets headers for the server's response.
    • output: Defines how the server's response data is handled. print sends the data as is.
    http-get{
    set uri "/hdq=sogou-wsse-3f7bcd0b3ea82268&ie=utf-8&query=1";

    client {
        header "Accept" "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8";
        header "Host" "www.sogou.com";
        header "Referer" "https://www.qq.com/";

        metadata {
            base64;
            prepend "session=";
            header "Cookie";
        }

    }

    server {
        header "Server" "nginx";
        header "X-Log-Ext" "antiforbidden=1&exp_1=1&exp_2=1";
        output {
        print;
        }
    }

}

  8. Understanding SMB Beacon and its communication model

    master

    An SMB Beacon is a specialized Cobalt Strike Beacon that communicates via Windows Named Pipes. Unlike standard Beacons that connect directly to a Teamserver, an SMB Beacon communicates through a parent Beacon. The traffic is encapsulated within the SMB protocol, making it stealthy and useful for bypassing firewalls.

    Key Characteristics:

    • Communication Path: Sub-Beacon $\rightarrow$ Parent Beacon $\rightarrow$ Teamserver.
    • Protocol: Uses SMB (typically over port 445).
    • Stealth: Traffic is encapsulated in SMB, which can help evade detection compared to direct HTTP/DNS traffic.

  9. Understand Cobalt Strike Listeners

    master

    Cobalt Strike uses Listeners to receive connections from payloads. In version 3.12, there are several types of listeners available:

    • beacon_x series: Native Cobalt Strike listeners including dns, http, https, and smb.
    • foreign series: External listeners typically used in conjunction with MSF (Metasploit) or Armitage.

    Note: Version 3.13 introduced windows/beacon_tcp/bind_tcp which supports Linux SSH sessions.

    windows/beacon_dns/reverse_dns_txt
windows/beacon_dns/reverse_http
windows/beacon_http/reverse_http
windows/beacon_https/reverse_https
windows/beacon_smb/bind_pipe
windows/foreign/reverse_http
windows/foreign/reverse_https
windows/foreign/reverse_tcp

  10. Basic syntax for variables, arrays, and hashes in Sleep 2.1

    master

    Sleep 2.1 uses specific prefixes to define different data types:

    • Variables: Use the $ prefix (e.g., $name = "value";).
    • Arrays: Use the @ prefix (e.g., @foo = @("a", "b");). Access elements via index: $x = @foo[1];.
    • Hash Scalars (Dictionaries): Use the % prefix (e.g., %bar = %(key => "value");).

  11. Use Data Transform Language for encoding

    master

    The Data Transform Language allows you to chain multiple encoding/decoding operations. You can combine any number of statements in sequence, but you must end the chain with exactly one termination statement.

    Common transformations include:

    • base64 / base64url: Base64 or URL-safe Base64 encoding/decoding.
    • mask: XOR mask with a random key.
    • netbios / netbiosu: NetBIOS encoding (case-sensitive).
    • append "string" / prepend "string": Adding or removing characters from the start or end.

    Termination Statements determine where the transformed data is stored:

    • header "header": Stores data in a specific HTTP header.
    • parameter "key": Stores data in a URI parameter.
    • print: Sends data as the transaction body (used in http-get.server.output, http-post.server.output, and http-stager.server.output).
    • uri-append: Appends data to the URI.

    If you use header, parameter, uri-append, or print within a client block (e.g., http-post.client.output), Beacon will automatically chunk the response to fit within a reasonable transaction length.

    append "string" | Append "string" | Remove last LEN("string") characters
base64       | Base64 Encode     | Base64 Decode
base64url    | URL-safe Base64 Encode | URL-safe Base64 Decode
mask         | XOR mask w/ random key | XOR mask w/ same random key
netbios      | NetBIOS Encode 'a' | NetBIOS Decode 'a'
netbiosu     | NetBIOS Encode 'A' | NetBIOS Decode 'A'
prepend "string" | Prepend "string" | Remove first LEN("string") characters

  12. Concept: Shellcode Evasion Strategy

    master

    To evade Antivirus (AV) detection, it is important to distinguish between the shellcode features (the static bytes) and the execution of shellcode.

    AVs often allow shellcode to be loaded into memory but will trigger an alert when the shellcode is actually executed. A common evasion strategy is to encrypt the shellcode and only decrypt it in memory immediately before execution, or to use encoders (like those in MSF) to change the shellcode's signature.