Analysis of a Multi-stage Squiblydoo variant The first foothold of the Malware was delivered via IP Address (IOC) 220.127.116.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).
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.
The problem statement 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. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 $ perf stat capinfos bigdnssample.
Why Monitor DNS traffic 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.
Almost every Internet-connected device on the planet comes with a nice web interface to interact with. And some of them like routers and APs come with their own little firewall to prevent backdoors and whatnot. So what if one of these devices or even servers gets compromised? Where do you look at to find IoC (indication of compromise) in them? I don’t think I need to explain why IoT is a huge security challenge for every organization since everyone at least has a “smart” printer lying around somewhere.
On April 23rd 2018, Mikrotik fixed a vulnerability “that allowed gaining access to an unsecured router”. myself and @yalpanian of @BASUCERT (part of IR CERT) reverse engineering lab tried to figure out what exactly got fixed, what was the problem in the first place and how severe was the impact of it. UPDATE: full PoC is now available on Github. UPDATE: CVE-2018-14847 has been assigned to this vulnerability and there should be a MetaSploit module related to this bug soon.