Morpheus: "What can you see, Neo?"
Neo: "It's strange. The code is somehow different."
Morpheus: "Encrypted?"
Neo: "Maybe."
Trinity: "Is that good for us, or bad for us?"
Neo: "Well, it looks like every floor is wired with explosives."
Trinity: "Bad for us."
Morpheus: "Here we go."
-The Matrix Reloaded
The "conficker cabal" industry consortium is working to lock the domain names used by the worm for command and control. The best probability of success for the bot's creators to retake control may now be DNS poisoning; DNS poisoning attempts may be a potential early warning indicator if the worm's authors attempt to reassert control of the infected population. The latest version – Conficker B++ or C – has also implemented an “autoupdate” capability of sorts, perhaps as an alternative method to reassert control.
Recently a new variant of the worm - Conficker C or B++ - has emerged and is under analysis. The variant uses an additional network communication mechanism – SMB named pipes. Obviously many networks block SMB protocols at their perimeter so this would not be a reliable command and control channel – but it could be used as an “autoupdate” feature. Many organizations do not internally compartment or filter unicast SMB protocol – in such a network, one instance of Conficker could potentially update the entire version C population at wire speed. This technique will almost certainly be imitated in future generations of industrially produced malware. It would probably be a sensible precaution to re-examine worm containment and network compartmentalization capabilities, particularly for VPN users and laptop populations who may be at greater risk of experiencing DNS cache poisoning or malware infection vectors in general. A single infected laptop with an updated instance of a bot with this kind of “autoupdate” capabilities could potentially update an entire population of infected machines with a binary payload in an un-compartmented and/or unfiltered network.
Looking at what we know about the worm there are number of detection strategies. While the worm's propagation may be relatively simple to detect with a well-tuned threat detection tool, detection of HTTP based covert communication channels tends to be more difficult and error prone, particularly with static signatures. HTTP sessions are supernumerary in many networks - and these control channels can be quite subtle and hard to distinguish from normal web traffic (the best place to hide a tree is in a forest).
It's worth noting that scanning for the MS08-67 vuln is not a useful tactic as Conficker will often patch this vuln after it infects a host. Also worth noting that attempts to control the bot by providing it with a binary program to run will most likely fail; the authors thought of this and Conficker will reject any binary image not signed using the bot herder's keys.
Antivirus detects – by now the major vendors will all have reliable signatures. Antivirus tools are actively jammed and attacked by the worm, however, and may experience false negatives in cases where the worm is able to cripple them.
Authentication Logs – in many environments the worm will produce a spike in auth failure and account lockout events. Easily detectable using a SIEM or log aggregation tool.
IDS events – the worm uses exploits for MS08-67, which by now all IDS tools should be detecting. IDS tools may also generically detect shellcode used by the worm.
Proxy logs - The first two variants connect to one of these URIs. (n is an incremental number). An exact URI match would require computing the Conficker domain list and creating a very large ruleset; a generic match on the URI parameters may or may not be useful in terms of false positives depending on overlap with legitimate web applications in a given environment.
http://domainname/search?q=n\&aq=7 (Conficker A)
http://domainname/search?q=n (Conficker B)
Flow / session data – lots of potential here.
Behavioral detection of worm propagation – the worm and its newest variant use SMB sessions, easily detectable by an NBAD tool
Geolocation – variants of the worm will connect to www.getmyip.com, getmyip.co.uk, checkup.dyndns.org and maxmind.com – observable using flow data (obviously these have legitimate users as well, so potential false positives exist)
Connectivity tests – the worm may make HTTP connection requests at 60 second intervals when communication fails or is blocked; this is observable using flow data and obviously programmatic.
Protocol Anomalies - the worm may make HTTP connections on nonstandard ports.
Geometric detection (using the QRadar tool) – geometric detection works by detecting deviations from normal application shape or geometry. When monitoring network session data over time, one of the things you find is that normal usage of many applications has a predictable shape – and that significant departure from normal geometry often indicates suspicious use or misuse of a protocol.
DNS activity – every three hours, the worm will generate up to 500 DNS requests. This activity will be obviously programmatic and could likely be detected statistically by a behavioral sentry or with a simple threshold based rule.
HTTP control channels - HTTP traffic produced by the worm may also have abnormal geometry; it may be too small, to frequent or too predictable to be human activity. It may also be statistically detectable using a behavioral sentry.
Multivariate Correlation (using a SIEM tool) – often best results come from corroborating multiple detects. Try using a function rule in a SIEM tool like QRadar to create a high priority alert when multiple detects are obtained within a time window.
No comments:
Post a Comment