I published an article on the IBM Security Intelligence blog : How Attackers Exploit the Remote Desktop Protocol.

This article covers the Remote Desktop Protocol (RDP) and how attackers attempt to exploit it. I provide a short introduction on what is RDP and who uses it and highlight some of its vulnerabilities, such as BlueKeep and DejaBlue. The article also includes a number of countermeasures that you can use to protect your RDP servers and which monitoring and forensic artifacts that are useful in case of incident response for RDP.

Read more at https://securityintelligence.com/articles/exploiting-remote-desktop-protocol/.

Unified Audit Log

The Unified Audit Log contains crucial elements when you want to investigate an incident in O365. You can do this live (with PowerShell, for example via Hawk). Sometimes however you receive the log file offline, with no live access to the environment.

I could not find a tool that gives me a quick overview of what was in the log. So I decided to write my own simple Python script to parse the exported O365 Unified Audit Log.

The exported Unified Audit Log is in CSV and basically you only need the first field of that CSV file, AuditData. This field is a JSON set of data with all the useful data.

Test data

There is a public data set containing Office 365 Unified Audit Logs for security research and detection. I used this data set to demonstrate/tune the script. The screenshots in this post are made with running the script on that data set.

Script

I was interested in the type of operations taking place, from where they are initiated and which objects they manipulated. And this is exactly what the script outputs. There’s plenty of room for improvement but for now it returns the results I’m interested in.

• Overview of basic elements of the log file
• Type of operations
• Client IPs

You can find the script on Github https://github.com/cudeso/tools/blob/master/O365-python-parse/o365-python-parse.py.

Overview of the log

Client IPs

Type of operations taking place

Update 20230214

Added support for simple output to CSV via https://github.com/cudeso/tools/commit/7e3132c6e727cbfdb732a26532785e7bb3af232e.

I published an article on the IBM Security Intelligence blog : When Is an Attack not an Attack? The Story of Red Team Versus Blue Team. This article is a high level overview of a red team vs blue team engagement. It starts with the reconnaissance of the victim, the red team scenario building, attack delivery and also how the blue team can discover the activities from the read team.

Read more at https://securityintelligence.com/articles/red-team-versus-blue-team-attack/.

Cobalt Strike

Cobalt Strike (S0154) is a commercial penetration testing platform which is used by many red teams and, unfortunately, also by many criminal threat actors. In this post I summarise the findings from a SANS Digital Forensics and Incident Response keynote by Chad Tilbury : Cobalt Strike Threat Hunting. The YouTube video provides much more details but below you can find those findings that were relevant for me during an IR case.

This post includes references to commands of the Volatility memory forensics platform but you can use any platform of your choice. Some of the logs sources that are valuable during IR such as network traffic (detect beaconing, traffic frequency), PowerShell logs and Sysmon logs were unfortunately not available.

Hunting

Process tree

Look at running processes and the process tree via pstree. Two anomalies to look for are:

• PowerShell spawning itself;
• PowerShell spawning (multiple) rundll32.exe processes.

Rundll32.exe is spawned as a sacrificial process in which Cobalt Strike injects its malicious code. By default, Cobalt Strike will spawn rundll32.exe. This is customisable and can as well be svchost.exe or any other process. The take-away is to look for multiple, similar, processes all spawned from PowerShell.

Command line arguments rundll32

The next item to look for are the command line arguments that are used for starting rundll32.exe from PowerShell.

If you notice a rundll32.exe process spawned from PowerShell without any DLL supplied as an argument then there is a high chance that something is wrong. By default Cobalt Strike spawns rundll32.exe without arguments but this is also customisable. If you observe multiple rundll32.exe processes (or for example svchost.exe) spawned with the same command line parameters or all without command line arguments then there’s a high chance it’s Cobalt Strike.

32-bit version PowerShell

Review if a 32-bit version of PowerShell was used to launch the subprocesses. You can detect this by looking at the startup path (via cmdline) of the command. If it includes syswow64 (take note of different forms of capitalisation) then it’s using the 32-bit version.

Execute and Write memory pages

You can find injected code with malfind which allows you to find ‘hidden’ or injected DLLs in user memory. Pay special attention to the memory pages that are marked both as executable and writable. Don’t be confused if the first page only contains zeros. Cobalt Strike can will not inject its code in the first page but you’ll be able to find the injected code after the set of zeros.

Named pipes

The default configuration of Cobalt Strike uses named pipes for the communication between different processes:

• \\.\pipe\MSSE-###-server (default Artifact Kit binaries)
• \\.\pipe\status_## (payload staging for lateral movement)
• \\[target]\pipe\msagent_## (SMB beacon)
• \\.\pipe\postex_ssh_#### (SSH sessions)
• \\.\pipe\postex_#### (post exploitation)
• \\.\pipe\####### (7-10 #s) (post exploitation before version 4.2)

