Can Malware infect your pc without Executing??

yes indeed.

 

The most informative discussion for a long time.

 

Yes, they are. But they cannot be executed without genuine executable. They should be loaded (or injected) into some process to get a chance to be executed. The problem is that "some" process can be pretty trusted (so allowed) one.

 

You can show that a .dll file is an executable by attempting to open one in a text editor:


______________________________________________________________________

This applies to other executable file types, such as .ocx, .sys, .cpl, .drv. As has been pointed out by others, these need to be launched by another program in order to run; that is, if you d-click on these files, Windows prompts with the Open-With box because these files have no file association, hence, the Windows generic icon.

An interesting exploit this summer using a .dll file involved the Safari browser which downloaded files directly to the desktop without a prompt. A Proof of Concept page was set up for a remote code execution example, and I was curious, so I installed Safari to see how it worked. Sure enough:


______________________________________________________________________

This "feature" has been eliminated, but even so, simple execution protection will block any attempt at such foolishness:


______________________________________________________________________

Another way .dll or similar files can run is by being spawned directly by a self-contained executable. A good example of this appeared some years ago in the Firewall Leaktest, Firehole.exe.

The author of the program wrote,

To demonstrate, I permitted Firehole.exe to download and be included on Anti-Executable's Whitelist. Then, I re-enabled Anti-Executable and attempted to run Firehole.exe which attempts to extract a .dll:


______________________________________________________________________

This can only be answered by each person in light of her/his security strategy and computing habits.

If I were tricked into thinking Firehole.exe was a legitimate program, I would have disabled Anti-Executable and the program would have installed its .dll file.

Would a HIPS know if the .dll were malicious or not? Many programs install numerous .dll, .sys, .drv files and write to the system directories. How to insure that one of these files is not compromised? Should one scan every file that the installer runs?

_____________________________________________________________________________​

Back to your original topic -- I would re-state: Malware cannot infect if it doesn't get downloaded onto your computer.

When the Firewall Leaktests first surfaced, a couple of us Kerio 2.1.5 users played wise-guys and bragged that we passed all of them. How can that be when the web site showed Kerio failed most? Answer: security in place prevented the test executables from downloading.

Not fair, was the cry. Why not? Why should we permit a test file posing as a trojan to download and execute, to show that our firewall didn't protect against something it wasn't designed to do in the first place?

It seems to me that more basic than "How would malware execute" is, "How could malware executables download to your system in the first place?" Or an Office document infected with a macro? Or a malicious script (.bat, .vbs) in an Autorun.inf file? Under what circumstances are you concerned that you might be tricked?

At this point, another aspect of security -- your state of mind -- enters into play. This is true in all security, not just computers. How you secure your home when away depends on how likely you think someone might enter through a window, by breaking a door lock, etc. The type of insurance you provide for your personal effects depends on the same thing. So, we take the fear factor into account. A still relevant take on this is Bruce Schneier's book, Beyond Fear: Thinking Sensibly about Security in an Uncertain World

So, for your computing, how you answer the above questions for yourself will determine what types of security products you decide to install.

I emphasize for yourself because no one can know what is right for someone else without being familiar with the person and her/his system and computing habits.

---

 

Alex is correct.

 

@ Rmus!

As always nice post.

 

Hi all,

I've noticed that the majority of AV do not scan .zip/.rar files that happen to be password protected. Therefore, malware might be hiding in there to do their nasty things. Am I right? If not, please I stand to be corrected.


Best regards,



Carlos

 

am i the only person for whom the words 'perfect protection' cry out snake oil? are folks really that naive?

 

not only are you right but in fact this has been used to the advantage of a number of mass mailing worms...

password protecting the archive is supposed to encrypt it's contents... it wouldn't be worth much if that encryption could just be ignored...

 

I don't know. Here is my take, if you have abc.rar which has password : xyz with a malicious file inside. AV scanners will miss it, since it can't decode the encrypted file.

Now if the malicious file wants to infect you, it has to somehow decrypt itself and then execute. Hence for decryption, some process must be run and resultant file must be expanded either into file or memory. Even if you take dll based approach to decode the archive, during memory read/write or file read/write, I am sure the AV scanner will find the malicious object.

