Stuxnet .(lnk exploit malware) versus HIPS

may you test malware defender ,please?

thanks

 

It must be same as Comodo v 3. I might try later.

 

Hi, have you tried it with defensewall ?
Which results will it have with virtualisation's software like bufferzone or sandboxie ?

 

Is it the same behavior with Comodo Firewall v5.3 with .tmp files. Can you test by changing sandbox level to untrusted.

Note: As i earlier posted, for me CFW (sandbox set to untrusted) did not fail when tested through sandboxie and my OS is completely patched.

 

Vipre antivirus premium passed test:

 

In December of 2008 the malware landscape changed forever with the arrival of the Conficker worm. In the variant that infected via USB, there were several sneaky parts of the attack that thwarted almost all security measures.

One was the malware file itself that was loaded by the shellexecute command in the autorun.inf file:



From an analysis:

If the security in place doesn't analyze the code of the file to be executed, the user is left with attempting to guess what file extensions she/he should configure the product to recognize.

Stuxnet uses .tmp so you have to test with the .tmp file extension for that particular exploit.

Just keep in mind that Conficker demonstrated that you can use any file extension.

Therefore, if people want to carry over these tests against Stuxnet to consider any possible future exploits, you need to try DLL files with random file extensions.

Otherwise, you have a false sense of security.

One example: Version 4 of Faronics Anti-executable reinstates DLL prevention (removed in version 3). I discovered it does not intercept DLLs with spoofed file extensions , so would not have blocked Stuxnet.

Very bad.

regards,

-rich

 

Hi, Rmus, in all anti-executable HIPS software you don,t need to configure file extensions to intercept execution of any executable file. They either intercept the execution or don,t intercept( Comodo v3 is an exception).

Actually, here, contrary to Anti-Executable, the case of classical HIPS is reverse. The classical HIPS might be more on risk to be bypassed by dll extensions, rather than other extensions. So testing them with dll extension was a harder and more tough test for these HIPS, IMO.

 

Sorry, those don't show HIPS in action, only the Antivirus part that has a signature for the PoC ("A known bad file..." as shown in the On-access scanner notification)

 

Hi aigle,

That's nice to know. In my comment referring to "security in place" I was thinking of things like SRP where you have to include file extensions in some cases.

I can see your dilemma. Your tests are very helpful, as always!

Anti-executable v. 2 was an exception to the normal anti-execution non-HIPS products, in that one of its detections was code analysis as well as file extensions. So, Stuxnet was an easy catch.

On v.4 this seems to be true for EXE files -- it detects spoofed file extensions -- but does not with DLL files.
Very curious.

regards,

-rich

 

Have you tried changing the extension of a file, from a blocked extension, and see if it still executes?

Sometime ago there was a discussion around SRP blocked/allowed extensions to see what extensions really meant in this scenario. Even if extensions do have a role in SRP, a .cmd file is always a .cmd file, even if the extension is renamed, so if it's being blocked, SRP should block it. The same is to say that if DLLs are being blocked, then they should still be blocked, regardless the extension being different. If it's a dll, it should be blocked.

Give it a try, and see what you find.

 

We should probably take this up further in another thread, since aigle is focusing on HIPS.

regards,

-rich

 

The link you provided to the site is blocked by Norton DNS, it may be malicious.

 

Oh, I never meant to say that you should reply to us here at this thread, or another. I meant as something you could try for yourself.

 

one, stupid, question:
why did you test OA4? newest version is out, and a lot of things are changed

Regards

 

Only because it I had this version installed in a snapshot of CTM.

Besides I did not expect anything new in the latest version that will change the results of this testing. Do you expect so?

 

Yes, this was a very very unique feature of AE. I was soooo impressed by this feature as this mitigates a lot of social engineering involved with the malware spread.

I am not sure why they dropped this feature and I am more surprised why no other HIPS or security software adds such a feature. I will once again say that security software vendors seem a bit lazy in fight against malware, they like a cat and mouse game, may be because they are getting profits in this game and a little bit of cat n mouse game is essential for their survival. Just a feeling that I can,t hide.

 

Honestly no reasons to expect a different result from previous version.

I find your tests and observations always very interesting, keep up the good work

 

Ok, can you give me the download link?

Thanks

 

No, I did not but I expect them to pass.

Hope you understand that I can,t test each and every software mentioned in this thread.

 

Ouch!

I hope not -- I've read Peter's research on his site for some years and have never seen something like this noted.

Nonetheless, I've de-linked the URL just to be safe!

regards,

-rich

 

Blocked by Bitdefender TrafficLight as well... Something weird going on there apparently.

Back to the subject here - nice test, thanks.

 

as per norton safe web it is hosting malicious pdf links. when scanned the same with sitescanner, i get the same results -
http://siteinspector.comodo.com/public/reports/19400

 

His analysis of exploits papers contain code, so that may be producing the alert.

I've removed the link so as not to cause any problems!

thanks,

-rich

 

See here:

https://www.wilderssecurity.com/showthread.php?p=1863963#post1863963


-rich

 

Re jwgkvsq.vmx as posted by Rmus

Thought i'd experiment by renaming a .DLL & see what happened.

Recently i've added this Extra protection afforded by ProcessGuard



Changed gmer.dll to jwgkvsq.vmx and double clicked it



I then had to manually locate Gmer.exe which is disguised as 1.0.15.15315 sjjvxc8c.exe for stealth Double clicked it and



Due to



1.0.15.15315 sjjvxc8c.exe is already in my allowed list in PG, but a new .SYS is always needed to run. PG is set to block all unknown drivers etc, as shown in my first screenie, so it failed to install

GMER did launch, as it's allowed, but with expected errors



So it "appears" that GMER recognised jwgkvsq.vmx as it's own .DLL inspite of being renamed ? If it was not legit i doubt if it would have.

If anyone thinks i've overlooked anything, please feel to critique