Jump to content

Wha2do

Members
  • Posts

    6
  • Joined

  • Last visited

Reputation

0 Neutral
  1. In the last day, a full scan detected one trojan: C:\Program Files (x86)\Windows Live\Photo Gallery\WLXPhotoGalleryRepair.exe (Trojan.Inject). I made a screen print of the results from the scan and attached it (for what it's worth). I've attached the DDS.txt and Attach.txt files - in order to run as administrator I opened up a command prompt run as administrator and ran DDS.com from my desktop. After detecting it, I first ignored it and sent the file to VirusTotal which showed 0/43 detecting anything (see attached). I ran the scan again in /developer mode thinking it might be a false positive and have attached the logfile generated. Afterwards I quarantined it, but thought I'd restore it to see if was detected by other scans and in case needed for further investigation. After highlighting and clicking restore several times it finally "disappeared" from the quarantine, but now it's nowhere to be found. It appears to have been deleted instead of restored as it was visible before quarantining... I ran a full MBAM scan after the quarantine & attempted restore and all came up clean. I did try several other scans after but got the BSOD for IRQL_NOT_LESS_OR_EQUAL but chalk that up to trying to do too much at one time. Everything appears to be up and running fine since, but want to make sure I truly am clean, know if it was picked up somehow, or was an fp. Thanks in advance! Also meant to say I'd googled the executable and it appears this is a legitimate file, but unfortunately now can't compare it with known versions...oh and noticed I hadn't posted the VirusTotal scan (for what it's worth, lol). Again thanks in advance for your assistance! dds.txt attach.txt 10-17-12 MBAM detection.rtf mbam-log-2012-10-17 (07-05-50).txt Virus Total scan.rtf
  2. Thanks for all the followup and clarifications! Excellent observation and question. Through time, I have used several routes including sandboxing, working in VM, etc. You're right about the dedicated box being the safest way to go - no danger of external contamination, making a mistake and making a mistake. In doing future testing, I'll retool one of my systems as a dedicated box as you've recommended to be 100% safe. While feeling that I'm working safely with all precautions, I do have one more step to make it completely mistake proof w/o any undesirable side effects. Again thanks for all the assistance and keep up the excellent work!
  3. Thanks on both replies w/clarifications! Just to make sure I understand what occurs during mapping to memory. Scenario two below would seem to be the logical one but just want be sure and understand 100%. If scenario one was the case, uploading to Virustotal could result in releasing the payload prior to finding out it's infected - and thus it wouldn't be recommended for someone to upload something for Virustotal scanning. Scenario 1) When an executable (or other file) is infected and is "mapped to memory" due to uploading to Virustotal, this action can cause execution/loading of its payload and infect the system? Scenario 2) Uploading to Virustotal is mapping the file to memory (as a whole) and during this process it sees the mapping is to a potentially infected file. MBAM doesn't know that this mapping is not a request to execute it (which would obviously result in releasing the payload/infection) and provides a preemptive warning. And in this case, it's safe to proceed since the executable is not being executed? Sorry if being a tad slow or dense on this!
  4. Just to be clear - I know the file is questionable/infected - I have it in my library of files for testing various security packages... I know the executable is detected by some of the engines on VirusTotal (mostly heuristic it seems and by the "smaller" engines such as Cat-Quickheal, Comodo, Esafe, Ikarus, etc - not Avira, Kaspersky, AVG, Symantec, etc). And yes, uploading the restored version shows it to be clean by all but SAS so quarantining it must clean it up. Oddly enough SAS didn't detect it on the first upload when it was a fresh "live infected" executable, only after it was restored from quarantine (as a Rogue.Agent/Gen-Nullo[EXE]). In resending the "live" copy of the executable to Virustotal, I was able to duplicate the "...a malicious process has been blocked from executing." message I've received before. The question at hand is I'm uploading a file for scanning - so why is MBAM stating a process is starting? The process/executable is not being started...unless I'm unaware of some method of it running triggered during an upload to Virustotal. In which case, those folks trying to upload a file to make sure it's clean would be infected before they even get the Virustotal results (assuming they weren't using MBAM or a similar product). So again question 1 - why is MBAM showing a process is attempting to run when all I'm doing is uploading to Virustotal? And question 2 - what is the ignore option - ignore the warning and let the process run? I really want to block a potentially malicious process, but don't want to quarantine the file immediately. Thanks in advance for answers on these two questions!
  5. Thanks for the reply and very impressed w/MBAM. I figured it could be tough to answer. The ip blocking appears to be fine, but curious about when MBAM notices a malware program/process is trying to run. I was surprised to see the pop up asking what action to take on this executable when I hadn't physically asked to run it (double click, right click - open or run, etc). It was justing sitting in my "library" and MBAM pointed to this file as trying to start up a process (the gist was "A malicious process has attempted to run and has been blocked...with the three options of (forget the first), ignore, and quarantine"). I figured quarantining and restoring modifies the file so wouldn't be live (which was the case in doing a manual scan). I had placed a new copy back in the folder and manually scanning with MBAM detects it's still infected with Trojan.Agent.CK. Yet I can't duplicate MBAM dectection of it attempting to start a process since that one time. The main question is if I'm not physically requesting it to run, how did it appear to be starting a process? Does MBAM put up that warning only when it truly is trying to run a process? Mostly concerned that there's something other method for this standalone executable to be triggered when just sitting on the system - ie. being touched by Windows Explorer, scanned by another program, etc? I can understand one component firing up another executable, but this is a single file without other files/executables. And this wasn't the warning from a regular MBAM scan... Just trying to understand if having these files sitting idle can do anything when "touched" by other system actions (directory accessed by Windows Explorer, malware scans, etc). Also, can this message be triggered even though a process isn't truly being started but an infected file is detected? Lastly, what does ignore do - ignore the warning and let the process start or block it but doesn't quarantine? Thanks so much! Sorry for this being long!
  6. This may be difficult to answer but figured worth a shot at asking... MBAM just warned me that an executable residing on another partition attempted to run (a malicious process has been blocked....). It's one I had in my malware library for testing various freeware security packages and it wasn't being executed. I was running a scan w/AntiVir Personal - Free on the overall directory at the time and to be safe, I quarantined it. For curiosity, I placed another copy of this executable in the directory to see if being touched during the scan caused the detection but it didn't occur again. Scanning the new one with Malwarebytes does label it as being a trojan.agent.ck so the it still is "live". And I don't have anything in my ignore list... Bottom line, how can an infected executable sitting as a standalone file start up a process that would be detected by MBAM? My system is clean so it's not being triggered by another malware process... Any ideas?
Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.