Mythic Documentation
Version 3.3
Version 3.3
  • Mythic
  • Operators
  • Installation
    • Connecting
    • A note about containers
    • Offline Installation
    • Updating Mythic
  • Internal Documentation
  • Quick Usage
  • Operational Pieces
    • MITRE ATT&CK
    • Operations
    • Browser Scripts
    • Active Callbacks
    • Files
    • Search
    • File Browser
    • Socks Proxy
    • Credentials
    • Comments
    • Tags
    • Expanded Callbacks
    • Screenshots
    • Event Feed
    • Understanding Commands
      • Basic Information
      • Parameters
      • MITRE ATT&CK in Commands
    • Payload Types
      • Containers
    • C2 Profiles
      • C2 Server Utilities
      • Egress vs P2P
      • HTTP
      • dynamicHTTP
      • Save Parameters
    • API Tokens
  • Message Flow
    • Building Payloads
    • Agent Sends Message
    • File Upload Mythic->Agent
    • File Download Agent->Mythic
    • P2P Messages
    • Operator Submits Tasking
  • Database Schema
  • Reporting
    • Artifacts
    • MITRE ATT&CK
    • Reports
  • Scripting
  • Presentations / Webinars
  • Common Errors
  • MythicTips
  • Customizing
    • Customizing Public Agent
    • Hooking Features
      • Actions
      • Linking Agents
        • P2P Connections
      • Process Browser
      • Artifacts
      • Credentials
      • File Downloads (Agent -> Mythic)
      • File Uploads (Mythic -> Agent)
      • Screenshots
      • Add / Remove Commands
      • Keylog
      • File Browser
      • Tokens
      • Alerts
      • SOCKS
      • RPFWD
      • Interactive Tasking
      • Task Status
      • OnContainerStart
    • 1. Payload Type Development
      • 2. Payload Type Definition
        • Container Syncing
        • Turning a VM into a Container
      • 3. Adding Commands
        • Commands
      • 4. Create Tasking & Comms Format
        • Agent Messages
          • 1. Agent Message Format
          • 2. Checkin
          • 3. Get Tasking
          • 4. Submitting Responses
          • 5. SOCKS
          • 6. Reverse Port Forward
          • 7. Peer-to-peer messages
          • 8. Interactive Tasking
      • 5. MythicRPC
      • 6. Browser Scripting
      • 7. Dynamic Parameter Values
      • 8. Sub-tasking / Task Callbacks
      • 9. OPSEC Checking
      • 10. Translation Containers
      • 11. Process Response
      • 12 TypedArray Parse Function
      • 13. SOCKS
      • 14. Reverse PortFwd
      • 15. Interactive Tasking
    • 2. C2 Development
      • Docker & Server Config
        • 1. Docker Containers
        • 2. Configuration Files
        • 3. OPSEC Checks
        • 4. Configuration Checks
        • 5. Sample Message
        • 6. File Hosting
        • 7. Redirect Rules
        • 8. Get IOC
        • 9. Push C2
    • 3. Consuming Containers
      • Webhooks
      • Logging
      • Eventing
        • Operator Context (run_as)
        • Workflow Triggers
        • Steps
      • Auth
    • 4. Extending Agent Commands
    • Mythic UI Development
  • Common Questions and Answers
    • FAQ / Troubleshooting Tips
    • Change Log
    • Tip of the Week
  • Updating
    • Mythic 2.1 -> 2.2 Updates
      • Agents 2.1.* -> 2.2.8
        • MythicRPC
    • Mythic 2.2 -> 2.3 Updates
      • Agents 2.2 -> 2.3
    • Mythic 2.3 -> 3.0 Updates
      • Agents 2.3 -> 3.0
    • Mythic 3.2->3.3 Updates
Powered by GitBook
On this page
  • What is it?
  • Components

Was this helpful?

Export as PDF
  1. Customizing
  2. 3. Consuming Containers

Eventing

PreviousLoggingNextOperator Context (run_as)

Last updated 8 months ago

Was this helpful?

What is it?

Eventing is a way to automatically perform actions based on some "event" within Mythic. The format and flow for this was heavily modeled after GitHub Actions, so if you're familiar with that then this should come pretty easily.

Components

There are a few components that make up an eventing workflow. Let's see what happens when you click the "New Event Groups" but on on the left hand side and select a file/multiple files to upload:

  1. The original eventing workflow file. This is a YAML, JSON, or TOML file that contains information about the entire workflow. In Mythic's GraphQL API, each eventgroup has a file_id that points to this file so that the contents can always be fetched later. Clicking the image folder icon under "actions" will display this file in the UI.

  2. After loading the workflow file and creating an eventgroup, each step is analyzed and parsed into an eventstep associated with that event group.

  3. When an event happens and triggers a workflow, then an eventgroupinstance is created to track that specific instance along with eventstepinstance for each step. This is how Mythic is able to tell all the different pieces from each other. These instances are tracked in the table below.

Once you select a workflow on the left, you'll see a bunch more information appear on the right. Let's look at that top table first:

  • Author - this is the user that uploaded the workflow file

  • Created At - this is when the user uploaded the workflow file

  • Trigger - this is what "event" within Mythic will cause this workflow to execute

  • Keywords - these are optional additional words you can use to kick off this workflow. For example, maybe you want something to execute each time there's a new callback. However, as part of something else you're doing, you want to execute this workflow anyway - you can associate a keyword with the workflow and then use that to execute the workflow at any time (more on that later).

  • Env - this is extra, global data you can access and pass into all of the steps in a workflow. You can set this via the environment keyword.

  • Actions - this is a set of additional actions you can take on this workflow

    • If the trigger is manual or keyword, then the green play button will appear here and you can manually trigger this workflow.

    • The popout icon allows you to see the step flow graph in a bigger view

    • The file image icon allows you to see the backing file for this workflow

    • The paperclip icon allows you to upload additional files for this workflow. These files can then be referenced from within your steps (this is how, for example, you can handle issuing tasks that might need to upload files)

    • The layered square icon gives context about additional services that might need to be running for this workflow to execute successfully. If this is red (with a number), then one or more additional services are needed (such as custom functions and conditional checks), but they're offline.

  • Graph: The big graph in the middle shows all the steps associated with this workflow and their dependencies. You can right-click any step and click "View Details" to get more contextual information about each specific step within the workflow overall.

A disabled event group workflow can't run new instances, but still shows up by default in the UI. A deleted event group workflow can't create new instance and doesn't show up by default in the UI.

Context - this is additional context about the workflow to help decide if/when it should execute. For example, with the new callback trigger, you can use this context to limit which types of payloads you want to execute. A good example would be that you want to run some situational awareness commands when there's a new callback, but you only want to do it for Windows payloads. This is trigger_data in .

Workflow Triggers