AutorunEngine: Refactor execution_order and execution_delay

[bcoles]

Each autorun rule specifies a execution_order and execution_delay properties.

These values are fiddly to configure, confusing for new users, add unnecessary complexity, and are often unnecessary. (#2541)

Execution Order

execution_order specifies the order in which modules are executed. For example:

beef/arerules/c_osx_test-return-mods.json

Line 32 in f8cba6e

"execution_order": [0, 1, 2, 3],

Every existing autorun engine rule specifies an execution order of incremental integers; or often simply just [0].

# grep -rn _order arerules/*.json
arerules/alert.json:15:  "execution_order": [0],
arerules/coinhive_miner.json:17:  "execution_order": [0],
arerules/confirm_close_tab.json:17:  "execution_order": [0],
arerules/c_osx_test-return-mods.json:32:  "execution_order": [0, 1, 2, 3],
arerules/ff_osx_extension-dropper.json:17:  "execution_order": [0],
arerules/get_cookie.json:15:  "execution_order": [0],
arerules/ie_win_fakenotification-clippy.json:28:  "execution_order": [0,1],
arerules/ie_win_htapowershell.json:24:  "execution_order": [0,1],
arerules/ie_win_missingflash-prettytheft.json:24:  "execution_order": [0, 1],
arerules/ie_win_test-return-mods.json:32:  "execution_order": [0, 1, 2, 3],
arerules/lan_cors_scan_common.json:20:  "execution_order": [0],
arerules/lan_cors_scan.json:25:  "execution_order": [0, 1],
arerules/lan_fingerprint_common.json:20:  "execution_order": [0],
arerules/lan_fingerprint.json:25:  "execution_order": [0, 1],
arerules/lan_flash_scan_common.json:19:  "execution_order": [0],
arerules/lan_flash_scan.json:24:  "execution_order": [0, 1],
arerules/lan_http_scan_common.json:20:  "execution_order": [0],
arerules/lan_http_scan.json:25:  "execution_order": [0, 1],
arerules/lan_ping_sweep_common.json:17:  "execution_order": [0],
arerules/lan_ping_sweep.json:22:  "execution_order": [0, 1],
arerules/lan_port_scan.json:26:  "execution_order": [0, 1],
arerules/lan_sw_port_scan.json:22:  "execution_order": [0, 1],
arerules/man_in_the_browser.json:14:  "execution_order": [0],
arerules/map_network.json:59:  "execution_order": [0, 1, 2, 3, 4, 5, 6],
arerules/raw_javascript.json:16:  "execution_order": [0],
arerules/record_snapshots.json:16:  "execution_order": [0],
arerules/win_fake_malware.json:35:  "execution_order": [0,1,2],

Users should not be required to specify this attribute. The order should be configured automatically.

When running only a single module this attribute is unnecessary. When running in sequential mode, the modules should be executed in the order they are provided in the rule file.

Presumably, this attribute exists as modules are stored with modules.to_json which may re-order the module keys. Instead of using a separate execution_order key, the modules should be stored with an associated order ID as part of the modules array.

Execution Delay

execution_delay specifies a setTimeout delay before the module is executed on the hooked browser. For example:

beef/arerules/c_osx_test-return-mods.json

Line 33 in f8cba6e

"execution_delay": [0, 0, 0, 0],

Many existing autorun engine rules specify an execution delay of 0 for every module.

# grep -rn _delay arerules/*.json
arerules/alert.json:16:  "execution_delay": [0],
arerules/coinhive_miner.json:18:  "execution_delay": [0],
arerules/confirm_close_tab.json:18:  "execution_delay": [0],
arerules/c_osx_test-return-mods.json:33:  "execution_delay": [0, 0, 0, 0],
arerules/ff_osx_extension-dropper.json:18:  "execution_delay": [0],
arerules/get_cookie.json:16:  "execution_delay": [0],
arerules/ie_win_fakenotification-clippy.json:29:  "execution_delay": [0,2000],
arerules/ie_win_htapowershell.json:25:  "execution_delay": [0,500],
arerules/ie_win_missingflash-prettytheft.json:25:  "execution_delay": [0, 5000],
arerules/ie_win_test-return-mods.json:33:  "execution_delay": [0, 0, 0, 0],
arerules/lan_cors_scan_common.json:21:  "execution_delay": [0],
arerules/lan_cors_scan.json:26:  "execution_delay": [0, 0],
arerules/lan_fingerprint_common.json:21:  "execution_delay": [0],
arerules/lan_fingerprint.json:26:  "execution_delay": [0, 0],
arerules/lan_flash_scan_common.json:20:  "execution_delay": [0],
arerules/lan_flash_scan.json:25:  "execution_delay": [0, 0],
arerules/lan_http_scan_common.json:21:  "execution_delay": [0],
arerules/lan_http_scan.json:26:  "execution_delay": [0, 0],
arerules/lan_ping_sweep_common.json:18:  "execution_delay": [0],
arerules/lan_ping_sweep.json:23:  "execution_delay": [0, 0],
arerules/lan_port_scan.json:27:  "execution_delay": [0, 0],
arerules/lan_sw_port_scan.json:23:  "execution_delay": [0, 0],
arerules/man_in_the_browser.json:15:  "execution_delay": [0],
arerules/map_network.json:60:  "execution_delay": [0, 0, 0, 0, 0, 0, 0],
arerules/raw_javascript.json:17:  "execution_delay": [0],
arerules/record_snapshots.json:17:  "execution_delay": [0],
arerules/win_fake_malware.json:36:  "execution_delay": [0,0,0],

A zero delay should be implied if not specified.

When running in chained-forward mode the delay is unnecessary as modules must wait until the previous module is executed.

Instead of using a separate execution_delay key, the delay for each module should be stored with the associated module as part of the modules array (with a value of 0 by default).

[github-actions]

This issue as been marked as stale due to inactivity and will be closed in 7 days

[github-actions]

This issue as been marked as stale due to inactivity and will be closed in 7 days