Zero Day-How's your AV

Please try on the next occurence of a new in-the-wild exploit (no PoC please) and post your results.

No, because I know how it works - I mentioned this in a previous post.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Well, I don't use a behaviour blocker, but there are plenty of people here using Prevx, Cyberhawk. I would like to see some results with real malware too.

lzx32 is more stealth than wincom32:
- Wincom32 (called Trojan.Peacomm by Symantec):
Link1
Link2

- Lzx32 (called Rustock.B by Symantec)
Link1
Link2

 

Thanks Rich, I got your point now.

 

A little bit of humor won't hurt

 

trjam,
I stopped running a resident AV once I was convinced SSM could handle the resident protection. The last one I used was AntiVir, version 6. That's been just under 2 years ago now. I do have 3 AV scanners available but most of the time it's easier to upload whatever needs scanning to VT.

I initially had a hard time trusting SSM as well. Two things finally convinced/pushed me to let SSM handle the resident protection.
AntiVir was releasing version 7, which I didn't like at all for multiple reasons. Most every other AV I tried was either too bloated for my liking, not configurable enough, or conflicted with something else I use. Because I use an older OS, I was being forced to find an alternative solution.

I had been using Max's version of SSM for a while by then and was just coming to grips with its abilities. When System Safety took over its development, I started beta testing for them. Part of that testing was equipping a test PC with just SSM and Kerio 2.1.5, then visiting every malicious site I could find with IE6 on abnormally low security settings, openeing infected e-mail, and using live malware from anywhere I could get it. After about 6 months of trying to exploit this test box, tightening rules, and repeating, I was convinced that SSM, tightly configured combined with a default-deny strategy and a tight firewall was sufficient to defend a PC against most anything, except the user own mistakes.

Shortly afterwards, I did a complete reformat of my system, equipped it the way I wanted it, and made a backup image of the "C" drive. All my data files were moved to an external hard drive, leaving the internal drive strictly for the OS and installed software. This way, even if SSM failed, I could easily re-image the "C" drive and be right back to a clean state in minutes. I've never had to use a backup image because of my security package failing. I have used backups to revert to the previous state when an app I chose to install didn't meet with my liking, but never from virus or malware.

I don't know how much they've changed since I opened that account. I've had it for years and always got lots of spam there, even when it was just a normal webmail account. Most likely, it's the way I been using that account the last couple years. I've deliberately used and posted that e-mail addy at the most questionable places I could find for the purpose of collecting infected material for testing SSM. It's worked very well for this. Sometimes I get 30 or more infected e-mails a week.

I can't believe you posted this!! If a user chooses to run that unsolicited "patch" from an unknown source without scanning it, monitoring the install, making a system backup beforehand, and shuts down the security software, that user has no security policy at all, or any sense for that matter. IMO, there's no such category as trusted installing. ALL CODE is suspect when being installed, no matter where it's from. The code, application, patch, whatever doesn't have to be malicious to cause major problems. One coding mistake or conflict with an existing application can be just as damaging if you don't have a way to revert to the previous state. How many people have had problems from M$ own patches, or finding an update to an already installed application is incompatible with something else you use?

• Always scan everything you intend to install, no matter what it is. Use more than one AV.
• Always make a system backup before installing anything. If you take the time to separate your data and personal files from your operating system and installed software, system backups are quite small. Often they fit on a couple of CDRWs.
• Do not shut down your security software during an install. Your system is at its most vulnerable when installing. The prompts tell you what's going on during that install. Read them.
• Monitor the install. Apps like Inctrl5 and Install Spy document the changes made by the install process.

Default-deny is not a type of protection, configuration, setting, etc. It's a security policy that specifies what applications, executables, user behaviors, etc are allowed and permits only these. It's the basis for the security software you choose, the reasoning behind the way you configure them, and the standard answer to unknown and unsolicited prompts, requests, etc. With true default-deny, non-administrative users do not get prompted with unknowns. The security apps say "NO" for them. Default-deny is a strategy that prevents changes, whether they're attempted by users, malicious code, or legitimate software. It's a strategy that's for completed, finished systems, systems that are equipped the way its owner or administrator wants it. This is the security strategy and type of system that SSM is ideally suited for. SSM is also best suited for those who know what is on that system, what those processes are and what they do. The better you know your system, the tighter you're able to configure apps like SSM to only permit those activities, processes, etc that your system needs to function. Of course, SSM is effective with different setups, strategies, etc, but default-deny is the policy most suited to its design.
Rick

 

In my case it's slightly different; I had a relatively easy transition to HIPS, what I can't bring myself to trust is that SSM is going to protect me well enough when it has no file defense capabilities. Something that won't alert me when a process tries to modify or delete executable files doesn't sit very well with me.

 

Well, I'm envious! I have to depend on others sending me stuff.

Well, I have to disagree here. If I trust the sources of the software I purchase, then I trust the installation. It's been my way of doing things for 15+ years. Everyone has to deal with this category in her/his own way. And so, you say,

There is nothing wrong with that. But it doesn't necessarily have to apply to everyone.

No quibble here

