Skip to main content

​
Build Parameters

Build parameters are defined on a payload type’s definition and allow you to configure a payload build in a way outside of C2 specific configurations. These parameters are defined in an array with a few specific fields. Below are examples in Python and Go:
  • Python
  • Go
build_parameters = [
        BuildParameter(
            name="output_type",
            parameter_type=BuildParameterType.ChooseOne,
            choices=["WinExe", "Shellcode", "Service", "Source"],
            default_value="WinExe",
            description="Output as shellcode, executable, sourcecode, or service.",
        ),
        BuildParameter(
            name="shellcode_format",
            parameter_type=BuildParameterType.ChooseOne,
            choices=shellcode_format_options,
            default_value="Binary",
            description="Donut shellcode format options.",
            group_name="Shellcode Options",
            hide_conditions=[
                HideCondition(name="output_type", operand=HideConditionOperand.NotEQ, value="Shellcode")
            ]
        ),
        BuildParameter(
            name="shellcode_bypass",
            parameter_type=BuildParameterType.ChooseOne,
            choices=shellcode_bypass_options,
            default_value="Continue on fail",
            description="Donut shellcode AMSI/WLDP/ETW Bypass options.",
            group_name="Shellcode Options",
            hide_conditions=[
                HideCondition(name="output_type", operand=HideConditionOperand.NotEQ, value="Shellcode")
            ]
        ),
        BuildParameter(
            name="adjust_filename",
            parameter_type=BuildParameterType.Boolean,
            default_value=False,
            description="Automatically adjust payload extension based on selected choices.",
        ),
        BuildParameter(
            name="debug",
            parameter_type=BuildParameterType.Boolean,
            default_value=False,
            description="Create a DEBUG version.",
        )
    ]
Each build parameter has a few different pieces you can specify:
  • name - the name of the parameter (this is required)
  • description - the description of the parameter - this is displayed along with the name to give users more context about what the parameter is doing
  • required - this indicates if the user is required to specify something or not
  • parameter_type - this is the type of value for this and can be boolean, number, choose one, choose multiple, file, string, dictionary, date, array (of strings), array of files
  • default_value - the default value for the field
  • choices - a list of choices to present for a choose one or choose multiple display
  • supported_os - optional list of strings of operating systems that work with this parameter. This is the same “OS” selection that you specify as part of your supported os for the payload type definition. For example, if this is “Linux”, but the user selected “macOS”, then this option will NOT be presented to the user.
  • group_name - optional name you can specify to group parameters together logically in the UI
  • hide_conditions - an optional list of HideConditions (only one element in the hide condition needs to be true for the entire thing to be hidden)

​
Hide Conditions

Hide conditions on a build parameter allow you specify, based on the values of other build parameters, if the current build parameter should be hidden from view or not. A good example would be to hide build parameters related to shellcode options if another option specify the output type isn’t shellcode. Hide Conditions are generally defined as: 
HideCondition(name="output_type", operand=HideConditionOperand.NotEQ, value="Shellcode")
  • name - this specifies the name of the OTHER build parameter that you’re looking at
  • operand - this specifies the “operand” that we’re going to use. This can be one of the following:
    • eq - equal
    • neq - not equal
    • in - in
    • nin - not in
  • value - this is what we’re comparing the current option’s value to. In the above example, we would HIDE that build parameter if the output_type build parameter’s value is Not EQ to the value Shellcode.
    • if you’re using in or nin, then instead of value you’d specify choices

​
C2 Parameter Deviations

This is another really powerful addition in Mythic 3.4 - the ability for a payload type to define a variation to a supported c2 profile. This is part of the payload type’s definition, but allows you to make light modifications to any parameter for a supported c2 profile. The only thing you can’t do is add new parameter values - only remove or modify.
  • Python
  • Go
c2_parameter_deviations = {
        "http": {
            "get_uri": C2ParameterDeviation(supported=False),
            "query_path_name": C2ParameterDeviation(supported=False),
            "headers": C2ParameterDeviation(supported=True, dictionary_choices=[
                DictionaryChoice(name="User-Agent", default_value="Hello", default_show=True),
                DictionaryChoice(name="HostyHost", default_show=False, default_value=""),
            ])
        }
    }
The above shows an example of configuring the c2 parameter deviations in python and go. They’re pretty straight forward, but they might look intimidating. They are dictionaries (map in go) where the first key is the name of the c2 profile. That value is another dictionary that maps the name of the parameter to a C2ParameterDeviation object. The C2ParameterDeviation object has a few fields:
  • supported - indicate if this field is supported or not. If it’s not supported, then it won’t be shown to the user.
  • default_value - your own default value instead of the one that’s normally provided
  • choices - your own set of choices instead of those that are provided
  • dictionary_choices - your own set of dictionary choice objects instead of what’s normally provided
⌘I