SEP let W32.Spybot.AVEN in?
Weird....... it was found and accounted for in 2008. The latest defs, shoot, even defs from last week should have alerted on it.
Instead a defs update at 3am today found it in the user profile, application data area, as an EXE file.
It said it quarantined it, but the file was still there and unmovable. So the alert that it was found and quarantined was WRONG.
(SEP should state that it wasn't able to quarantine, unless it did and it reappeared??)
I'm working on it now, but a full SEP scan with updates are not able to remove it. It keeps alerting with every restart that it was found and either "details pending" or "quarantined" and yet it's still there.
If this was known in 2008, like the Symantec write-up states, why did it get in, infect, then at 3am when no one was here and no one was even using the computer did the alerts come through that it was a new infection, or rather, a newly FOUND infection?
Is it:
A. A VARIANT of the old W32.Spybot.AVEN
B. SEP simply missed it, but for some reason suddenly found it?
C. Did it appear in the middle of the night, were the Halloween ghosts using the poor fellow's computer in the night?
Since SEP won't remove it, I'm going in manually to see what I can do - otherwise, looks like SSS's TR!
Just curious - because now I have to explain to management........ oh, making this much worse if the fact that this is the CFO's COMPUTER! And he sits right next to the AGENCY ADMINISTRATOR! (and will be in meetings with these folks all day today, lucky for me)
Just wondering if anyone has seen this beast recently, and I'm hoping I can explain this as a new variant, even though the Symantec write-up isn't really clear on this...........
Comments
It's probably a new variant
It sounds like Spybot is being "installed" (either by downloading from the internet or being extracted from local files) by something that isn't detected on the machine. I'd recommend contacting support so we can work with you to try to identify the suspicious file(s) or process(es) and get them submitted to Security Response for detection.
I believe the file was most likely quarantined and came back, rather than not going away at all. I also believe that it's not a new variant of Spybot, but I could be mistaken.
As far as the write-up is concerned, it's accurate. We first detected the virus in 2008, but virus writers are creating new variants all the time. If a new variant isn't different enough to warrant a whole new name (or new extension), we'll often just update the "main" definition. However, we don't update the write-up unless needed...so, it's possible to get the impression that an "old" virus has shown up when, in fact, it was just recently modified by a virus writer.
Well, I guess I couldhave
Well, I guess I couldhave stated that better - not that it's not accurate, but SEP names the name as W32.Spybot.AVEN and the write up for it doesn't apply to this case as the files aren't there and the registry entries aren't there.......
So it's that SEP have given this a name that doesn't work with the writeup for a beast of the same name.
The poor article writer was probably 100% accurate at that time..........
I also am of the thought that it was removed and came back....... I'll look and see if SEP got it to the quarantine server.
I know Matt - he ONLY goes to "good sites", never playe around or does non-work related stuff on his computer. He's a straight arrow at work - so this could mean a site somewhere has been comprimised........
AND this is a new beast that looks a lot like the other, so SEP id's it as such.
TR just said the machine is clean.
I can't find any traces of weird files or registry entries when logged in as ME.
Malwarebytes has flagged a registry entry, but until it's done, I can't tell what it is.
Just starting the computer, SEP said it was there again - but I can't see it........... so it's a stealth beast so far.........
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
Thanks for the clarification
Okay, I understand now.
One issue with our write-ups...well, more of an issue with the threats themselves...is that it's not always possible to update them to contain all the latest information.
Spybot is an *excellent* example of this. Spybot writes file names and registry keys that are completely random but legitimate-looking...that is, it's always going to write to HKLM\Software\Microsoft\Windows\CurrentVersion\Run, but *what* it writes here could fill a small book. When I say legitimate-looking, I mean seeing things like lsass.exe, svchost.exe and the like...just loading from incorrect locations. Since the variables that virus writers can pull from is limitless...at some point we, as a company, go "okay, we can't possibly list all the different names we've seen for filenames for this threat". As such, the writeups should be followed, but if files don't match (but we're alerting on them), the writeup should be a guideline.
If, for example, the writeup says that lssass.exe (note the extra S there) is loaded from HKLM\Software\...\Run and I don't see it, but I DO see cssrs.exe (should be csrss.exe) loading in Run, and that's the file we're alerting on, that's the entry I'll go after. It's not perfect, sure, but short of publishing every possible file and registry permutation, it's what we've got.
As far as where it came from, it's quite possible that it could have been a "drive by" infection, or an infection of a legitimate website itself. I've personally seen very simple webpages for a local city celebration get hit with a java injection which, in turn, tries to pull malware down. The site itself is perfectly innocent, it just comes down to the admin(s) in charge of the server hadn't patched IIS and, as such, java injections happened on most (if not all) sites hosted. The old axiom of "avoid the seedier places on the internet", while still helpful, sadly, isn't as true anymore. However, in your specific case, it's just speculation on my part.
I see your submission in our backend, and some files are already identified as "new threat", which typically means we're already in the process of building rapid release definitions, and three files are flagged for hand-detection by an engineer, so hopefully soon we'll have full defs created to detect and remove this.
In the meantime, you might want to open a case with Support (if you haven't already) and request the load point diagnostic utility to help ferret out any suspicious or unexpected loading points. Many of the times I've found new threats on customer machines has been after running load point and finding files that didn't seem quite right, or were quite obviously incorrect.
Chris I just broke my rule
Chris I just broke my rule and SUBMITTED the file. SEP did get it to the Q-server two times.
See, that quarantine server IS handy since we now won't allow this notebook a network connection, that's the one and only way I could possibly submit.
PLEASE talk to them about keeping q-server and updating it!
Anyway...........
[TRACKING]: Symantec Security Response Automation: Tracking #13324046
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
MALWAREBYTES says TROJAN.ZBOT
MALWAREBYTES says TROJAN.ZBOT and found 3 XXX.QSP files in c:\windows\temp folder.
SEP did not trigger on those..........
We'll see what the submission brings.
MB didn't flag anything in the registry, which is odd since SOMETHING was loading this beast!
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
Must be taking a long time to
Must be taking a long time to analyze as I sent in a second file and got a response on it in like 10 minutes.
This one was submitted a couple of hourse ago.
What does it mean that the file was deferred for manual analysis in the q-server screen??
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
Deferred
Deferred means that the files were sent to Symantec, our server has gone "hey, we need to look at this" (or "hey, we've got this MD5 hash somewhere else already") and it's queued up to be looked at by an engineer.
Unfortunately, there's no way to track this (that I'm aware of), which is why we request that people submit via the online submission page...it gives us a tracking number that we can track, whereas things submitted automatically from the Quarantine server, to the best of my knowledge, cannot.
Thanks - that's helpful to
Thanks - that's helpful to know.
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
So whats the answer. I show
So whats the answer. I show its more than 18 weeks ago and still no answer. The Symantec server can grab all it once but the problem still exist. Also a small finding maybe, Qsp seems to be create when a corruption occurs to the symnantec av files. Recently we found the confictor and after it was removed we started getting the qsp in the temp directory. Seems to coincide with realtime. We did remove enpoint and reinstalled clean and at this time no qsp files are appearing
I think you might be on to something. We noticed that these random .qsp files were being created from Symantec's quarantine folder in all users/applications data/symantec...../quarantine. We deleted everything in the quarantine folder and the .qsp files stopped being created in the %windows%/temp folder. It might be a corruption somewhere that would cause this. We believe it's using rtvscan.exe as it's process to do this.
Chris I did a manual
Chris I did a manual submission via the page anyway - figuring same.
So the tracking number is above in this thread........
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
OOPS, sorry, I didn't scroll
OOPS, sorry, I didn't scroll up and see you replied! Sorry.
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
NEW INFORMATION!!! SEP found
NEW INFORMATION!!!
SEP found the EXACT SAME FILE as before, but this time, it calls it something totally different!
SEP was calling this file W32.Spybot.AVEN but NOW calls it infostealer.Banker????
Here's the NEW alert on the same file on a DIFFERENT computer:
At least one security risk found:
Risk name: Infostealer.Banker.C
File path: C:\Documents and Settings\alc\Application Data\sdra64.exe Event time: 2009-10-23 08:04:48 GMT Database insert time: 2009-10-23 08:08:13 GMT
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
Threat names can change, certainly
NORMALLY you'll see a shift in the extension...so, like, Spybot.gen would later become Spybot.abcd or the like. Usually if the threat "jumps" names...like from Spybot to Infostealer, it's due to either a misclassification in the first place or, upon further review, it looks more like the second threat than the first. I can't speak for what happened specifically in *this* case, as I'm not in Security Response...I'm just going on the experience I've gathered working here in Support.
You need to hire me into
You need to hire me into Symantec.............. (actually, they were going to at one time)
I think for kicks I'll go ahead and submit this and see what they say........ worst that can happen is it comes back as "known threat, fix it yourself".
My curiosity at times overtakes my frustration with the submission processes............ LOL
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
GREAT - it once again said I
GREAT - it once again said I submitted more than 10 files! I submitted the original EXE as found - guys, you need to fix this thing or folks won't be able to submit any worms or trojan horses to you since they are ALL exe files containing numerous other files.
We've been this road before -
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
It might be a "misnamed" file?
Looking at your original submission, the file sdra64.exe is listed as a compressed file. It's possible that this is either a self-extracting zip file that contains more than 9 files (the online submission page has a limit of 10...9 files and the zip container), or simply a .zip file that was renamed by the virus writer to have a .exe name rather than .zip.
If you could, use any of the free MD5 hash generator programs to generate the MD5 hash of the file and PM the MD5 value to me. I'd like to compare it to the earlier submission to see if it's the same thing.
You could also try submitting the file to threatexpert.com (a site we purchased awhile back) and see what it returns as.
I'll be BLUNT - again. I
I'll be BLUNT - again.
I don't care if the worm EXE contains 1,000,000 files. SYMANTEC WANTS US TO SUBMIT suspect files, etc. So I try - and try and try. And since they block anything with over 10 files, that means that they can't even GET most worms any more, since they are nearly all packed with multiple files.
This is NOT my problem, it's symantec's archaic means of taking suspect files.
**It's not up to me to extract these things and analyze them FOR Symantec.**
They want these files, they either take them AS WE SUBMIT them, or I propose NO ONE submit to them in protest.
THIS IS TOTAL CRAP - we are in crisis mode for other rreasons here and I don't have time to spoon feed your antique system.
Take the bloody file or don't, but don't dare ever suggest to me again that I need to submit suspect files as I will not.
I WANT THIS TAKEN TO THE VERY TOP OF SYMANTEC.
Why does Symantec want us, the CUSTOMER, to figure out what is in an EXE that we really shouldn't even be touching to begin with?
This is customer service?
And if you delete or hide this, trust me, there will be issues beyond this......
I'm sick of this submission process, and it ALWAYS happens when we have other problems. If submitting was a casual non-important thing that would be different - but folks submit samples because THEY HAVE A VIRUS and need help and answers.
I don't give a rat's hind end if this thing is compressed 10,000 times and has files that rival the federal debt - you people WANT SUBMISSIONS, we try and this is what we get. ANALYSIS is SYMANYTEC's Job, not mine.
Mine is to SUBMIT THE FILE AS WE GET IT from the web.
A copy of this is going to our sales rep and engineer...............
With our mandatory 10% budget cut here in Iowa, FREE software is looking mighty tempting right about now.............
And I don't have time for a 2 hours phone call to open a case. We are pressed hard to do double the work here as it is, your bloody submission process doesn't make our jobs any easier.
Iowa agencies are in crisis mode, our agency has network outages I need to be dealing with, we've got these worms getting in here, multiple alerts, and I'm supposed to extract worm files and spoon feed them...........
Yeah, right.
Yes I'm mad - this should have taken all of 5 minutes. Submit file, accept results.
Instead, I have to analyze and extract for Symantec.
Apparently no one else submits files to Symantec because this has happened TWO TIMES to me, and no one else seems to run into this!
But then, I've also found MULTIPLE NEW THREATS for Symantec when Symantec says an outfit THIS SMALL should not see new threats!
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
I tried again, ZIPPING the
I tried again, ZIPPING the original WORM.EXE and giving it a password.
We'll see........ but I'm only going to try this this one time, then that's it as I don't have time for another fight.
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
Password protected zip files aren't accepted
I can't remember if the submission mechanism itself checks for passwords on compressed files or not, but assuming it doesn't, development won't open a password protected file.
I have sent all of this info
I have sent all of this info to our sales person, telling them this gets resolved very soon.....................
I'm doing this not only for me, for our agency, but also any other customer frustrated with the overly complex submission process, a process that says we can't submit a worm file because the worm author was clever enough to make it an archive.
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
Bologna! Last time I
Bologna! Last time I WAS TOLD TO SUBMIT WITH A PASSWORD and include the password in the comments!
I bet that message is still in the forum here.
I was told to password protect it, and to use a password that was NOT common, such as don't use the password "password" for example.
AND IT WAS TAKEN last time.
Symantec Security Response Automation: Tracking #13361440
password = password-ivrs
this is NOT a file I created using 10 or more files. This is an EXE that is ZIPPED with a password.
This EXE is exactly as it came to our computer, so I"m not responsible for it being a container with more than 10 files.
Symantec wants submissions or they don't.
I submit them EXACTLY as we get them with zero changes.
Technically, according to rules, I shouldn't even be touching a worm or suspected worm file so I'm doing it for multiple reasons, not the smallest of which is as a favor to all involved.
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
Wow, amazing..............5
Wow, amazing..............5 days later. Guess their system really IS stopped up with too many submissions! This is something I can take to our management to show them what they got hit with. Just kidding...........
Has ANYONE else seen a file named sdra64.exe and if so, what did SEP say it was, and were YOU able to submit it?
That's ok, though. I've got our sales engineers working on the terrible experiences attempting to submit a single EXE file now............
Our reps are the best and quite responsive. I'll give them time to work.............
I'm still attempting to figure out why sdra64.exe keeps showing up, ends up in the system restore folder as if it's a system or OS file, and is ID'd as two different things at different times. Since I can't submit it, I may never know what it was, how it got here, and if it's still around somewhere.
Maybe it no longer matters even............
-------------------------------------------------------
My sites - http://theamcpages.com & http://antique-engines.com
Toy:
Shadow:
Would you like to reply?
Login or Register to post your comment.