Taking part in ethical hacking exercises such as pentesting is a valuable practice for hardening your security posture. Pentesting can help identify gaps and detect security vulnerabilities across an organization’s threat landscape, finding weaknesses before threat actors do, but only as long as the test results can be trusted
Such an important exercise for ensuring and maintaining a strong security stance must be done properly, on a regular basis, and accurately. Accuracy is especially critical for organizations that must meet compliance requirements for security auditing procedures, including PCI DSS and SOC 2.
Many XDR/EDR solutions handle threats differently and will identify and block them at different stages, and improper testing may not trigger detections the same way a real attack would. For instance, if a test does not attempt to fully compromise an endpoint, the results could provide a false understanding of your product capabilities. To help ensure valid pentesting outcomes are achieved, this blog will focus on best practices and potential pitfalls when pentesting and/or simulating attacks in a Cortex XDR environment.
There are several forms of pentesting, from testing physical access to remote access and compromise. However, it is important to understand the limitations of each method to ensure the successful detection of threats and avoid inaccurate results. Always keep in mind that the idea is to test the security of your overall environment, not how secure a single endpoint is by itself.
While “homemade” threats can replicate parts of real ransomware and be useful in some tests, we have seen these types of tests fail to provide accurate results for a number of reasons, which will be detailed further below. As such, when possible it is best to test using real samples of the ransomware and wipers found in the wild, rather than something homemade.
Using Cortex XDR in Your Pentesting Arsenal
Cortex XDR is an agent-based solution that is loaded onto hosts to help protect against threats that access a host or utilize a host after it has been compromised or even ransomed.
We will describe an appropriate test that uses Cortex XDR to evaluate endpoint coverage, but before you start the test, you should prepare with the internal or external tester.
Initial recommendations:
- Have one or more hosts that are setup as targets.
- Ensure that you are using live threats, not something that is “live like”.
- Make sure you understand how a vendor's product works to protect you. Is it pre- or post-execution or both, as an example.
- Find out if you need the vendor to perform a best practices review of your system prior to testing.
- Make sure product features in scope actually exist in the product. Do not expect to see alerts for network activity if your product only looks for file-based threats.
Setting Up the Environment
We highly recommend that you take at least one host (although more is better), and dedicate it to the pentests/simulation to allow the tester to compromise an asset without worrying that it will disrupt and/or corrupt the test environment. This can be accomplished by taking an existing host, cloning it, and using the clone as the target for the tests.
Depending on the scope of the test, you may need an isolated host or have the target host in a VM or cloud instance to avoid an unintentional environmental compromise. This host would look like an existing system, complete with all the downloads and installed applications some of your users may have which provides a wide range of attacks to be performed.
Clones are especially effective if you are doing ransomware testing. Due to how XDR systems detect ransomware, for example using canary files, if a system is not made fully available to be compromised with this method you can end up with false results.
Simulating Attacks Effectively
Once you have a realistic and isolated testing environment, you'll want to ensure that testing accurately simulates how threat actors work and how malware behaves. Too often, simulated attacks will evade detection simply because they aren’t doing anything truly malicious.
For example, if a pentester creates ransomware that simply makes and then encrypts a file on the system that would not prove the host is susceptible to being ransomware compromised, because the test fails to simulate how attacks occur in the wild. Ransomware that we see in the wild often implements different techniques to identify files of interest to an attacker. Because these techniques are malicious or not normal in their behavior, they will be detected.
It is also important to complete the compromise. For example, creating a TCP connection and writing a file to disk is not an accurate test of compromise; this is normal activity done on a daily basis. What this actually reflects is that initial steps of a compromise might happen without detection, but it is by no means a demonstration of a compromise.
Similarly, other tests might consider it a compromise if “malicious” files are copied and pasted into a host folder that the pentester is using, and then they are executed only within that newly created folder. This is also not necessarily an accurate test because while malware payloads may be delivered soon after an attacker gains access, when executed they go beyond the folder where they are executed.
In order to accurately depict a true compromise there needs to be something malicious or nefarious in the payload, something like previously discussed ransomware, data exfiltration, or even lateral movement. This is another reason why a target system or systems should be set up for the tester, and why the target systems should be clones of actual machines in the environment. Clones will act like real world systems because they essentially are.
For all of these reasons, testing with live malware is better and more accurate than malware that is not actually malicious, but doing so comes with its own challenges, like the possibility of network compromise. Take proper precautions when using live payloads. For additional information you can see the blog post, “Ransomware Simulators - A Reality or Bluff?”
Another option for more effective pentesting is to refer to the MITRE ATT&CK framework to help plan testing scenarios, and assess cyber threat defenses.
Best practices for using this framework for pentesting include:
- Using real-world tactics from the Groups list.
- Use the attack matrices to find and fill gaps in defenses.
- Be aware of differing implementations of various techniques.
Questions to Ask
Having all of these best practices in mind will be especially helpful when preparing with an internal or external tester. Additionally, there are some questions you should get answers to prior to kickoff:
- What is the objective of the test/simulation?
- What stages of an attack will your test include?
- Are you doing a pentest or a simulation?
- Are you doing this in a live environment or in a lab environment?
- If you are doing it in a live environment, do you have a target host identified?
- Are you looking beyond the endpoints as part of the scope?
- How are the attacks going to be delivered to and then executed on the host?
Once testing begins, it is also important to understand the full range of the test or simulation. When it is reported that “your agent” did not stop the attack, pause, take a step back, and consider these questions:
- What did it take for the attacker to get to the host machine?
- What did your firewall see?
- What did your email filter detect?
- Did your web filter get triggered?
- What was missed?
These are important to understand because the endpoint is the last stop for an attacker. You should have protections in place to prevent a file from getting on your host systems and damaging them, so make sure those are also in scope for the simulation or pentest. Evaluate those results as well. After all, as said before, the idea is to test the security of your environment, not how secure a single endpoint is by itself.
Conclusion
While simulations or pentests can be very helpful in making sure your tools are working the way a vendor says they should, if they are not performed in an appropriate way you will get poor results. Understanding that Cortex XDR is very effective in blocking real-world attacks will help set expectations and the importance of proper testing. Work with your tester and consider the points above to get the best possible results. Doing these tests correctly will save you any anxiety around whether you are getting the solution that best fits your needs.