OPSEC or Operational Security, is a concept and doctrine borrowed from the military that is used to protect the assets, plans, and movements counter to that of our adversaries. It’s amazing what can be pieced together with a few bits of information.

Within the last 24-48 hours a fervor of activity was kicked off across both vendor and organizational security teams due to the likelihood of a large-scale supply-chain attack underway. The first public details of the attack were shared by the folks at CrowdStrike and within the blog post: CrowdStrike Prevents 3CXDesktopApp Intrusion Campaign.

So, what’s the big deal?

TL;DR the 3CX desktop application utilized by millions of users appears to be compromised and is being used by possible nation state threat actors. Further details on how, why, and what they are doing with the compromised applications are still being researched.

Update (3/30/23) Huntress Labs released a blog with technical and behavioral insights on the threat actor’s capability and use of 3CXDesktopApp.exe: 3CX VoIP Software Compromise & Supply Chain Threats.

3CX is an international Voice Over IP (VoIP) Private Branch Exchange (PBX). Simply put, they route a great deal of voice communications and are one if not the largest operator of this type with over 12 million users across 600+ thousand companies!

Circling back, if you look into additional blogs posted on this threat (as of 3/29/23), you’ll note that there isn’t a great deal of insights into the attack vectors, commands, and actions-on-objectives publicly shared. This likely alludes to how the industry was caught off guard by the attack and further highlights how hard it is to detect evil within trusted and signed applications.

Isn’t this post about OPSEC?

Yes, it is, and it relates to the above referenced incident. Currently, one of the earliest and highest quality atomic indicators shared were that of observed Command and Control (C2) domains. These domains were seen in communication with compromised/malicious installations of the 3CXDesktopapp.exe.

So, what do you think happens when you share a list of malicious domains associated with a suspected supply-chain attack which are reviewed by 100s of thousands of businesses using 3CX software? If you said ping and tracert/traceroute commands, then you’d be correct! Post compromise review of this attack showed many customers attempting to reach out via those network troubleshooting tools essentially flagging themselves to the adversary network.

The Do’s and Don’ts

What we have here is a clear case of signaling, or the act of transmitting awareness of an operation to an adversary. While we certainly wouldn’t want to do this during a confirmed incident in an organization - we definitely don’t want to provide further awareness to the adversary of organizations that might be vulnerable to their capabilities. Particularly because this threat is not fully understood and there are no public mentions (that I’ve seen) that discusses how organizations are targeted and compromised.

Be careful out there!

1. If you really need to, utilize an air-gapped network prior to reaching out to malicious infrastructure.

2. Utilize a virtual machine (VM) that does not look, behave, or have shared configuration or settings to that of your production network environment.

3. Make use of a VPN to obfuscate your location ensuring you do not associate your production network with this research and investigation.

4. If you’re testing firewall rules and need to ping the domain, try to virtualize or move your firewall or network control to the air-gapped network for testing prior to relying on it in production.

Detection Opportunities

Expect a lot to change with associated detection content publicly shared as our understanding of the threat unfolds.

SigmaHQ/sigma Rules: 3CX Rules (3/29/23)

As discussed above, the only consideration beyond the lack of insight into the threat is that these rules will generate false positives for benign apps making connections to the domains such as ping or traceroute. That should be manageable as we would not expect widespread benign connections to these domains.

Some considerations for triage and analysis:

• Verify what application is making these outbound connections.

• Do you have detections associated with publicly shared binary hashes? Are they also associated with detected network comms?

• Be aware of legitimate use of ping and other command utilities making connections to these shared domains. Is this an admin or just an interested user?

• If available, keep an eye on detected process lineage and their relationships to 3CX software to determine the likelihood of risk tied to associated detections and events.