The configuration of these named pipes can be changed, but in a lot of cases attackers will just stick to the default settings.

In Volatility you can list the named pipes via the handles command and specify the process PID. Note that the list of named pipes can provide you hints of other machines most likely also affected by the intrusion (for example if the named pipe has references to machine names/IPs for post exploitation or SMB beacons).

For an initial triage and to reduce the volume of results it makes sense to look only

• at processes which normally would not use named pipes;
• for 32-bit processes (syswow32) using named pipes;
• or for named pipes with a seaming-less random name.

As an additional note, the number of characters of the name of the named pipe is a giveaway for what command is being issued. For example mimikatz (8 chars) will have a named pipe name of 8 characters long. Also see the blog of F-Secure Detecting Cobalt Strike Default Modules via Named Pipe Analysis and a list of malleable profiles (including the different pipe names) from Michael Haag.

A last remark on named pipes. Because Cobalt Strike uses named pipes to deliver shellcode you should make sure your sandbox emulates named pipes as otherwise Cobalt Strike might not find its shellcode. See also the blog from NVISO Anatomy of Cobalt Strike’s DLL Stager.

PowerShell logging

PowerShell logging is essential to further identify Cobalt Strike activity. Because so many attacks make use of PowerShell in one way or another (not only for Cobalt Strike), it is a treasure cave for doing incident response. Unfortunately PowerShell auditing (logging) is not always enabled in corporate environments (as was the case for the IR for which I did this post).

If you do have PowerShell logging enabled, then look for

