Iranian APT seen exploiting GitHub repository as C2 mechanism

An Iranian advanced persistent threat (APT) group associated with the operation tracked as Cobalt Mirage has turned to GitHub as a means to operate its latest custom malware, known as Drokbk, using a repository hosted by the open source hub as a so-called dead drop resolver to relay command and control (C2) instructions.

According to new intelligence gathered by the Secureworks Counter Threat Unit (CTU), Cluster B – which is likely sponsored by Tehran’s Islamic Revolutionary Guard Corps (IGRC) – has taken to packaging up C2 server location instructions and storing them in a GitHub repository to be collected by the Drokbk malware for later use.

The technique mirrors a traditional element of spycraft known as the dead letter drop, in which agents in the field pass documents, money and other items using a secret location, without making contact with each other.

Although reminiscent of the fiction of Ian Fleming or John Le Carré, the dead drop lives on in the 21st century as a form of short-range communication – in 2012 the UK was forced to admit using a fake plastic rock to conceal surveillance equipment targeting Russia, which embassy staff would periodically walk by and download information from. A similar concept underlies the SecureDrop open source project, which connects whistleblowers with investigative journalists.

Reporting on his findings at Black Hat Europe, Rafe Pilling, Secureworks principal researcher and thematic lead for Iran-focused research, said that using GitHub allowed Cluster B to evade detection more easily by helping the Drokbk malware blend in.

“All the traffic to GitHub is encrypted, meaning defensive technologies can’t see what is being passed back and forth,” he said. “And because Github is a legitimate service, it raises fewer questions.”

The Secureworks CTU team says Cluster B’s use of Drokbk seems to date back to February 2022, when its own incident responders encountered it while conducting first response following a cyber attack at a local government body in the US. This attack was found to have started with the compromise of a VMware Horizon server via the Log4j/Log4Shell vulnerability – a favoured modus operandi of Cobalt Mirage and one it is still successfully exploiting to this day.

“To date, Drokbk has kept a low profile and hasn’t been documented in open source, so this is the first really in-depth look at how it works under the hood,” said Pilling.

“Drokbk provides the threat actors with arbitrary remote access and an additional foothold alongside tunnelling tools like Fast Reverse Proxy [FRP] and Ngrok. Our advice to organisations is to use available controls to review and restrict access to the IP addresses, domains and URLs associated with Drokbk – which we have listed in our blog.”

The Drokbk malware itself is coded in .NET and comprises a dropper and a payload. On its own, it has limited on-board functionality and mainly serves to execute additional commands or code from Cluster B’s C2 infrastructure, hence the use of a reliable mechanism of communication such as GitHub, which seems to be integral to its inner workings.

Pilling and the CTU have been on Cobalt Mirage’s trail for some time, but until recently had been working on the understanding that it was a single entity, but they are now relatively certain that it operates two distinct clusters – Cluster A being the ransomware-centric operation.

Cluster B, on the other hand, seems to be somewhat harder to track and favours more custom tools – Cluster A favours BitLocker, a legitimate full volume encryption feature that can be turned to malicious purposes, such as ransomware. It is probably more focused on information-gathering rather than extortion.

Pilling said Cluster B conducted “broad scan-and-exploit” activity against IP address ranges in Israel and the US, but also operated on something of an opportunistic basis, hitting targets in a wide range of sectors, from educational institutions to financial services organisations.