C2 (Command and Control) is a Server-Client communication method, mostly referred to as malicious communication between a trojan, malware or any other malicious program to the “mothership”. The C2 server usually has 100s if not thousands of clients connected to it, and each client (compromised device) can act differently and behave in a certain way.

C2 is a generic term. The malware samples I’ve come across have used various methods to establish the connection to the command and control servers. Some of the interesting ones include: - Reading metadata inside a Tweet picture to get the next action - Analyse comments on Britney’s photo on Instagram and decrypt the message - Login to Gmail/Outlook and use the email’s builtin features - Pure HTTP connection to an IP/hostname

First off, let’s have a brief overview of what SolarWinds Orion is and what’s it good for. Orion’s main purpose is to give a single pane of glass to look at your IT infrastructure. Various technologies can pump their metrics into Orion Database using Orion poller as a proxy. Orion Pollers will sit in your network, consume the metrics they need, and push it to the database engine. From the design perspective, it’s a robust, effective, and scalable way of having the data always ready. Oh btw, SolarWinds has nearly 18,000 customers worldwide.

The first foothold of the Malware was delivered via IP Address (IOC) 209.141.61.11. When the user navigates to that server, depending on the User-Agent string of the request, you’ll either get a signed, legitimate, non-malicious PDF document (Artifact #1 ZIP, 1d2d5b2befe5fcfea8e9303d87b92adaaf9f161a82e0e1341008518d1585e81a, VT 0/60) or a page with a simple CAPTCHA (Artifact #2 PCAP, dfed73960bd9aa030cc5d84df18eaf2d295dfa7f990614c53673e74b84034ef5, VT N/A) that ultimately leads to a ZIP file (Artifact #3 PCAP, 38dcef9b23f21a98fe9dde3f5b5eb643292bf41556b7e4d5da30484848c4cf3d, VT N/A and Artifact #4 ZIP, db647308649e2d3815f7d53d024ac50e8dead8a3caf33bc203dac90b5dbb1596, VT 15/61).

Let’s start from the basics. We’re all familiar with Multi-Factor Authentication (MFA) and we’re (hopefully) using it everywhere: Twitter, Gmail, Slack, etc. On the other hand, we don’t usually use it for our infrastructure access. RDP, SSH, Telnet are among those services that are not easy to secure on the open internet, so we usually tuck them away under a bastion host or a “gateway” of sorts that can provide this MFA functionality. Unfortunately, those services are quite expensive and according to Shodan, we have ~23 MILLION SSH servers exposed to the open internet. Those services might not be any of my concern now, but when (not if) they’re compromised, they’re gonna form a zombie army for a botnet and then it becomes everyone’s problem.

Say you have a 30GB PCAP full of DNS data, and you want to analyse unusual activity on it. To make things simple, let’s see how long it’ll take to find a list of IPs that have accessed PSN’s domain (prppsn.com) and the timestamp associated with them.

As a member of a Security Incident Response Team, I’ve seen that the normal security practices like deploying firewalls, IDS sensors, NSM Toolkit and Netflow Monitoring. SIRT is increasingly looking to the network as a data source. For years infosec has been network-address-centric and the attackers have adapted. Today it is very common to see malware command and control (C&C) use domain generation algorithms (DGAs), Peer-to-Peer (P2P), or even fast-flux DNS to evade IP address-based detection and blocking. It’s very clear that monitoring DNS activity inside the network and trying to find anomalies associated with it is an essential part of SIRT toolkit.