But incase you don't have a AV scanner and just say Anti-Executable. Then you are open to even more basic attacks based on DLL execution/injection.

 

Wrt these mass mailing worms... Eh, my personal view is - 100% PEBKAC issue. Seriously, if you are stupid enough to not only open unknown attachments but even supply the password given in the email because the malware can't work otherwise , well... stupidity taken to entirely new level.

The password was plaintext first, then AVs learnt how to use this to decrypt the files so the malware guys changed their strategy and started to stick the password into a picture... IIRC some AVs even implemented a barebone OCR to work around this, meh... I haven't seen such email for a while, so this got out of fashion I guess. These mail-facing AVs and products have an option to treat encrypted archives as virus and either strip the attachment or discard the mail altogether.

 

returnil always on when on internet and nothing else seems to work the best and light on resources
i do have antivir etc on portable usb but don't have to use them just scan a file if i want to save to external
what if anything can get me
perfect?

 

Interesting out of all the other topics and posts I have read in the firewall forums regarding "INCOMING" firewall Protection I have never seen anyone say untill now that Kerio 2.1.5 can block malware executables from being downloaded in the "First Place" I allways thought that software firewalls cauld not achieve this that instead you need to use a Antivirus webfilter which scans Incoming traffic for Malware.

Whats the Firewall Rule in Kerio to achieve this? because you have to allow remote TCP connections on port 80 to be able to load web pages, or Does
malware executables get downloaded from a different Port?

 

i think in the hips section of the program choose internet explorer to block files downloads i tried already it is good but also block child processes like if you tried to use media player trugh iexplorer then media player is block.any downloads from internet explorer is block if you configure so.
also coreforce can be able to block executables files on high

 

Hello, arran,

When I read through this thread yesterday I thought, now this is a great topic because it affords the opportunity to think through this whole business of how malware downloads and executes. Am I in control of my computer or not?

My statement about "security in place" refers to a few paragraphs above the one you quote from my post, where I explained that in order for me to download the Leaktest Firehole.exe, I had to disable my execution prevention security:


________________________________________________________________

Without my permission to download, it could not execute.

If the malware executable is triggered by remote code execution (drive-by download), this also is easily prevented, as I showed with the Safari PoC.

This can be applied, in addition to emails, to on-line .pdf files, Word documents, media files; unknown USB sticks, etc: how do you decide what to open, whether or not it can be trusted?

This, of course, is the weakest link in anyone's security strategy: how to deal with files you knowingly want to download/install, how to insure that they are safe.

Scanning may or may not be reliable. A HIPS program may or may not be reliable.

As I wrote in the other post, each person has to decide what types of security products will give the most comfort level and peace of mind.

Over the years, I've found doktornotor's observation to be the most pertinent and most reliable preventative measure.


---

 

True, but it is nice to have protections in place. In my work, I receive emails with attachments and a very good amount of those have titles that are in Chinese or other. To miss something there is a loss on business. True, I could develop a database on past usage, but even with that I would not "know" the user. And the pace is just too quick to in-depth analyze things. Even if you do know the user, you might not know if the attachment was originated by that user or not. So in effect, for me anyway, unknown and known attachments are treated the same. I believe that is Franklins point on Sandboxie,in that anything and everything, known and unknown, is contained.

 

