Jump to content

0th3us

Members
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

0 Neutral

About 0th3us

  • Rank
    Newbie
  1. 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.
  2. 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: The user opened up the Trojan-laden email The user opened the Trojan-attachment The js script was not yet part of the MS Security Essentials signatures The js script ran and downloaded several TeslaCrypt variants A combination of Immunet and MS Security Essentials stopped several of these variants, but one made it through That variant was eventually added to the Security Essentials signatures and quarantined, after it was too late
  3. 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.
×
×
  • Create New...