Jump to content

jeremyf

Members
  • Posts

    7
  • Joined

  • Last visited

About jeremyf

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    Canada
  1. For anyone interested, please see my previous edited post for a few details.
  2. *Edited. I am just going to mention here as well, here is the log of the initial infection. Again, although these threats were discovered/caught, infection was still successful on this machine. Date Received 2014-06-02 08:44:37 Date Occurred 2014-06-02 08:40:50 Level Warning Scanner HTTP filter Object file Name hxxp://gerring-serilg.su/net-phocaguestbook/jquery Threat a variant of Win32/Injector.BEYR trojan Action connection terminated - quarantined User [domain]\Pauline Information Threat was detected upon access to web by the application: C:\Users\Pauline\AppData\Local\Temp\KB480233852.exe. And immediately afterwards: Date Received 2014-06-02 08:44:37 Date Occurred 2014-06-02 08:40:51 Level Warning Scanner Real-time file system protection Object file Name C:\Users\Pauline\AppData\Local\Temp\480239983.bat Threat BAT/Small.NAN trojan Action cleaned by deleting - quarantined User Information Event occurred during an attempt to access the file by the application: C:\Users\Pauline\AppData\Local\Temp\KB480231699.exe. It was within a few minutes of the above that "DECRYPTION_INSTRUCTIONS" files began to be written on network shares...the local machine was taken over at this point... Date Received 2014-06-02 08:52:31 Date Occurred 2014-06-02 08:44:09 Level Warning Scanner Real-time file system protection Object file Name D:\Last.Report\DECRYPT_INSTRUCTION.HTML Threat Win32/Filecoder.CR trojan Action deleted User [domain]\Pauline Information Event occurred on a newly created file.
  3. That's quite a hairy story you have there! And it sounds quite similiar to what we experienced, but you are much bigger...and I am sorry to hear you had actual data loss as a result... Yes, I really hope law enforcement gets serious with this type of thing (as much as it can), but I fear it will have little effect. This will likely become the de facto standard for the most dangerous "virus" scripts/programs out there, since what else do you want as a malware writer, other than A) destruction and maybe a little B) profit? I predict this might stimulate changes at the OS level in time as a response...we will see! I am thankful that Eset really seemed to stop it as it tried to spread to other systems...it really seems to have only let it go on the one system (and shared network folders as a result), and I think because it is an as-of-yet unidentified strain.
  4. That was my opinion as well, after having read up on it a bit. Which is why I was quite happy once I DC'ed the affected system that everything seemed to stop in terms of files being generated on the network folders (and actual active harmful encryption taking place), etc. One other aspect however, was that I had one off-site software developer connected to another workstation via RDP during the same period of time as the infection took place. I was actually on the phone with him with very strange behaviour: repeatedly getting "lagged out" of his connection. Not disconnecting mind you, just so much lag his remote system became unresponsive from his perspective. A user disconnect on his part, and reconnect, would solve it momentarily, but it would quickly do it over and over. That all stopped when I went to deal with the infection and finally DC'ed the affected workstation, although he was only able to inform me of that quite a bit later in the day. Again to be clear, neither his laptop at home, or the local system here he was remoting to was affected in any way I can tell from this infection, except for that strange behaviour that was too much of a coincidence to be ignored. I have read some stuff about some malware taking advantage of open RDP ports in a local LAN, and I wonder if that was some method of propogation...though to be honest it seems a bit far-fetched. I'm trying not to get too excited, but for you to even suggest my calling you is amazing on your part! Even though I am fairly confident that I have stopped this thing dead in its tracks (and therefore not in a panic or anything), a brief look by a professional such as yourself would be more than welcome! I will take you up on giving you folks a call first thing tomorrow. i also now realize I spelled "Crypto" wrong in the title of my OP...would a moderator please correct that for proper search functionality?
  5. I have Endpoint on all domain connected workstations, including the one that was infected. I have File Security for MS Servers on the single server we have, which hosts the shared network folders. I am currently nuking a couple of virtual Win XP, and a single Win 7 machine (all within Virtualbox) - which are hosted on the server as well. These system are not part of the domain, but serve other purposes. They did NOT have Endpoint on them, which I will rectify after I restore older images of those machines pre-infection. I expected the thing to begin actively encrypting shared network folders...what I did not expect was it to seemingly propogate through some unkown means to other workstations? These system do not have shared network folders...and yet no less than 4 Eset detections and deletions according to RAC logs on other otherwise unaffected workstations in their respective local User/Appdata folders...I found this strange...by what means does it propogate in that way?
  6. Addendum: To my dismay, now that I am reviewing the Threat log on the RAC, I see at least 4 other systems that detected the same "Win32/Filecoder.CR trojan" as .TMP files in the associated workstations users' 'Appdata/local/temp' directories. As far as I can tell from this log, Eset Endpoint DID detect these as threats and deleted them. The timestamps on these detections and deletions coincide to just before I originally disconnected the offending infected workstation. So somehow it was attempting to propogate through the internal LAN network as well. I was not aware of this behaviour from these types of ransomware infections...anybody else? My fear now is I can only hope that Eset did in fact eliminate this threat as it was attempting to propogate (it sure looks like it did!). I am also puzzled by why Eset did NOT detect it on the offending, fully infected original workstation. (Although it did begin throwing detection notifications on the DECRYPTION_INSTRUCTION files). I have slightly different versions of the Endpoint client on these machines, ranging from 5.0.2126 - 5.0.2225. But the version on the offending machine, and one of the ones that detected and reported deleted in the Appdata directory was the same version, .2126. Again, any advice or commentary is welcome.
  7. Hi there, On Monday, our business was hit with "something". I expect the manner of infection was via IE (latest version, fully patched) on a Windows 7 x64 workstation (also fully updated and patched). The user was looking at "recipes" and I believe it was through an undocumented exploit of IE (a drive-by download), since she knew enough to call me over once UAC starting prompting her for changes (to which she always hit NO), and she wasn't trying to download anything, just viewing the web site. Before I knew what I was doing with, I installed Malwarebytes free version on the PC (fighting the UAC prompt hitting NO every 5 seconds or so)...but then before it had even run for 5 minutes I noticed "DECRYPTION_INSTRUCTIONS.txt" being created in the Documents folder of the PC, and Eset Endpoint started flagging "DECRYPTION_INSTRUCTIONS.html" files being created alongside the .txt versions in every folder the malware was actively encrypting (and yes, it was quite successful at fully encrypting that workstation) as "Filecoder.CR Trojan". At that point I disabled the ethernet card on that system. The warnings from RAS later emailed to me, as a result of Eset Endpoints flagging them just before I disabled the ethernet card, looked like: Obviously, it had started to work on Shared Network folders before I disconnected it. It was quite successful in the "export" and "last.report" directories, not so much in the "Common files", "Drivers and software" and "Programdata" directories. For this I am thankful. Action I have taken: - completely wiped (formatted and re-installed), and then restored from previous backups the entire affected workstation (it never came back on the network until this was complete) - completely wiped and deleted those shared network folders on the Server that were affected, and restored from previous backup (disclaimer: if the "DECRYPTION_INSTRUCTIONS" files had been written to the directory, I tested randomly files within it. Like I say above, for the two folders where I could verify everything was encrypted, I deleted and restored. For those folders that I could find NO EVIDENCE of encryption having taken place, I simply deleted the "DECRYPTION_INSTRUCTIONS" files. I sincerely believe I caught the malware in time for those folders. My question to the knowlegable folks here is: what else do you recommend? Without providing source files (sorry I wiped the affected machine too quickly), I suppose I am not helping the cause by providing the malware for future immediate detection by Eset. I can tell you that it created a folder directly on teh affected machines C: drive called "ebc0c52" in which a file resided called "ebc0c52.exe". This file was also present in a number of Windows system folders, and set to run at startup throught the registry. That is as much investigation that I did before I wiped the system. Does it make sense that Eset seemed to not detect the actual malware, but only the files it generated? I would appreciate any input any of you have on this. Thanks.
×
×
  • Create New...