Cobalt Strike is a commercial, full-featured, remote access tool that bills itself as “adversary simulation software designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors”. Cobalt Strike’s interactive post-exploit capabilities cover the full range of ATT&CK tactics, all executed within a single, integrated system. In addition to its own capabilities, Cobalt Strike leverages the capabilities of other well-known tools such as Metasploit and Mimikatz.
Cobalt Strike is a legitimate security tool used by penetration testers and red teamers to emulate threat actor activity in a network. However, lately, this tool has been hijacked and abused by cybercriminals.
Our goal was to develop a tool to help identify default Cobalt Strike servers exposed on the Internet. We strongly believe that understanding and mapping adversaries and their use of Cobalt Strike can improve defenses and boost organization detection & response controls. Blocking, mapping and tracking adversaries is a good start.
A review of existing Cobalt Strike detection tools and public research showed that current tools can only scan a small number of potential Cobalt Strike instances (1-5k hosts). Our goal was to increase the scanning capabilities and validate several million potential Cobalt instances in less than an hour.
To achieve the above goal within a reasonable timeframe and on a small budget, it was necessary to adapt and scale the current understanding of the Cobalt Strike hunting methodology. The following content assumes an understanding of what Cobalt Strike is and how to locate and identify Cobalt Strike instances. Before going into the details of the tool and their components, let’s take a look at the general architecture.
https://github.com/shabarkin/pointer
Scanning a large number of hosts in a reasonable amount of time does not scale and has physical, cost and power limitations. Unless you have a great home lab and the bandwidth to support it, personal computing cannot really solve the scaling problem, so the decision was made to use AWS to affordably scale and achieve the desired goals.
The tool is developed and heavily based on AWS SQS, Lambda and DynamoDB.
The Pointer client parses the local json file with a list of IPs, optimally splits them into packets (10-20 IPs), and then adds the packets to be processed to the SQS queue.
The SQS queue is setup to invoke a lambda function for each packet in the queue. The lambda function (Pointer server) performs the actual scanning of the provided packet of IPs and saves results to DynamoDB.
In cases where Lambda fails or throws an error, packets are returned to the SQS queue and will wait for a retry.
If the packet fails a second time, a new Lambda function is launched that logs the failed packet to DynamoDB for further analysis and rescan each IP individually to locate the failed IPs.