Inconsistency may be caused by the huge distance to Frankfurt. Ping 190ms must be at least 25 hops, likely more. I'm only 5 hops away, ping 12ms. I have WiFi disabled, and don't use a browser, but the Windows app, from Breitbandmessung.de
The issue is, that average users will follow the advice to block. Blocking updates may cause security risks.
Could you please send the file to virus@wisevector.com, we will analyze it if it is benign we will whitelist it.
Sorry for the late. We have tested the Floxif samples you provided, WVSX's advanced detection blocked them all.
I'm sorry if you're not happy about the answer, but it's true Floxif did't infect the system in our testing.
Yes I can understand that WVSX performs quite good when it comes to blocking code injection. But my question is purely technical. There are 4 tools that claim to block banking trojans proactively, but they do it in a different way, let me explain: HitmanPro.Alert: alerts about modified browser memory G Data BankGuard: alerts about modified browser memory and replaces the modified API's Trusteer Rapport: blocks modification of browser API's related to SSL network traffic SpyShelter: blocks modification of browser API's related to SSL network traffic So my question is, do you know how Trusteer and SpyShelter are able to block banking trojans from setting network hooks even after code injection? This has strangely enough never been explained. Or perhaps I'm misunderstanding and they are simply blocking code injection, similar to other HIPS?
We tested with iVPN + WireGuard enabled. Sometimes the internet speed is even faster when WVSX is on, in most cases there is only a minor difference. WVSX is on WVSX is off
It is possible to detect user mode hooks. For example, for inline hooks the standard way to do this is to overwrite the first 5 bytes of the function with a jump to malicious code, so the AV can check the first 5 bytes to see if the function has been hooked or not.
OK thanks, this is some useful info. I think they are indeed probably monitoring this stuff, so this would mean that they can block it even after succesful code injection. I have tested SpyShelter against the Zemana SSL keylogger simulator and it will always correctly block it from setting network hooks, even if you allow it to install a global hook.
That's not the case for me. A few days ago, I had no internet connection again. After shutting down WiseVector I had internet access again. I had kept WiseVector closed since I noticed the speed issues, but I rebooted a few days, so WiseVector was running again.
In recent MRG-Effitas test, they use (in-house coded?) "Banking Simulator test". Only Eset, Malwarebytes and Symantec Endpoint passed this test. It would interesting to know, what kind of method they use for this simulator test.
that's a lottery in these tests, you never know which av will win, and what methods they use so I stop looking at them. I am a bit confused with wvsx standard it does not seam to update, so I disabled its connections , also because it is not using cloud and doing everything locally so whats the point of letting it connect?
When testing AV it is better to use in-the-wild malware since AV often has a higher tolerance for programs produced by reputable companies.
If possible, you can also try to use some BitTorrent clients to download big files at maximum speed, and then check if the the download speed will be affected when WVSX is on.
WVSX is constantly updating for signatures, models, etc. So it is better to allow internet access for WVSX.
I can't do that when I have no internet connection. For now, I never have WiseVector running due to the internet problems.
Sorry but I don’t quite follow you. Is the "internet problems" mean that whenever your computer resumes from sleep, you must quit WVSX to get internet connection?
Actually, the Zemana simulator is wrongly detected by Win Defender as malware. But to clarify, it's a tool that I use to test if SpyShelter works correctly. This simulator will use global hook and DLL injection to intercept network traffic and SS correctly blocks it, even if you allow code injection.
Refer to pages 37-38 in the .pdf download. Remember the MRG simulator test uses custom code written by them. What is described in the write-up lists what non-detected activity results in test failure.