Probably there’s something more in the Next Step Of Botnets besides BlackHole 2.0 and Tor C&C mentioned in my previous post. I mentioned the takedown of the Nitol Botnet by Microsoft as one of the most important infosec events of the last week, but I forgot to mention one important aspect related to this event: the malware supply chain.
As a matter of fact, in case of Nitol, Microsoft discovered a real botnet factory, that is a compromised supply chain, based in China, that allowed new computers (to be sold to unaware consumers) to come pre-installed with malware embedded with counterfeit version of Microsft OS.
A step forward in the Cyber Crime industry with the advantage for cyber crooks to setup an “army” of zombie machines without enforcing time consuming drive-by attacks or spam campaigns. I used the term army since the main features of Nitol are the capability to execute on-demand DDoS attacks (besides to offer a backdoor to cyber criminals for taking control of the infected machines).
Unfortunately, what’s especially disturbing according to Microsoft, is that the counterfeit software embedded with malware could have infiltrated the chain at any point.
If you still have doubts that Cyber Crime has become a real industry there’s no better example to demonstrate it. Moreover I cannot help but think that, once upon a time, new computers came out with antivirus software embedded, today they are sold directly with malware.
- The Next Step of Botnets (hackmageddon.com)
So Google has acquired Virus Total, the Spanish company which provides the well-known cloud-based free service that analyzes suspicious files and URLs to detect malware, by comparing the results of 42 different antivirus engines and 30 URL scanning services. The news has been given today with a blog post.
Google’s move does not come so unexpected if you consider that Anti-Malware services are moving towards the cloud which is the only way to provide the resources and the holistic perspective needed to analyze the growing number of malware samples (and variants), a task which requires a huge amount of computational resources and a real-time intelligence. To have an idea of the resources needed, try to have a look at the Virus Total Statistics.
On the other hand, the Spanish company has admitted in the blog post that the Virus Total service will undoubtedly benefit from Google’s horsepowers:
- The quality and power of our malware research tools will keep improving, most likely faster; and
- Google’s infrastructure will ensure that our tools are always ready, right when you need them.
Continuing to operate independently, and to maintain the existing partnerships with other antivirus companies and security experts.
And Google? Even if detractors claim that the company will exert a strict control on malware data, the target of the acquisition is a quantum leap in web security, with the possibility to include Virus Total Security Services and Technologies inside the rich service portfolio of Mountain View. Think for instance to real time scanning (with 30 engines) of the URLs in search engine results.
Time will tell who is right, in the meantime keep on submitting malware samples!
Yesterday Bloomberg reported the news of a new cyber attack in Middle East targeting an Oil Company. The latest victim is Ras Laffan Liquefied Natural Gas Co., a Qatari LNG producer that has shut down part of its computer systems targeted by an unidentified malware since Aug. 27.
According to the scant official information available, desktop computers in company offices were the only affected, while operational systems at onshore and offshore installations were immune, with no impact on production or cargoes.
Of course it is impossible to avoid a parallelism with the cyber attack targeting Saudi Aramco a couple of weeks ago, and the 30,000 workstations that the company admitted to have been targeted (and restored only few days ago) by this malware outbreak. It is also impossible not to mention the infamous Shamoon, the brand new malware discovered in Middle East that information security community immediately connected to the Saudi Aramco cyber incident, furthermore stating (by literally quoting Symantec’s blog):
W32.Disttrack is a new threat that is being used in specific targeted attacks against at least one organization in the energy sector.
The Ras Raffan cyber attack maybe provides a partial answer to the question regarding who else might have been affected by Shamoon (I wonder if we will soon learn of other companies targeted) and even if security researchers have not confirmed, so far, the connection between Shamoon and this latest attack, the first speculations on regard have already appeared. According to the WSJ, the RasGas information technology department identified the virus as Shamoon, stating that:
Following the virus attack, some “computers are completely dead”.
The Middle East is considered the Cradle of Civilization, but I am afraid that, in this 21st century, it is becoming the “Cradle of Cyber War”. And even if you consider Shamoon just an amateurish copycat (with no cyberwar intentions), you cannot ignore that the latest research according to which even Wiper is a son of the so-called Tilded Platform (the same malware platform that originated Stuxnet, Duqu and Flame).
This cannot be considered a mere coincidence.
So, it looks like that the destructive impacts of the cyber attack targeting Aramco, where definitively true. In the same hours in which the first details about the malware were disclosed, Kasperky Lab, McAfee and Symantec have dedicated respectively three blog posts to describe what appears to be the latest example of a large scale cyber attack targeting Middle East (apparently focused on companies belonging to Energy Sector).
Shamoon (or W32/DistTrack), this is the name of the malware, has some points in common (the name of a module) with the infamous Flame, but according to Kaspersky this is the only similarity:
It is more likely that this is a copycat, the work of a script kiddies inspired by the story.
The malware has the same features seen in other “companions” among which the driver signed by a legitimate company “Eidos Corporation”.
According to Symantec, the malware consists of several components:
- Dropper: the main component and source of the original infection. It drops a number of other modules.
- Wiper: this module is responsible for the destructive functionality of the threat.
- Reporter: this module is responsible for reporting infection information back to the attacker.
According to McAfee, machines infected by the malware are made useless as most of the files, the MBR and the partition tables are overwritten with garbage data. The overwritten data is lost and is not recoverable, so this should confirm the destructive details received yesterday.
While, according to Seculert, the malware is a two-stage attack:
Stage 1: The attacker takes control of an internal machine connected directly to the internet, and uses that as a proxy to the external Command & Control server. Through the proxy, the attacker can infect the other internal machines, probably not connected directly to the internet.
Stage 2: Once the intended action on the internal infected machines is complete, the attacker executes the Shamoon malware, wiping all evidence of other malicious software or stolen data from those machines (or also the MBR and the partition table as McAfee Suggested). It then reported back to the external Command & Control Server through the proxy.
So far it is not clear who is behind the attack, although Kaspersky Lab suggests that the term Shamoon:
could be a reference to the Shamoon College of Engineering http://www.sce.ac.il/eng/. Or, it could simply be the name of one of the malware authors. Shamoon is the equivalent of Simon in Arabic.
More details are expected in the next hours.
While the U.S. and Israel keep on mutually claiming the Stuxnet’s paternity, Kaspersky Lab has unveiled further details about Flame that allow to connect it with the infamous malware targeting Iranian Nuclear Plants.
Are the two 21st century Cyber Weapons really correlated? Due to some architectural differences, the first data seemed to exclude any similarities between the two platforms: the so-called Tilded platform which Stuxnet and Duqu are based on, and the brand new platform from which Flame has been developed. In any case never trust appearances, as a small detail dating back to 2012 has unveiled a landscape that seems completely different from what was previously believed, which suggests the hypothesis that the Stuxnet malware had a kind of “proto flame” inside.
The Cyber Spy Story begins in October 2010 when the automated systems by Kaspersky Lab detected a False (Stuxnet) Positive. This sample apparently looked like a new variant (Worm.Win32.Stuxnet.s) but a deeper analysis showed (then) no apparent correlation with Stuxnet so it was subsequently dubbed Tocy.a.
Only two years later, in 2012, after the discovery of Flame, the russian security firm started to compare the brand new malware with previously detected samples to find any similarities. And guess what? The nearly forgotten Tocy.a was nearly identical to Flame. A further check to logs, allowed to discover that the Tocy.a, apparently an early module of Flame, was actually similar to “resource 207” from Stuxnet, and this similarity was the reason why the automatic system had previously classified it as Stuxnet.
Resource 207 is a 520,192 bytes Stuxnet encrypted DLL file that contains another PE file inside (351,768 bytes). It was found in the 2009 version of Stuxnet, despite it was dropped in the 2010 evolution, with its code merged into other modules. The PE file is actually a Flame Plugin, while the purpose of Resource 207 on the 2009 variant of Stuxnet was just to allow the malware propagation to removable USB drives via autorun.inf, as well as to exploit a then-unknown vulnerability (MS09-025) to escalate privileges in the system during the infection from USB drive.
Given the evidences collected, researchers suggests that, although Flame has been discovered a couple of years after Stuxnet, it was already in existence when Stuxnet was created (Jan-Jun 2009), having already a modular structure. The “Resource 207″ module was removed from Stuxnet in 2010 due to the addition of a new method of propagation (vulnerability MS10-046), while the Flame module in Stuxnet exploited a vulnerability which was unknown then, allowing an escalation of privileges, presumably exploiting MS09-025.
Part of the Flame code was used in Stuxnet despite, after 2009, the evolution of the Flame platform continued independently from Stuxnet.
Probably, this is the second important discovery about Flame after the MD5 Collision Attack, which enabled to malware to hide the download of its own modules behind Windows Updates.
Regarding the MD5 Collision Attack, I suggest you to have a look at this very interesting presentation. You will be amazed in discovering that the first successful demonstration of this attack took, in 2008 (the alleged year in which Flame was created), about 2 days on a cluster of 200 PS3s (corresponding to about $20k on Amazon EC2). Together with the complexity of the attack, this aspect is enough to suggest a state-sponsored origin for the malware (i.e. the need of huge resources and know-how). But there’s more: to make the MD5 Collision Attack successful in Flame, the Attackers, had to overcome a huge obstacle corresponding to prediction the Serial Number of the Certificate (which is based on a sequential certificate number and the current time). Nothing strange apparently, except for the fact that they had a 1-millisecond window to get the certificate issued. What does this mean in simple words? A large number of attempts required to get the certificate issued at the right moment, an effort 10-100x more costly that the original MD5 Collision Attack Demonstration.
Now I understand why the Iran Cyber Warfare Budget is estimated to be “only” USD 100 Million…
- Back to Stuxnet: the missing link (securelist.com)
- Researchers Connect Flame to U.S.-Israel Stuxnet Attack (wired.com)
- Discovery of new “zero-day” exploit links developers of Stuxnet, Flame (arstechnica.com)
The fact that ISPs are evaluating an Anti Botnet Conduct Code means their are feeling responsible for what resides inside (and leaves) their networks, and hence are supposed to take technical, organizational and educational countermeasures.
Anyway, in order to be effective, anti-bot controls should be enforced inside the customers’ networks, or at least before any source NAT is performed, otherwise IP addresses of the infected machines would be hidden, making impossible to detect and block them directly. A huge task for an ISP unless one were able to centralize the security enforcement point where the traffic is monitored and compromised endpoints members of a bot detected.
Said in few words I believe that ISPs will soon offer advanced anti-malware (read anti-bot) services in the cloud by routing (or better switching) the customer’s traffic on their data centers where it is checked and the customers notifyed in real time about the presence of bots inside their networks. You may think to the same approach used for URL filtering services on the cloud with the difference that in this scenario the clients should arrive to the ISP’s Data Center with their original IP Address or a statically NATed address so that it could always be possible to recognize the original source. Another difference is also that in this scenario the purpose in not only to protect the customers’ networks from the external world but also (and maybe most of all) to protect the external world from the customers’ (dirty) networks.
Another contribution of the cloud against Botnets that I forgot to mention in the original post.
- I, BOT (Coming To A C&C Server Near You) (hackmageddon.com)