Adversary simulation: what you need to know

The adversary simulation team are likely to repeat this process throughout the engagement. As mentioned previously, this work is undertaken by the team providing the service, and should not be the result of a procured threat intelligence product.

Now that the adversary simulation has commenced, the reconnaissance is likely to be more active than passive. Active reconnaissance involves direct interaction and runs the risk of being detected. It can include, but is not limited to:

• limited port scanning
• visiting the customer organisation’s websites
• surveying available online services

For full spectrum engagements, the adversary simulation team uses reconnaissance findings to identify potential access points to the customer’s internal IT systems. Common techniques include phishing or watering hole attacks, which may have been identified in the scoping phase as potential attack vectors. The team may identify additional opportunities during active testing and discuss them with the customer.

For assumed breach engagements, the team will start from a point within the customer network. There are numerous ways to achieve this, for example customer staff may be included as part of the engagement to facilitate the adversary simulation team’s initial access to the network.

For both types of engagements, it is important that the team establishes and discusses the escalation process during the scoping phase, so that, if the customer’s defensive security team detects the attack, there are some pre-agreed options covering the course of action the customer will take.

Once the adversary simulation team has established a foothold on the customer network, it works towards the objectives agreed during the scoping phase. This is a crucial phase where the customer’s internal capability to detect and identify anomalous behaviour and protect its most critical functions is tested. If the team achieves one or more objectives without detection, they will advise the customer and then agree how to proceed. Note that it is for the customer to determine whether an objective has been met (in conjunction with the evidence provided by the adversary simulation team).

If the objectives have been met, the customer and adversary simulation team may choose to agree additional activities in the remaining timescales. It is important that the necessary permissions are in place for such activity, and that this is documented. Such activities may include identifying alternative approaches to achieve the same result, or gradually increasing the ‘noise level’ until the detection team becomes aware of the attack.  

If the adversary simulation team cannot gain a foothold from an external vantage, the testing may proceed using a de-chain action whereby the customer provides a (typically low-privileged/standard) user account or a device with credentials, from which the team can continue to work towards the agreed objectives.

Using a de-chain action should be a serious consideration if the engagement stalls and the provider is not making progress. This is still valuable as it provides insight on the risks faced from trusted third-parties, or from malicious insiders seeking to access the customer’s most sensitive data. However, the customer and the adversary simulation team need to carefully judge the best time for switching approaches, balancing the benefit of faster progress with the consequences of losing insight into the resilience of the systems to attack from outside. 

A de-chain action may also be used in other scenarios, such as where an attacker has a capability not available to the adversary simulation team at present (for example zero-day vulnerabilities), or in a scenario where the adversary simulation team have identified an attack path which the customer does not wish them to exploit.

The use of a de-chaining action reflects a mature approach to testing. Rather than being constrained by a single attack path, it enables testing to remain focused on the organisation’s most significant risks and the outcomes that matter most. By redirecting effort where it will provide the greatest insight, a de-chaining action helps maximise the value of the engagement and strengthens confidence in the organisation’s overall resilience.

In this phase, the adversary simulation team remove from the customer’s system all artefacts that were created during the engagement. If they are unable to remotely remove artefacts, the team must document them and provide to the customer details of how to safely remove them. Note that the adversary simulation team may advise that rebuilding a host is the only viable solution.

In addition, as secrecy is no longer necessary, the customer’s internal detection team may wish to more thoroughly review all potential indicators of compromise (IoCs) that might have been flagged but not acted upon during the test window. This will allow the customer to immediately start to learn from the engagement while waiting for the report to be produced.

Throughout the engagement, the adversary simulation team must keep a contemporaneous record of all activity. This provides evidence in the event of any disputes resulting from the test, such as proof that Technique A was used on Host B. A sanitised version of the record can be provided to the defensive security team to aid in detection of the IOCs and to provide opportunities for staff training.