SOC Team Essentials | How to Investigate and Track the 8220 Gang Cloud Threat

8220 Gang is a low-skill crimeware actor known for infecting cloud hosts through n-day vulnerabilities and remote access brute forcing. We have previously detailed how 8220 expanded its botnet and rotated its infrastructure. Since our last write up in October, the group has again switched to new infrastructure and samples, providing us with an opportunity to share an educational walkthrough of the process of investigating cybercrime activity that may be useful to new or lesser experienced SOC teams, analysts and researchers.

In this post, we use 8220 Gang activity as a lens through which to explain the process of investigating a threat, researching the threat activity as a whole, and gaining a perspective into attacker objectives, ultimately concluding with a wider understanding of related threat intelligence.

Refresher on 8220 Gang

8220 Gang (pronounced eighty-two twenty), also known as 8220 Mining Group, was first publicly reported by Talos in 2018. Victims of 8220 Gang are typically, but not exclusively, users of cloud networks operating vulnerable and misconfigured Linux applications and services.

Attacks make use of SSH brute forcing post-infection to automate local and global spreading attempts. Victims using cloud infrastructure (AWS, Azure, GCP, Aliyun, QCloud) are often infected via publicly accessible hosts running Docker, Confluence, Apache WebLogic, and Redis. Victims are not targeted geographically but simply identified by their internet accessibility.

Initial Discovery

Our walkthrough starts with the initial discovery of an interesting script found on a compromised AWS machine with publicly available SSH service secured with weak credentials. For readers not running a honeypot, this initial discovery could have also been observed in the monitoring of new files uploaded to file scanning services like VirusTotal or MalShare. For those looking to monitor this group, international SSH honeypots plus VirusTotal YARA rules offer a reliable method of catching new activity as it occurs.

The script in question has the SHA1 a9da0947243333d95f84f6a0e37b9fc29b2fb054.

We can see it is quite simple in design and built around the process of downloading and setting persistence of some other file.

With a few string pivots inside VT, or even a few Google searches, we can quickly discover the core functionality of the script has been widely reported on as it has been reused by many amateur cryptocurrency mining groups and opportunistic profit-seeking attackers.

One example of such reporting is our July 2022 post on 8220 Gang expanding their botnet to roughly 30,000 hosts. However, this time the attacker-specific infrastructure is different, and we have not determined if it has delivered similar malware. Remember, this “infection script” is used by many attackers, and it alone is a very weak source of attribution.

8220 Infection Script Analysis

The script goes through a set of instructions, often at multiple levels of encoded commands, aimed at the delivery of setting persistence on the victim machine by downloading itself from malicious servers. The multiple levels of Base64 encoding attempt to hide the fact that it is also downloading a specific payload as well. This is first observed under the createservices function.

One difference that’s quickly apparent to past reporting on the script is that the attacker began adding the lwp-download command as a failover for wget and curl to enable downloading commands. We initially observed this activity on January 6th, and since then the actor has continued to standardize it in their infection scripts today. Sysdig also noted this activity in a recent blog.

The key take away from analyzing these infection scripts is noting unique additions, like lwp–download, combined with the destination of download requests. By clustering infection scripts based on function names and order, if the functions are called, and what infrastructure is associated, we can weed out the non-8220 Gang samples.

Additionally, we can link this further based on the encoding quantity and repetition to past 8220 Gang samples. For example, in our infection scripts createservices makes use of three base64 encoded echo commands. The first command can be decoded into a new script which pings associated attacker infrastructure and then starts a “payload” command.

The payload contains two additional base64 encoded scripts to set permissions, download, and configure miner and IRC bot infections. This functionality communicates with 194.38.23[.]170.

Post-Infection Activity & Sample Pivots

The post infection activity for this and other recent 8220 infection scripts evolve slightly, but generally proceed with infecting the victim with an updated PwnRig cryptocurrency miner and IRC bot.

In the infection scripts we observed in this campaign, the group continued to use old bash IRC bot “Tsunami”. The sample delivered remains unchanged; however, the network it communicates with evolves over campaigns. The infection script here delivered 472548a4b8295182f6ba8641d74725c2250b7243 – the Tsunami sample.

More useful for tracking 8220 Gang are the samples of PwnRig – the custom version of the open source XMRig cryptocurrency miner – that they drop. In this campaign, the script downloads the UPX packed sample 38be55f1fc4ce1cb5438236abc5077019e5e1cdf, which unpacks to 332485bd460f55117a254f8164736b90d74aa9f6. A characteristic of 8220 Gang is their repeated use of fake miner pool domains themed around the FBI. Here, we see this theme again through the use of the malicious domain fbi.su1001-2[.]top.

Infrastructure Analysis

Tracking 8220 Gang is aided somewhat by their failures in infrastructure OPSEC. Since the beginning of what the industry calls “8220 Gang” the primary method of attribution has been reused infrastructure and identification of newly associated infrastructure. While this technique alone does not link the actor with certainty, it remains reliable when combined with the previously noted linkability around malware samples delivered.

During our initial investigation in January, the group was using 185.106.94[.]146, and dw.bpdeliver[.]ru for malware download location post-infection such as in their infection script. Anyone looking into this group should pivot on all subdomains associated with the actor-controlled domain, in addition to all DNS history of malicious IPs to identify a wider set of the malicious activity.

For example, the recent dw.bpdeliver[.]ru host resolved to 79.137.203[.]156 during the initial deployment of the script. More activity of 8220 Gang scripts can be found calling directly to this IP rather than the domain. The same goes for 185.106.94[.]146, which is called by IP in the script, and which at the time resolved to jira.letmaker.top, a widely reported known 8220 Gang domain.

Overall, the group is clumsy and unsophisticated in their infrastructure management, providing a good opportunity for those willing to track the mess or cut their teeth in threat actor investigation.

Our graphic from a previous campaign explains the overlap, which can still be found in this most recent activity.

Conclusion

Tracking and researching 8220 Gang, which has exhibited a lack of operational security, requires a simple understanding of their use of malicious scripts, malware samples, and malicious infrastructure. A successful approach to tracking this group can involve monitoring and analyzing malware samples, identifying patterns in their malicious scripts, and mapping out their infrastructure.

Indicators of Compromise