If I don't disable my execution protection [default-deny] and reboot Deep Freeze Thawed, then I can't install a program.

Now we come full circle back around to patch_.exe. I wrote,

and you wrote,

I whole-heartedly agree. But my users wouldn't have do all of that scanning, monitoring, because

1) they know that patches/fixes don't come by email so wouldn't consider installing it in the first place

2) they wouldn't find such a thing on the reputable sites from which they download anyway.

My statement was in response to the idea that execution protection would prevent this type of email exploit. It would prevent the inadvertant extracting of the executable, but wouldn't prevent someone making the decision to install it. Once they have made that decision, their own methods of installing come into play - whether or not they scan, etc.

As far as scanning -- it's been shown that most AV missed this file anyway, so scanning it wouldn't have helped, depending on the person's AV -- which is the point of this thread, as quoted in Post #1,

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Actually, the fact that you scan means you didn't leave scanners behind.
AV's are still necessary. Even for you.

 

I still use AV scanners to check incoming files. I don't run a resident AV. I don't consider the AV as a primary defense.
The best way I can explain the difference is like this. AVs and most other resident anti-whatever apps are default-allow. I'm not including apps like anti-executable here, just signature and reference file based apps, conventional security apps. Unless the item in question is included in the detections or otherwise sets off some heuristic detection, it's allowed to run. Windows itself is designed that way. Anything that's not expressly blocked can run.

Signature based detections were fine when most viruses were written by amateurs and circulated by e-mail. Most people used dialup. Connection speeds were slow and users were disconnected more than they were online. The rate of spread was slow, the quantities fairly low. Moreover, the purpose of the malicious code was different. For many of them it was just for recognition.
Now PCs are connected 24/7 at high speed. There's hundreds of thousands of variants, professionally coded, designed to take control of PCs, steal passwords, etc. The goals are money and power. Distribution can be almost instant, thanks to malware controlled botnets. The vendors of signature based apps have much less time to react. The malware itself is much nastier, much of it directly attacking security-ware if it gets to execute. The quantities are huge. There's too much malware spreading too fast thru too many delivery methods to count on a reactionary security strategy that depends on identifying the malicious code. There's no way signature based detections can keep up.

The particular malware this thread centers on points out only one of the shortcomings of signature based detections, that AVs may not recognize a given piece of malware for several reasons. With that piece of malware, the user has a choice of whether it's executed or not. That's not always the case. In the case of a malicious or compromised website, the malware can be made to download and execute with no user action. If the malware is a rootkit and directly attacks security-ware, conventional AVs have no chance of removing it if it executes before they recognize it.

The only real defense is preventing unknown from executing. That's where a default-deny strategy applies, which SSM enforces. My security strategy boils down to "all unknowns are blacklisted until I decide otherwise." For me, the AV is more for information purposes, not for blocking. The scan results are one factor in determining if the unknown or untrusted item has any chance of making it onto my whitelist.
With blacklist methods, it boils down to "identify, block if identified as malicious, otherwise allow."
With whitelisting or default-deny, its "block, allow if identified as known and harmless."
The black and white lists aren't the problem. It's the grey list that's the problem, the unknowns and untrusted. A security strategy that allows those grey items to execute will always be at greater risk from new or unidentified malicious code than one that blocks them.
Rick

 

I totally agree with Herbalist 100% here, and in fact, his most recent post should be a Forum sticky IMHO.

 

I think as other folks had mentioned many times before, each person had to evaluate his/her own security needs and operating environment before deciding on what security programs to deploy. For someone who tries out a lot of different programs obtained from the internet, a HIPS program may not be a convenient choice. A sandbox, VM, quick snapshot/restore program (combined with anti-xxxxx programs) may fit better. Also, signature+heuristic detection still can catch quite many malwares out there which may raise a red flag to the user if such detection can identify a malware (even eventually). E.g., for a casual user who uses some sort of sandbox + anti-xxxxx programs, his/her PC may be protected from a presently undetected malware by the sandbox and the same malware may be detected by the anti-xxxxx programs within days, weeks, etc. So it is probable that the user may see a warning from the anti-xxxxx programs down the road and that may prevent the user from spreading the malware unintentionally by sending it to friends, despite no harm had been done to the user's computer all along.

 

Like everyone else i search and i search, then i test and i test, over and over again for just the right combination that will offer the most PC protection overall. I have KIS6 only recently within the past month or so and already it's a dust collector. HIPS are just too super-efficient at snagging the potential threats from their inbound traack to whatever folder they've zeroed in on. Still though, you can't count out an AV just yet, theres a little matter of installing new programs these days and from what i seen of some of them lately, it's just as easy to get something "laced" with filedioxide that can contain the potential to make your PC sick and give you the willies if they do happen to elude those hair-trigger file-suspending sensors of HIPS.

Since turning to FD-ISR i've all but 100% totally eliminated any risk of forced intrusion be it self-inflicted or forced upon that can do any damage, big or little. Couple that with a dependable Imaging Software and a nice safe METAL! external or internal storage facility (HD), and you've all but sealed your own fate in enjoying 0% risk of permanant distraction/destruction of your system/data collections.