When Red Team became Blue Team

The other day I read amazing presentation from Black Hills Information Security about how Blue Team can benefit from using Red Team tools and techniques to improve general security posture and their detection capabilities and started thinking if this works the other way. How Red Team can apply Blue Team tools, techniques and tactics to improve their foothold, stay under radar as much as possible and move detection and response to the next level.

Just imagine — you established initial access to the network, and before running mimikatz or network scan you started collecting Windows logs. From log information you can get understanding about what services are running, for example log forwarder which sends logs to Blue Team SIEM or Tire 2 Analytic started using EDR solution to get process information or computer memory dump. Let’s move even further, we configured our own Red SIEM, collected logs using our beacons and started writing “Blue Team detection” detection to alert whenever someone runs artifactcollector.exe so we would know in real-time that we have been detected. After that we can configure alert action to pull strings using some SOAR solution to kill artifactcollector.exe process and let the “battle of SIEMs” begin.

While this looks like some sci-fi movie I decided to build simple PoC solution using CobalStrike and Splunk.

Development process looks pretty the same as security monitoring by Blue Team:

• define data sources
• configure connectors and data ingestion
• develop use-cases
• testing

Data sources

While this can be everything Security Operation Center would use like Windows Security or Sysmon logs, let’s keep it simple and just collect running process information similar to how Splunk Add-on for Unix and Linux works. If you would have admin permissions on the host you could use wevtutil tool to query process creation logs or try to hijack windows logs using Windows Event Forwarding to your own rogue WEC server tunneling all data through beacon.

Configure connectors and data ingestion

Cobaltstrike can be heavily automated and programmed using aggressor-scripts. Also there is amazing repository with python bindings to make things simple which I will be using.

First things first we need to create cobaltstrike aggressor script to launch our python code. Here you need to defined path to pycobalt’s aggressor directory and name of your python code to run.

Python code looks pretty simple — with certain time interval iterate over all beacons and task them to list active process. To be able to task beacon with process listing we need to activate beacon window and that is where aggressor.openOrActivate() method comes to rescue. Next problem we will be facing is case where we can have multiple beacons on the same host or heartbeat interval of our script and beacon sleep time can be different which will cause running process listing multiple times. That’s why we are using QUEUE to track all IPs and tasks.

Engine.message() method is used to track script progress and print results to script console.

In ps_callback function we need to handle process listing results and generate events which should be easy to ingest by our SIEM and clear QUEUE.

We should get next results if we open script log file.

Now, let’s start ingesting cobalt_ps_collector.py script log into SIEM.

1. Select Monitor file and ports on this Splunk platform instance.
2. Select path to cobalt_ps_collector.py script log file.
3. At Set Source Type configuration select Event Breaks->Every Line
4. You can use default index but I suggest creating new one, in case you break something.

Now, if you search using specified before index you should get your first events.

Develop use-cases

Our “Blue team” detection use case will be looking for active process of artifactcollector.exe. Basically we need to check if pname(Process name) is equal to artifactcollector.exe.

Save this search as alert.

Testing

At this point we should be ready to fire up our first alert with running artifactcollector on infected host.

Final alert

Summary

Red Team can definitely benefit from collecting host logs for environment awareness instead of simple “Get-DomainAdmin” path bruteforce. It’s better to know that you have been watched and stay under radar as long as possible instead of triggering tons of critical alerts right after getting initial foothold. “Blue team detection” use-cases can vary from checking for “Blue Team tools” process name to understanding environment to blend in with usual activity.

Looking forward for your ideas about how and what you would detect using environment logs as Red Teamer in the comments!

Full code for cobalt script to collect active processes.