Immunet 3 Failed To Detect Tesla ... Until Too Late

[0th3us]

This isn't a knock on Immunet, but to get resolution on a puzzle.

 

I'm supporting a friend's work PC. Yesterday they noticed a problem, and today I determined it was the TeslaCrypt 3.0 "ransomware", as noted on securelist.com (files with .macro extension, and I found the registry key to confirm it). Not only did it encrypt data on network drives that were mapped to drive letters, but it also found a computer on the network with an unmapped letter (which was open, sharing the C: drive. Yeah, I could have prevented that.). I'm not yet 100% sure, but it appears to have deleted the volume shadow copies from before that start point even though it ran under the permissions of an ordinary user. Did it manage to elevate privileges for itself? Further, it appears to have completely gotten by both Immunet (3.1.13.9671) and Microsoft Security Essentials (Win7), but see below.

 

For every file TeslaCrypt encrypted, it left its mark in the Immunet registry as an "installed file". Thus I know exactly when the virus started adding files to the system: Jan 26 17:19:54 (GMT, presumably, as local time stamp of said files is off by X hours). To be sure I missed nothing, I used an SQLite Browser to examine the raw history file. (Actually, this was necessary, due to Immunet's interface being unable to handle so many files in its log).  A couple of things of interest here:

 

• The source (creating the files) was this time named "suavghe45.exe"
• That image (suavghe45.exe) does not show up in the Immunet logs until the next day
• There are no entries on Jan 26 prior to 17:19:54, but entries exist days and weeks before.
• When suavghe45.exe is flagged and quarantined by Immunet, it is identified as "W32.Trojan.19c0.1201"
• Microsoft Security Essentials was simultaneously running and at 16:42 GMT, identified as "Tescrypt.B" coming from c:\Program Files\Immunet\clamav\temp\clamtmp\<blah>.tmp\nocomment.html
• and then "Tescrypt.D" from
  c:\Program Files\Immunet\clamav\temp\clamtmp\<blah>.tmp\notags.html
• At the same time suavghe45 is generating these files, Immunet is noting (but doing nothing) the creation of *.dat files in Microsoft Antimalware\Scans\MetaStore\1\*\*.dat via MsMpEng.exe (Microsoft Security Client). 
• Using nirsoft's BrowsingHistoryView tool, I saw no visits to anything suspicious. I see nothing wrong with the following sites, but I am not willing to vouche for the last 4. Perhaps someone here sees a red flag? All these were visited using Chrome.
  • ​​​google search
  • youtube.com
  • google translate
  • wetter.de
  • translit.net
  • wetter-im.com
  • reise-klima.de 
• Even after performing a "Flash scan", while I was working on the computer this evening, doing nothing else, Immunet and MsSE detected new threats. Immunet detected C:\windows\temp\TMP0000<long-hex-string> as "W32.GenericKD.19c1.1201" while MsSE detected Tescrypt.D in %AppData%\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\<hexstring>\93[1]

This all leads to the following questions for the community and the devs:

 

• Why doesn't the creation of suavghe45.exe ever show up in Immunet's logs? Could Immunet have been temporarily disabled? Does Immunet clean out these logs after a few days? If so, is there a backup (there's a "historyex.db" but my SQLite browser tool cannot read it)
• Is it possible Immunet first quarantined the bad files, which then triggered MSE to quarantine them in turn? If so, why didn't these events show up in the history log?
• Is it possible that these files were executed but quarantined after execution started? 
• Aside from Browsers, what could the attack vector be?

 

I completed a full scan and found 1 threat, inside a folder in Windows-temp from 2014. 

[0th3us]

I believe I found the infection vector. I also think I know how privileges got escalated. 

 

The PC is used by a business for processing, among other things, invoices. The day before the infection occurred, an email was received. Two hours after the infection occurred, this email was forwarded to another person within the company. This email had a double From entry, one real, one bogus, and it claimed it was for an unpaid invoice. The attachment was a zipped JS script. When I re-unpacked this zip file, Microsoft Security Essentials identified the file as the TeslaCrypt installer. Immunet was told to scan the zip file, with archive-scanning enabled; it identified neither the zip file nor the js file as a problem. 

 

I will try to confirm with users in the morning, but it appears the following occurred:

1. The user opened up the Trojan-laden email
2. The user opened the Trojan-attachment
3. The js script was not yet part of the MS Security Essentials signatures
4. The js script ran and downloaded several TeslaCrypt variants
5. A combination of Immunet and MS Security Essentials stopped several of these variants, but one made it through
6. That variant was eventually added to the Security Essentials signatures and quarantined, after it was too late

[ritchie58]

Hi Oth3us, sorry to here about the ransomware infection.

That is one of the most widely used attack vectors, a malicious email attachment or link that a user is duped into clicking on. I would like to point out that Immunet Free does not have email scanning capabilities to begin with (this could be a feature that's included in a future 4.0 build that's due to roll out sometime this year). Also, since this is such an extremely new variant of the TeslaCrypt malware I can see why Immunet did not immediately detect it after the infection occurred. No AV in the world is infallible 100% of the time.

Unfortunately, in my opinion, attacks using JavaScript is just in it's infancy and will be a problem for the foreseeable future as malware authors, using this relatively new attack vector, try to stay one step ahead of the good guys. They are now using the NW.js framework that allows criminal minded developers to quickly create and deploy new Windows applications or variants using HTML5, CSS3, JavaScript, and WebGL. Linux or Mac machine users, don't fool yourselves and think you are invulnerable to this type of infection either. "All of these Operating System platforms are vulnerable to this type of attack!" 

Here's a posting on the subject you may find relevant. http://support.immunet.com/index.php?/topic/2981-ransom32-the-first-javascript-ransomware/ 

Regards, Ritchie...

[0th3us]

Thanks for your response, Ritchie.

 

There are some points from my post that are not addressed, but first to rebut some of the things you wrote:

 

"attacks using JavaScript is just in it's infancy".  You have no idea what you're talking about. JS files when launched from the user's own PC can cause quite a bit of damage. You're confusing a new attack type that works inside NW.js, where the entire trojan is written in js. The new NW.js based attack is no different than a virus based on Java, Adobe Air, MS Silverlight, etc.  But here I'm talking about JS being used as part of the vector which downloads and launches the real payload.  

"[immunet] does not have email scanning capabilities to begin " I understand that, but when an application (the mail handler) unpacks an attachment, it stores that attachment in temporary folder. Immunet normally scans and sees those files and in many cases handles them. When it scans them, it logs them in its SQLlite-based history database. I examined this database and for some reasons, these entries do not appear! In my first message of this thread, I noted that the log entries begin appearing at 17:19:45.  It appears that Immunet deletes its own logs periodically or that something else did!

 

Second, Immunet successfully quarantined the trojan the next day. Were we a victim of bad timing here? That the signature was simply unknown until the day after? Is there anyway to check this?

 

A new additional point for the devs: Immunet's exclusion list does not include Microsoft Security Essentials! Seems to me that should be a default. We found that Immunet and MSE kept fighting over quarantined files.

[ritchie58]

It seems I didn't word that quite correctly to your liking. Perhaps I should have said that attacks using JavaScript is on the "rise" especially with the new NW.js attacks occurring. Sorry for the misunderstanding there.

 

You are correct about the log files. Immunet will delete the history files after a certain amount of time to keep the logs from getting too big and using up excessive HDD space.
 

It's very possible that you were the first person to encounter this Malware variant with Immunet. Perhaps that's why it took a little time for a quarantine response to take place. The file(s) were downloaded, analyzed and then added to the detection database.

 

I think that would be a good idea to add MSE's Program Files folder into Immunet's Exclusion list by default as well.

We do recommend that any security app's Program Files folder you use with Immunet, that's not in the default exclusion list, be added to avoid conflicts. There's lots of postings on the forum about this particular subject.

I was hoping that an Administrator would join this conversation and perhaps shed some additional light on the situation. I do try my best to help people out on this forum whenever possible but I'm only one person and I'd be the first to admit I don't have all the answers.

Regards, Ritchie...