|
It appears that a lot of people infected with the TDSS/TDL3 rootkit I was talking about before are now getting bluescreened after patch Tuesday. http://tech.slashdot.org/story/10/02/12/1455203/Rootkit-May-Be-Behind-Windows-Blue-Screen (slashdot but the original source seems to be down) Most likely because the update may try to patch the stealthed atapi.sys file, with all those file writes going through the rootkit, and the rootkit doesn't properly implement them so the system is left in some horrible intermediate state when it reboots. MS can't tell that atapi.sys has already been patched by the rootkit since it's stealthed and appears totally normal, and the rootkit can't properly apply the MS update since it won't allow writing to its patched code. Nice.
|
#
¿
Feb 12, 2010 20:36
|
|
|
|
| # ¿ Apr 27, 2024 13:01 |
|
|
Stanley Pain posted:What's the best anti-rootkit/scanner thingy for Windows 7 64bit? Haven't really found anything that works well. there are no kernel-mode rootkits for windows 7 64-bit
|
|
#
¿
Feb 22, 2010 22:24
|
|
|
PopeOnARope posted:Though that makes me feel better about my system security, it baffles me as to how some of my login info got lifted. oh I'm sure there's plenty of userland malware and keyloggers, and most of the 32-bit stuff will work straight up without problems there just aren't any kernel-mode rootkits because 64-bit Windows enforces driver signing, and so far the only bypasses have been proof-of-concepts using infected boot sectors or BIOSes, nothing actually in the wild
|
|
#
¿
Feb 22, 2010 22:42
|
|
|
There's a new worm going around called Stuxnet that's exploiting a Windows vulnerability that isn't yet publicly disclosed. The worm autoruns from USB sticks even if you have autorun disabled fully. It does this by exploiting a vulnerability in the way Windows parses .lnk shortcut files. Once run, it installs a rootkit that hides the files on the USB disk so you can't tell you (or it) are infected. From looking at the vulnerability today, it isn't specific to USB drives -- all that's needed to execute the worm is that you browse to the shortcut files from explorer. The good news is it's relatively easy for anti-virus products to detect for the .lnk files in a way that (should) stop them running if you have an on-access scanner.
|
|
#
¿
Jul 15, 2010 19:55
|
|
|
Midelne posted:When you say "browse to", do you mean open a folder containing the malicious .lnk, or does there actually need to be some selection or clicking of the file in question? Just open a folder. The critical thing is that explorer loads the icon. There's a thread on Wilders here: http://www.wilderssecurity.com/showthread.php?t=276994
|
|
#
¿
Jul 15, 2010 20:03
|
|
|
Midelne posted:That was a fun read, thanks. Any opinion on the later posts suggesting that it was custom-made for targeted industrial espionage? I haven't looked at the usermode part of the payload yet but I might get a chance tomorrow. Frank Boldewin is a fairly well-respected reverse engineer though it looks like he's just seen a string rip from the executable and I think it'll probably be a day or two before anyone says for sure. I'm more interested in how they managed to sign their rootkit drivers as Realtek. Gotta be some sweet drama there. Also there's no obfuscation at all on any of the kernel modules so I'd guess this is a completely different group to those that release most of the major malware families.
|
|
#
¿
Jul 15, 2010 20:31
|
|
|
Midelne posted:Didn't seem to be any significant consensus at this point as to whether it was a valid signature or not, but yeah, I'd certainly be interested in knowing whether Realtek's CA had been subverted somehow. If so, that's, uh, substantial. Windows tells you the signature is OK if you right-click properties the file. But the timestamp on it is expired and I'm not sure if it's since been revoked.
|
|
#
¿
Jul 15, 2010 20:37
|
|
|
the LNK file exploit also works from a webpage, at least if the victim is using IE
|
|
#
¿
Jul 21, 2010 22:22
|
|
|
TDL3 now has a 64-bit variant that infects the MBR instead of an existing driver. http://www.kernelmode.info/forum/viewtopic.php?f=16&t=19&start=370 This will be interesting to follow since with Patchguard MS removed many of the tools anti-rootkit software uses to detect and remove things. The ball is really in their court to stop Patchguard being bypassed. Until then you can probably remove it really easily with fixmbr or some other boot CD solution. Easier than 32-bit TDL3 at least.
|
|
#
¿
Aug 26, 2010 19:19
|
|
|
COCKMOUTH.GIF posted:I have a system here that I've been scanning and cleaning. It's Vista 32-bit and I believe it had some variant of the fake antivirus malware going around. It looks clean for the most part. Every scanner I toss at it comes up clean, but when I run GMER, it crashes when it reaches the point where it scans what appears to be the volume on the hard disk. I'm thinking it has an MBR infection but it's hard to say. Are there any tools to determine this for sure or should I just use something like the Microsoft Vista Recovery disk to run a FIXMBR? Or maybe Microsoft DaRT? Some Sinowal/Torpig/Mebroot variants crash when a usermode app tries to read from the raw disk. Howver this could just be gmer crashing like usual... You might want to try the two MBR-related tools from eSage: http://www.esagelab.com/
|
|
#
¿
Aug 27, 2010 10:09
|
|
|
Maniaman posted:One thing I don't really understand.. How is it that antivirus companies have yet to pick up on most malware? Almost every computer I see infected with SuperXP7AntiMalwareWindowsVirusVistaRemover has some form of antivirus running, just sitting in the system tray chilling out. Do they not bother with them because they aren't traditional viruses? What's the line between a traditional virus and malware? It's nothing to do with whether they're viruses or not. The actual reasons are not always obvious, but (imho) the main on is the way tests and reviews of AV software work. Which leads me to my rant... A big problem with the AV industry at the moment is that most users make purchase decisions based on reviews involving large scale testing against malware files -- but with most of these tests, they don't bother to test whether the AV software involved actually detects or fixes the thing when its running, just whether the files involved are detected when they're sitting on some test machine. This naturally forces the AV companies to focus mostly on the files aspect, neglecting things like run-time detection and anti-rootkit functionality. Usually it's there in most AV suites, but it doesn't receive the same level of resourcing. Couple this with the fact that file detection is not too useful in the real world because the malware authors update stuff far too frequently (though this doesn't show up in most AV tests -- see the pattern here?). Thankfully all this is changing as some testers are finally raising their game and not testing against a million outdated files that are of no consequence to anyone -- rather, they're testing cleanup of already-infected systems and the ability to cope with rootkits etc. Though the are still testers that stick with the sample sets, "in the wild" lists (complete bollocks) and do "proactive" tests that just roll back virus data as if that's somehow relevant to customer protection. Do your best to ignore these ones. It'll take time but things should improve. For now the best thing you can do is buy an AV product based on recommndations from friends that have actually used it rather than reviews that claim to have tested against millions of virus samples.
|
|
#
¿
Oct 17, 2010 10:57
|
|
|
Otacon posted:Just removed a rootkit last night - redbook.sys, infected usbhub.sys, rdpcdd.sys, mrxsmb.sys, and mup.sys - virus names were Rootkitdrv.HS, Alureon.H, and Oficla.M - Combofix helped me immensely, and a repair install finished it off. The biggest issue I had? Figuring out how to use a mouse and keyboard after I nuked the infected usbhub.sys file. You might want to try using Kaspersky's TDSSKiller next time you see a TDSS, TDL3 or Alureon infection: http://support.kaspersky.com/viruses/solutions?qid=208280684 Generally tools like that can disinfect the infected driver file without totally removing it.
|
|
#
¿
Nov 6, 2010 14:29
|
|
|
sfwarlock posted:Which raises a Stupid Question. If Windows needs to have iastor.sys* loaded in memory in order to read the hard drive, how does it read the hard drive to get iastor.sys into memory in the first place? it starts off going through the BIOS int 13 interface until the disk drivers are loaded -- hooking that interface as part of the MBR startup code is how these MBR-infecting rootkits get loaded into Windows in the first place
|
|
#
¿
Nov 8, 2010 20:45
|
|
|
PopeOnARope posted:We came across Win32.TDSS.TDL4 in the wild today. On a Windows 7 x64 system Since it sounds like you have an imaging solution, could it be that this is somehow confusing the whole MBR/partition boot situation? How about any full disk encryption software or RAID? These can all complicate the MBR cleaning process, though I'm not sure how TDSSKiller specifically deals with them. If you can boot a Linux or Windows environment from CD, you can use a hex editor to copy an MBR from a clean Windows drive, but you'll need to be careful only to copy the code portion of the MBR, not the partition table (just the first 0x1b8 bytes). There's an outside chance that the TDL4 rootkit has started encrypting the partition table to make fixmbr unusable, but I think other reasons are more likely.
|
|
#
¿
Nov 22, 2010 14:11
|
|
|
Saint Sputnik posted:The other day I noticed some Google results being redirected, seemingly at random. When I've had the problem before, it usually hijacked searched about hijacked searches, but just now I googled "nook sd slot" and the first result redirected to some casino bullshit. Couple scans of Spybot didn't help. Spybot might have added a lot of adware or malware domains to the hosts file with redirects to localhost or their own servers, to prevent things being downloaded from them. From the way your searches are redirected it sounds like you might have the TDL3/TDSS rootkit, try TDSSKiller.
|
|
#
¿
Dec 16, 2010 16:21
|
|
|
mindphlux posted:I'm putting together a new toolkit, as my last one (hijackthis, spybot, adaware, AVG) is kind of lol. I tend to find the following are enough for most things, but it's not as automated as something like combofix or malwarebytes: Process Hacker Process Monitor Autoruns Rootkit Unhooker (newer beta versions are available on the forums at kernelmode.info)
|
|
#
¿
Feb 4, 2011 10:16
|
|
|
Maniaman posted:On the subject of rootkits, I'm finding a LOT more rogues are installing rootkits with them. This time 6 months ago you'd run into the occasional rootkit with ComboFix or TDSSKiller. Now I'm finding almost every machine that comes in has some variant of the TDSS rootkit on it. It tends to be the other way around, the rootkit gets installed first and downloads the fake antivirus -- this is why if you just remove the fake AV from the machine it usually comes straight back the next time the rootkit calls home. The groups creating the rootkit/downloaders like TDSS sell them to the groups running the fake antivirus rackets, so you see them mixed and matched a lot.
|
|
#
¿
Feb 9, 2011 23:57
|
|
|
I find NoScript to be more trouble than it's worth to be honest. Using AdBlock and a browser that blocks known malicious sites (Firefox and IE both do, I assume Chrome does too) is less intrusive and still quite effective.
|
|
#
¿
Mar 21, 2011 10:40
|
|
|
Megiddo posted:The problem with just using AdBlock and/or FlashBlock is that they don't block the execution of scripts or prevent content from downloading - in many, if not most, cases they just block it from displaying in the browser by merely hiding the ad content. Unless you block the scripts from running in the first place with something like NoScript, you're still open to attack from malicious scripts. AdBlock Plus for Firefox does stop content from being downloaded. I'm not sure about other browsers (I think the Chrome one was recently updated to do this). You can probably test by killing Flash, opening a new browser window and browsing a site with a single blocked Flash ad, then seeing if Flash has been loaded. The problem I have with NoScript is really that it's so fiddly and most users won't know which sites to allow, because there are a whole lot of legitimate uses for cross-domain javascript loading these days. Also, in cases where the malicious JS is embedded in the compromised page itself, it's not so useful since you probably already whitelisted the page. If you know in advance that you're going to be visiting some compromised or malicious sites then NoScript is great, but for regular browsing it's overkill by far and steps over the line from "good enough security" to "interfering with productivity".
|
|
#
¿
Mar 21, 2011 11:52
|
|
|
co199 posted:Ever notice how all the malware that hits Windows machines is always "Win Security 2011"? And then a week later it's "Microsoft Security 2011"? Congratulations, it's a malware kit! Change a few words on a template, change the randomization scheme and you just made a new rogue that can't be detected (one big reason why signature detection doesn't work). Detection is hard because the authors are manually updating the obfuscation they use on the code. It doesn't have too much to do with the name or branding of the fake AV program itself, and the creation kits can't usually make changes that break detection signatures (except straight checksums) -- it takes a human author to do that.
|
|
#
¿
May 26, 2011 09:49
|
|
|
co199 posted:That's true, and I was over simplifying the process. I've been out of the research game for a couple years now so I don't have the details I used to. That being said, it's really hard to find an explanation for a customer when they ask "well why didn't xxx program detect this?" The "malware kit", while not 100% correct, works when you're dealing with someone who doesn't give a poo poo about the technical details and just wants an answer. Hell, it's a better answer than a bunch of other shops around here give, which is "because that one is a bad AV program, buy this one". Neither answer solves the problem, but one doesn't cost the customer unnecessary money. I knew some support techs that just told them that no one product detects everything and point them to the usual comparatives sites. Seemed to work OK. Generally it's easier now because if a product has good HIPS or in-memory detection the customer can at least clean it all up (hopefully with a single click) after getting infected.
|
|
#
¿
May 26, 2011 16:57
|
|
|
Hex Darkstar posted:Well thats a first, came across a detection on a users machine that was a heuristic detection by Artemis for a .scr file named "Recycled". I sent it off to ThreatExpert and the results were kind of disturbing. It creates a sys file and service based off that sys file that is set to start at 0x1 so it is set to start as a system service That sys file isn't part of the virus. It's the system component of the Themida copy protection system: http://www.oreans.com/themida.php The malware author has just packed his lovely bot with Themida, which is what's dropped the sys file. So you don't have that to worry about at least -- and leaving the sys file around probably won't do any harm. The connections to China are definitely not from that though.
|
|
#
¿
Apr 15, 2012 17:38
|
|
Oh yea did I forget to mention that it also tries to contact a remote location that was in China according to the report?
|
Scaramouche posted:Read this on TheReg: Schneier has misunderstood the malware industry. Flame and Stuxnet go undetected because they are so narrowly targetted that no one sees a sample for years (even though backend AV systems have collected them). Their authors are only interested in some very specific information from a few targets. Commercial malware can't do that because the return per infection is so low that they need to infect a whole load of machines to make any real money. Of course there will be financially motivated, targeted threats out there but they're rare. They aren't as well engineered as Stuxnet and Flame so they're much more likely to be picked up by AV heuristics even though they've not been seen before (although most likely they were created with a kit that has been seen a lot).
|
|
#
¿
Jun 20, 2012 00:34
|
|
|
|
| # ¿ Apr 27, 2024 13:01 |
|
|
tjl posted:Zero-days are one thing, but I have to agree with Scaramouche. Traditional methods have fallen way behind. I routinely upload suspicious .exe files I come across to Virustotal. Drive by downloads, e-mail attachments, etc. More and more often nothing detects them as being malicious. Virustotal only tests static file detection, which is something AV companies have been moving away from for the last 7+ years. It's not a representative test of what would happen if you actually ran the file on a machine with a particular AV product. The reason for this is exactly what you posted -- the files themselves are tweaked by hand several times a day to make sure they evade detection on Virustotal-style scanners. That's why AV companies now care less about just detecting the files (except they still have to detect them retroactively to pander to independent testers and people who judge effectiveness with Virustotal) and more about blocking or reversing what they do to a system.
|
|
#
¿
Jun 20, 2012 11:25
|
|