Slashdot Mirror
Java Web Attack Installs Malware In RAM
snydeq writes "A hard-to-detect piece of malware that doesn't create any files on the affected systems was dropped onto the computers of visitors to popular news sites in Russia in a drive-by download attack, according to Kaspersky Lab. 'What's interesting about this particular attack is the type of malware that was installed in cases of successful exploitation: one that only lives in the computer's memory. ... It's ideal to stop the infection in its early stages, because once this type of "fileless" malware gets loaded into memory and attaches itself to a trusted process, it's much harder to detect by antivirus programs.'"
"This type of malware is rare, because it dies when the system is rebooted and the memory is cleared.
However, this wasn't a problem for the cybercriminals behind this particular attack, because of the very high probability that most victims would revisit the infected news websites, Golovanov said."
From the linked article.
It doesn't have to. It contacts the C&C server where someone presumably decides whether to install further bots or more resident exploits.
The exploit seems to be more about stealth distribution and about dropping other malware. This makes sense because if a dropper is detected as malicious, it becomes useless due to its detection. (You can safely assume anything using a dropper is malicious)
This means that anti virus software should in theory only be able to detect the actual dropped malware. Any new malware could have had a field day with this exploit because both the dropper and malware would not have been detected.
From my understanding of the article it actually dropped the Lurk trojan but I get the feeling it could drop anything the C&C wants it to.
Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,
After reading a bit on the referenced exploit((CVE-2011-3544) I find it hard to believe that the app was all in memory. The exploit involves and unsigned applet gaining higher privileges. Things may have changed since the last time I checked, but shouldn't the jar file for the applet that copied the DLL into memory be the new file sitting the the browser cache that you're looking for? The DLL could retroactively delete the trace but at some point the jar is what the anti-virus should be looking for since it has to be loaded before the DLL can be.
Oh, if only that weren't true.
My wife does enterprise storage, used to do backups ... occasionally a server gets out of whack, and has all sorts of problems. Eventually she or someone on her team ends up saying "can we just reboot it?". This is usually after several days of troubleshooting and huge amounts of time spent.
It fixes a vast amount of issue in which nobody can identify what's going wrong. Though, it makes any proper form of root-cause impossible to track down. I've heard this referred to as "The Microsoft Patch".
I also know some old-school UNIX admins and mainframe guys who cringe at the notion that a reboot can be a viable way of troubleshooting/making the problem go away. Because they don't reboot unless God himself has filled out all of the right paperwork, and only then if he's got a really good reason and there are no alternatives.
Lost at C:>. Found at C.
In Soviet Russia, Java runs YOU!
Let's call it what it is, Anti-Social Media.
AV software can scan memory in order to find active malware, yes, but it cannot do so constantly. For example, in order to make sure that your browser isn't getting owned, or that malware isn't otherwise being attached to an active process, it would have to scan every change to memory, which would be prohibitive in terms of processing overhead. Instead, they generally scan whenever files are written to the hard drive. Since any permanent virus needs to do that at some point (and most malware works by downloading a file then executing that), that will usually catch and stop most malware at the very beginning. And since writing is comparatively slow (next to RAM), the overhead is minimal.
What this seems to do is run exclusively in RAM, which can be caught by AV doing a RAM sweep, but not by most resident AV systems which don't do regular RAM sweeps (again, because of the performance impact that would cause). It will either have to download a permanent program to the harddrive later (ideally, after getting "trusted" status to bypass AV software) or simply steal info while resident. Either way, most AV software will have trouble detecting it. I think if the malware gets written to swap, the AV will detect it than, but I could be wrong.
"None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
As the article points out this is a known vulnerability. And there has been a patch available since October 2011.
http://www.oracle.com/technetwork/topics/security/javacpuoct2011-443431.html
The infoworld article mentions that the applet used a "rogue" DLL. Where did that come from? If it didn't install any files on the system, why is there a "rogue" DLL on the system? Did it just "install" that DLL into memory also? And if the malicious applet code managed to get escalated privileges, why didn't it install something on the drive? And isn’t the term “install” being misused in the article? In fact, isn’t it true Mr. Infoworld Article person, that the alleged malware was merely “loaded” into memory? The truth is there was no flight leaving Guantanamo Bay, you doctored the flight logs, you ordered the code red, you framed OJ Simpson
FAQs are evil.