Analysis of a Caddy Wiper Sample Introduction CaddyWiper was first reported by ESET as below: Dubbed CaddyWiper by ESET analysts, the malware was first detected at 11.38 a.m. local time (9.38 a.m. UTC) on Monday. The wiper, which destroys user data and partition information from attached drives, was spotted on several dozen systems in a limited number of organizations. It is detected by ESET products as Win32/KillDisk.NCX. One of my friends pinged me a few days later with a link to a CaddyWiper sample.
Overview As a cyber defender and a DFIR analyst, network packet captures are one of my best friends. I know that’s probably one of the most depressing things you’ve ever heard, but that doesn’t make it less true (͠≖ ͜ʖ͠≖) Packets don’t lie if they’re stored properly, and they paint a good picture of what happened if there’s enough metadata surrounding it. If you have proper packet processing, you’ve got a powerful asset in your IR and 0-day detection toolkit.
What is C2 and why DNS as a transport method 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.
SolarWinds Orion 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.
Analysis of a Multi-stage Squiblydoo variant The first foothold of the Malware was delivered via IP Address (IOC) 184.108.40.206. 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).
What is SSH MFA 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.