- #Cobalt strike beacon meterpreter full
- #Cobalt strike beacon meterpreter software
- #Cobalt strike beacon meterpreter code
įigure 5: Config file extracted from embedded Cobalt Strike beacon.
#Cobalt strike beacon meterpreter full
A full analysis of a Cobalt Strike configuration is outside the scope of this article and there are already great resources in the Cyber Security community on the topic, but the following article provides a starting point for those wanting to go deeper into extracting and understanding IOCs from this artifact ( ). The config extracted from the above-analyzed sample is a simple configuration as shown below in Figure 5, with a single IP as a C2Server and minimal use of additional Cobalt Strike features.
The configuration of the beacon can be extracted from the decoded beacon executable using the fantastic Cobalt Strike config parser ( ).
On execution, the Cobalt Strike beacon will reach out to its C2 server per its embedded configuration.
#Cobalt strike beacon meterpreter code
The section of code responsible for this decode, reflective loading, and execution is shown below in Figure 4.įigure 4: This code snippet shows how each byte of the ‘buff’ array is XORed against a byte in the ‘key_code’ array in a loop then loaded into memory and executed. This task decodes the ‘buff’ variable to a memory stream which is then reflectively loaded into the hosting MSBuild process, then executed. Note that the ‘buff’ variable takes up the majority of the file contents and has been truncated in the figure.Īs the proj file is ‘built’ the ‘ClassExample’ task is executed. Code snippets of these variables from the proj file can be observed in Figure 3 below.įigure 3: ‘buff’ and ‘key_code’ byte arrays storing encoded Cobalt Strike beacon and decode key respectively. The Cobalt Strike payload is stored in a variable called ‘buff’ and is byte-wise XORed with a 5-8 byte key stored in variable called ‘key_code’. The observed tasks were written in C# and contain code to decode, reflectively load and then execute a Cobalt Strike beacon payload. In the case of the samples analyzed by the FortiGuard Responder team the Task was the largest section of the project file. The task section defines the task to be executed alongside the build process.
These two sections can be observed in Figure 2 below.įigure 2: Target Name and TaskName variables common between samples. The TaskName is the name of a particular task and is references in the Target definition, in the case of all samples analyzed by the FortiGuard Responder team this had a value of ‘ClassExample’. The target name defines the target for the build, in the case of all samples analyzed by the FortiGuard Responder team this had a value of ‘Debug’.
#Cobalt strike beacon meterpreter software
Whilst overt, this technique would at first glance be indistinguishable from standard activity, especially in environments where software development tools are standard.Ī project file has several key components of note in this sample Target Name, TaskName and the Task itself.
The sample observed by the FortiGuard Responder team was delivered through an RDP connection then executed directly through GUI access to the ‘Developer Command Prompt’. This functionality has been used in the case of the analyzed sample, for proxy execution of a Cobalt Strike beacon. Functionality within the MSBuild process called ‘Tasks’ allows for the execution of arbitrary code alongside the build process to provide flexibility for end users, likely to support the integration of MSBuild in automated build processes. The sample above (and the one analyzed in this article) is a project file, which is an XML schema designed to be used to control the creation of an executable. Similar samples, to be analyzed later in the article, are more than 6 months old and still have less than 3/57 vendor detection rate.įigure 1: Sample has a very low detection rate through AV vendors. The C2 infrastructure associated with this activity has also been linked to log4j exploitation earlier in the month although this TTP itself has not been linked with log4j. This article will demonstrate how FortiEDR protects against the use of this proxy execution technique and will analyze a sample observed in the wild that is readily available to validate the protections offered by FortiEDR.Īt the time of detection, several samples that employed this proxy execution technique continue to have a very low detection rate on Virus Total with only 6/57 vendors detecting it as malicious and only one correctly identifying the Cobalt Strike implant. This technique was also observed and reported by Renato Marinho from Morphus Labs. The FortiGuard Responder team has observed attempts to employ a proxy execution technique that uses the Microsoft MSBuild to deploy Cobalt Strike beacons throughout customer environments.
0 kommentar(er)