The only reliable protection here is to throw every encrypted attachment away on mailservers (and in fact, that's what a majority of people do). You need to realize that email is NOT a way to exchange files, you can use HTTP, FTP or whatever else designed for such task instead.

As far as loss of business is concerned, how many legitimate business partners have sent you an email with encrypted attachments as a first contact? The answer is - zero.

 

Encryption and passwords aside, just an in general comment on email attachments. It may not be user stupidity that necessitates opening an email attachment, and for me the Sandboxie protection does fits that bill completely.

 

No, but mother-in-laws do

 

Hello, can u explain how did u test it.

IMO archive bomb is no threat. I just tried to unzip it. After many unzips I got tired and stopped it. Until that time it only occupied few hundred MB of my HD in one folder.

Also some one thinking of it as a legit file will not bother to unzip it( as it will need to be unzipped dozens of time).

Thanks for any input.

 

Aigle, I didn't unzip it all, I just showed that it can't run within a sandbox which has been configured to allow only certain apps.

Not sure on this but I think way back before any blacklist scanners, AV's, could detect these archive bombs that some would keep on automatically unpacking the zips during a scan until your hard drive filled up.

There must be some sort of auto extractor around the place if you want to see your hard drive run out of space as a testing?

 

42.zip is very old PoC which proves your AV scanner (e.g. which scans on your mail server) can be security hole, instead your security solution...

 

You don't need a malicious exe to execute a malicious dll. Rundll.exe, Rundll32.exe, svchost.exe and others can all execute dll's. A malicious dll can come from any of the usual infection vectors, a compromised download, bundled software, e-mail, loaded via browser exploit, the last bad link a user clicked on, links opened by hta's, etc. Most of the time, it's the actions of the user that gets it all started but not always.

Some form of execution is required for malware to infect your PC. The malware itself doesn't have to be directly executable. If it's executed by a legitimate process, the results the same.

It almost always comes back to the user and how they handle files, media, etc from outside sources. How well HIPS defends the PC is also dependent on the user, how tightly it's configured, is an install mode used, do they disable it during installs, etc. If properly configured and kept fully functional at all times, the good ones can defend a system very well. HIPS fail when the user fails. AVs fail for many reasons.

Your statement "...whether or not it can be trusted?" is the key. "Trust" is the primary reason users get infected. My policy is to not trust any content, file, etc from outside sources. That doesn't mean I won't open it but it does affect how that material is handled. If I'm going to install something, I'll try it on a test unit first. Before installing to my main PC, I make a system backup. Nothing gets tried out for the first time on my main PC.

I treat all internet content as potentially malicious. Apps that handle content from the internet or from outside sources are as isolated from the OS and each other as possible, both by HIPS and system configuration. Internet content is filtered thru Proxomitron and several browser extensions. None of these apps can launch each other and have as little system access as I can give them. Most users would consider this setup inconvenient, having to download a media file or PDF, then open it in a separate process. I view it as potential damage control. I start with these assumptions:

1. All software is exploitable.
2. Software that handles internet and external content will eventually be exploited.
3. Users make bad decisions.

Assuming that any one of the apps that open unknown content will be exploited eventually, isolating them from each other and from the OS as much as possible may well prevent an exploited application from becoming an infected system.
As for bad user decisions, both the HIPS and firewall require a password to access them. The HIPS has the UI disconnected so another user won't see a prompt. If they try to launch an unknown, they see "access denied." I don't trust the other users of this PC to make security conscious decisions about its usage, and it won't ask them to.

 

Even the old faithful, Internet Explorer, can do so! -- as demonstrated in the Safari exploit I mentioned above.

Your examples illustrate what I've always advocated, that each person set up policies that meet the specific need.

An example in my case: when I was teaching, those in my department opened many Word documents weekly. The threat was macro viruses, and we weren't comfortable that AV would have the latest outbreaks in their databases, so our policy was to open the documents in MS Wordviewer, or in a text editor which wouldn't run any code.

For the student labs, computers had Deep Freeze installed, so it was a non-issue there.

Unfortunately, many are fooled by emails, and they are becoming more sophisticated. A recent example:

Beware of Fake Microsoft Security Update Email
http://readerszone.com/microsoft/beware-of-fake-microsoft-security-update-email.html

Suggested policies

==> Know how updates for your various products are handled by your vendors.
Microsoft does not send updates or executable files by email

==> Know how sites with which you do business deal with security. Three of mine:

When I used to help people set up their system, I insisted that they have this understanding,
and that they look at the company's site's security center frequently.

Finally, I don't think it's particularly effective to just say, "Don't click on anything unknown." I keep a collection of screen shots of fake stuff (such as the above MS fake update), and also of various exploits, to show people. A visual aid reinforces the policy you are trying to get across.

----

 

Yet another bogus email rife with grammatical errors, so it should be easy to spot for those whose native tongue is English. It would, admittedly, get tricky for those learning the language. Still, it is not to my knowledge common practice for MS to email security alerts to the public, unless I'm missing something.