Typically we evaluate which type of attack based on the requirements. An example Test procedure is shown as an example:

TEST PROCEDURE

The overall command-and-control test procedure included six main categories of attack scenarios executed using the Cobalt Strike attack framework. Each of the six categories examines a major aspect of the respective product’s capabilities in a specific real-world scenario. HTTP over TCP port 80 was used for command-and-control communication unless otherwise noted. For each profile tested, a stageless implant/beacon was generated and delivered to the “victims” for execution out-of-band prior to testing. In other words, only the capability of the product to intervene and protect against Cobalt Strike callback network activity was tested, not the ability to block the initial delivery of the beacon itself; exploitation and delivery of the beacon are assumed to have already taken place. The types of attacks we evaluated are: 1. Basic Attack Scenario: This test was performed to evaluate the product’s basic protection against the most commonly available public attack profiles attempting data exfiltration and malware delivery via HTTP. The basic attack scenario included three subcategories: Normal, Crimeware, and APT.

1. Each scenario had a multitude of profiles that were evaluated as a part of the Cobalt Strike attack framework.

2. Random Attack Scenario: This test was performed to evaluate the protection when the data transform language utilized in Cobalt Strike is leveraged to generate “randomized” attack scenarios using tools that are part of the Cobalt Strike arsenal of researchers and the public. This randomization increases the probability wherein the traditional threat defenses of the firewall might be rendered ineffective against data exfiltration and malware delivery.

3. Custom Attack Scenario: This was the first of the confirmation tests, which used a smaller profile set. This test was performed using purposely chosen and modified attacks from the Basic and Random attack scenarios. The modifications were made to attacks that were previously blocked, to confirm whether the modifications would be sufficient to bypass the defenses. Modifications were made on the different variables that are supported for customization. The variables were modified using data transform language.

4. Nonstandard ports-based Attack Scenario: The purpose of this testing was to confirm if the next-generation firewalls can continue to provide protection when attacks use HTTP over a nonstandard port.

5. HTTPS Attack Scenario: The purpose of this testing was to confirm if the next-generation firewalls provide the same level of protection when attacks are delivered via HTTPS rather than HTTP.

6. Hostname Change Attack Scenario: The purpose of this testing was to confirm if the next-generation firewalls continue to provide the same level of protection when the threat actors adjust/seed/modify the hostname used by a profile in order to evade reputation-based protection. The tests did not have equal sample sizes. The Custom Attack Scenario, Nonstandard Ports-based Attack Scenario, HTTPS Ports-based Attack Scenario, and the Hostname Change Attack Scenario were verification exercises.

Thus, they did not require many profiles. As a result, the vast majority of profiles were run in the Basic Attack Scenario and Random Attack Scenario.