Who let the logs out? Woof.June 29, 2016
Logging is an important feature in any red team operations platform. Logs serve multiple purposes. Good logs aid reporting. If an operator needs output for some action or forgot what they did and when, logs help refresh the operator’s memory. Good logs also help with ground truth. Anyone who has worked red operations long enough knows that red teams get accused of all kinds of things. Good logs help put these matters to rest. Finally, good logs help with deconfliction. You want to know which activities are attributable to your operators and which ones are not theirs. Heaven forbid an adversary is already present in your customer’s network. Deconfliction matters.
With these points in mind, I put a great deal of effort to re-design Cobalt Strike’s logging in the 3.0 release. This blog post will take you through the information you need to get the most from these changes.
Where do the logs live?
Cobalt Strike 3.0 and later log everything on the team server. This is a departure from previous releases where logs lived with the client. The advantage to this scheme is twofold: (1) Cobalt Strike logs, whether a client is connected or not, and (2) the ground truth activity for a team server lives in one place.
Cobalt Strike’s logs are in the logs/ folder co-located with your team server’s current working directory. If your team server was run from /root/cobaltstrike, then the logs are in /root/cobaltstrike/logs.
Cobalt Strike organizes all of its logs by date. In the logs/ folder you’ll see folders with a YYMMDD format. For example, the folder logs/160629/ contains the logs from June 29, 2016.
Cobalt Strike has multiple types of logs to capture the different types of activity in the tool. Let’s go through these.
Beacon Session Transcripts
Cobalt Strike logs Beacon sessions to [target]/beacon_[session ID].log within the logs folder. These logs capture everything that occurred during a Beacon session. Each item in the log includes a date and timestamp, an entry type, and the information Cobalt Strike knows about the item.
Here are the types of session events Cobalt Strike logs:
The metadata entry provides information about the session. This information is usually found at the top of a Beacon log file. Consult this entry to see who the session ran as, which process it lived in, the computer name, and IP address of the target.
The input entry indicates that a command was issued. The log includes the command, its arguments, and the operator that issued the command.
The task entry is Cobalt Strike’s acknowledgement of input. This information shows you how Cobalt Strike interpreted the command given to it. These entries make a great running narrative of what happened in a Beacon session. In fact, I use this information quite heavily in Cobalt Strike’s reports.
The checkin entry documents when Beacon called home to grab tasks that were in its queue. This is helpful if you need to approximate when a queued command was run.
The output entry is the output of a command or action taken with Beacon.
Finally, Cobalt Strike tracks indicators made by some of it commands. For example, if you upload a file, Cobalt Strike will generate the MD5 hash of the file, and store this in its data model. Cobalt Strike also tracks these indicators as indicator entries in its log file. This information is helpful if you need to quickly de-conflict whether or not a file was put on target by one of your red team members.
Beacon’s logs surround the entry type with square brackets. This makes it easy to grep for different types of log entries. For example, if you want to find all of the indicators in your logs, use grep –r “\[indicator\]”. from the logs folder.
The events.log file documents activity from Cobalt Strike’s event log. The event log is essentially an operator chat and a central place to push notices to members of your team.
Keystrokes (Session Specific)
Keystrokes captured by Beacon are stored in the [target]/keystrokes/ folder within that day’s logs folder. Cobalt Strike stores these in keystrokes_[Session ID].txt. The Session ID is the Beacon’s session ID. The contents of these files is the same information you see when you go to View -> Keystrokes in Cobalt Strike.
Cobalt Strike also tracks information about each of your phishing engagements too. These are located in phishes/campaign_[unique ID].log. Each phishing salvo from Cobalt Strike is assigned a unique campaign ID and each salvo gets its own log file. This file documents meta-information about the campaign, who you sent the phish to, when, and whether or not the message was accepted by the mail server.
Screenshots (Session Specific)
Screenshots taken with Beacon are stored with the logs as well. Cobalt Strike stores these in the [target]/screenshots folder. The naming convention of these files is screen_HHMMSS_SessionID.jpg. The HHMMSS represents the time the screenshot was reported by your Beacon. The Session ID part of the filename is the Beacon session the screenshot came from.
Cobalt Strike has several keyboard shortcuts to take screenshots while you use Cobalt Strike. Ctrl+P takes a screenshot of the current active visualization. Ctrl+T takes a screenshot of the current tab. Ctrl+Shift+T takes a screenshot of the entire Cobalt Strike window.
Cobalt Strike pushes these screenshots to the team server and they live in the screenshots/[operator name] folder within the logs directory. The screenshots are named HHMMSS_[screenshot title].png. The HHMMSS part is the time the screenshot was taken. The title is dependent on the type of screenshot taken and where. For example, in the case of Ctrl+T, the title part of the filename is the tab’s title.
The weblog.log file tracks hits on Cobalt Strike’s web server. This file follows Apache’s logging conventions.
Cobalt Strike’s Website Clone Tool has an option to log keystrokes on the cloned website. These keystrokes show up under View -> Web Log in Cobalt Strike’s user interface. The webkeystrokes.log file captures these keystrokes in a central place for review after the engagement.
The logs in Cobalt Strike 3.0 and later are a vast improvement over the tool’s previous logging implementation. The new logs make it easier to get ground truth on red team activity, to perform deconfliction, and to revisit key information from your engagement (commands, keystrokes, screenshots, output) to make better reports. I hope this post helps you get the most from this very important feature.