• DownloadString / IEX downloads for localhost (http://127.0.0.1);
• Large blocks of encoded PowerShell (FromBase64String, EncodedCommand);
• System.Reflection or ReflectedDelegate.

Crowdstrike has an overview of PowerShell log observations of Cobalt Strike commands: Getting the Bacon from the Beacon.

Extract Cobalt Strike configuration

If you have a memory dump of a system running Cobalt Strike then you can use the 1768.py tool from Didier Stevens to decrypt and dump the configuration file of the Cobalt Strike beacon. The tool will scan the memory dump, look for the XOR key and then decrypt and dump the configuration of the beacon. You can dump the configuration in tabular output, CSV or JSON.

Image from https://blog.didierstevens.com/2020/11/07/1768-k/

The dump of the configuration file gives you immediate access to the named pipes, the C2 server (name, port and URI) and the HTTP user agent used for beaconing. All this information is something you can use to further identify compromised devices.

Sigma rules

There are a couple of Sigma rules that you can use to detect Cobalt Strike :

• Suspicious Rundll32 Without Any CommandLine Params Suspicious Rundll32 Without Any CommandLine Params: Detects suspicious start of rundll32.exe without any parameters as found in CobaltStrike beacon activity
• CobaltStrike Named Pipe CobaltStrike Named Pipe: Detects the creation of a named pipe as used by CobaltStrike
• CobaltStrike Service Installations CobaltStrike Service Installations: Detects known malicious service installs that appear in cases in which a Cobalt Strike beacon elevates privileges or lateral movement

Summary

PowerShell spawning itself
PowerShell spawning (multiple) rundll32.exe processes
Multiple rundll32.exe with no command line arguments or all with the same command line arguments
32-bit version of PowerShell started (via syswow64)
Memory set as EXECUTE and WRITE
List of default Cobalt Strike named pipes
PowerShell downloads for http:/127.0.0.1
Encoded PowerShell

Update 20210914

These resources provide additional useful information for detecting and fighting Cobalt Strike:

• Cobalt Strike, a Defender’s Guide: A very extensive guide with information on which Event IDs to look for during the different stages, such as Execution, Defense Evasion, Discovery, Privilege Escalation, …
• Awesome-CobaltStrike-Defence: A Github repository with pointers to hunting and detection tools, Yara and Sigma rules and indicators of compromise.

For a recent assignment, I had to summarise some of the legislation and cooperation frameworks that exist between CSIRTs and law enforcement agencies. This list is certainly not complete but already gives you an overview of what’s available. I first list the frameworks and then provide an overview of some of the existing cooperation mechanisms.

Legal Frameworks

Council of Europe Convention on Cybercrime  (Budapest, ETS No 185)

2001 – International

This convention, also known as the Budapest Convention is the first international treaty to address Internet and computer crime. The treaty focused on harmonising laws and increasing cooperation across borders so that cybercrime could be prosecuted in the countries affected. The treaty had three main objectives

• harmonising national laws that dealt with cyber-related crime;
• supporting the investigation of cyber-related crimes;
• increase the international cooperation in the fight against cybercrime.

Full text can be found at coe.int.

Directive on attacks against information systems (2013/40)

2013 – Europe

This directive imposes new obligations, tasks and expectations on certain key stakeholders, including CERTs/CSIRTs, LEAs, security specialists, telecommunications service providers. These relate mainly to the operation of the existing 24/7 contact points (introducing a response deadline obligation within 8 hours), improving criminal justice/police cooperation, and the obligation to strengthen statistical data collection in order to support accountability and rational policy making.

The Directive is well known because it establishes the criminalisation of certain tools for committing offenses

This is a directive, which needs to be transposed into national law in all individual member states of Europe.

Full text can be found at eur-lex.europa.

Directive on processing personal data for prevention, investigation, detection or prosecution of criminal offences (2016/680)

2016 – Europe

This directive regulates the processing of data by police and criminal justice authorities in the EU. The Directive requires the data collected by law enforcement authorities to be processed lawfully and fairly, collected for specified, explicit and legitimate purposes. The data can also only be kept in a form that allows identification of the individual for no longer than is necessary. The Directive requires that the law enforcement authorities make a clear distinction between the data of different categories of persons.

This is a directive, which needs to be transposed into national law in all individual member states of Europe.

Full text can be found at eur-lex.europa.

General Data Protection Regulation – GDPR (2016/679)

2016 – Europe

The GDPR is the privacy data law that is designed to harmonise and update data protection requirements in the European Union. The primary objectives of the GDPR are to give control of personal data to EU citizens and residents. GDPR also simplifies the regulatory environment for international business within the EU.

Contrary to a directive, a regulation does not need to be transposed into national law, it immediately applies.

Full text can be found at eur-lex.europa.

Directive on Security of Network and Information Systems – NIS (2016/1148)

2016 – Europe

The EU’s NIS Directive (Directive on security of network and information systems) is the first piece of EU-wide cyber security legislation. It aims to achieve a high common level of network and information system security across the EU’s critical infrastructure. It sets a range of network and information security requirements which apply to operators of essential services and digital service providers (DSPs).

This is a directive, which needs to be transposed into national law in all individual member states of Europe.

Full text can be found at eur-lex.europa.

EU’s Cybersecurity Strategy for the Digital Decade (JOIN/2020/18)

2020 – Europe

The EU Cybersecurity Strategy focusses on building the operational capacity to prevent, deter and respond to cyber incidents. One of the major focal points to increase the operational capacity is to establish a Joint Cyber Unit (JCU) to speed up information sharing between different cybersecurity communities in the EU. It also focusses on increased cooperation and strengthening collective capabilities to respond to major cyberattacks.

Full text can be found at eur-lex.europa.

Cooperation Mechanisms

CSIRTs Network (CNW)

The CSIRTs Network is a network composed of EU Member States’ appointed CSIRTs and CERT-EU. The European Commission participates in the network as an observer. ENISA is tasked to actively support the CSIRTs cooperation, provide the secretariat and active support for incident coordination upon request. The CSIRTs Network provides a forum where members can cooperate, exchange information and build trust. Members will be able to improve the handling of cross-border incidents and even discuss how to respond in a coordinated manner to specific incidents.

European Union Cybercrime Task Force (EUCTF)

The EUCTF is a trust based network which meets twice yearly at Europol and provides a forum for the heads of the EU cybercrime units and associated countries (Denmark, Iceland, Norway and Switzerland), together with EUROPOL, CEPOL, EUROJUST and DG HOME to identify, discuss and prioritise the key challenges and actions in the fight against cybercrime. The mission statement of EUCTF is to develop and promote a harmonised approach within the European Union to the criminal misuse of information and communication technology and the fight against cybercrime.

Joint Cybercrime Action Taskforce (J-CAT)

The Joint Cybercrime Action Taskforce (J-CAT), launched in September 2014 helps fighting cybercrime within and outside the EU. J-CAT’s objective is to drive intelligence-led, coordinated action against key cybercrime threats and targets by facilitating the joint identification, prioritisation, preparation, initiation and execution of cross-border investigations and operations by its partners. It consists of 9 EU Member States, 7 non-EU partner countries and Europol.

European Judicial Cybercrime Network (EJCN)

The European Judicial Cybercrime Network (EJCN) was established in 2016 to foster contacts between practitioners specialised in countering the challenges posed by cybercrime, cyber-enabled crime and investigations in cyberspace, and to increase the efficiency of investigations and prosecutions. Eurojust is a key partner of the EJCN, especially in situations in which the Network deals with the numerous challenges related to the genuinely borderless nature of cybercrime.

24/7 Points of Contact Network

This network was constructed under the Council of Europe Convention on Cybercrime

Joint Cyber Unit

The JCU is part of the new EU Cybersecurity Strategy and has as goal to speed up information sharing between different cybersecurity communities in the EU.