Jump to content

zombunny2

Members
  • Content Count

    88
  • Joined

  • Last visited

  • Days Won

    18

zombunny2 last won the day on December 4 2021

zombunny2 had the most liked content!

Community Reputation

26 Excellent

About zombunny2

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @ANKUSH, can you clarify what you mean? Are you saying that Immunet keeps resetting these settings to "on", after you switch them "off"? If that is the case, it is a bug or error in the software. I remember Immunet once behaving like this with me in the past. I cannot remember what I did to fix it, I think I uninstalled Immunet. When the uninstaller asked if I wanted to reinstall Immunet later (keep settings), I said "no". I probably used either Revo Uninstaller or BCUninstaller to remove all traces of Immunet. I think I then rebooted the computer, and reinstalled Immunet, and it worked fine after that.
  2. @Adriano, Please open the Immunet interface by either clicking its icon on the desktop/start-menu, or double-clicking the tray icon, and perform the following steps:- On the right-hand panel of the Immunet interface (the panel title is "Product"), click on "Settings". Scroll down the settings, and click on the option "Notification Settings", to expand it. A menu appears, "Tray Icon Notifications", with 3 options ("Cloud Notifications", "Verbose Tray Notifications", "Gaming Mode"). Ensure that the second option ("Verbose Tray Notifications") is set to "off". I think that the behaviour you experience is caused by the "verbose tray notifications" setting, which someone must have toggled to "on". When this is "on", Immunet reports all files it scans, whereas if it is set to "off", Immunet only reports infected files.
  3. I don't use Immunet much now, because it has proven too buggy recently, and I don't really use Windows anymore, but I have a couple of custom scripts that essentailly do what you're asking for and certainly worked on previous Immunet versions within the last year. I won't paste the entire code here as my scripts have evolved into a nasty kluge and they're messy and difficult to understand, so I'll just post the important bits here and you can construct your own to suit your needs. Points to remember: Immunet stores its ClamAV databases in the installation directory, in a subfolder of a subfolder (i.e. "clamav\[clamav-version]\"). So for instance, the databases will be in something like "C:\Program Files\Immunet\clamav\0.103.3". While Immunet is running, it protects its installation directory and all subfolders. To copy files into the folder, you need to stop and restart Immunet. Immunet's service, in the past, has included the version number, changed between "Immunet", "ImmunetProtect", and other names. The only thing that's remained consistent is the fact it contains "Immunet" within its name. So a standard "net stop / net start" command with Immunet's exact service name will be unreliable and will be prone to breakage. You need to instead start or stop any service that contains the string "Immunet" in its name, which should account for these changes. If you have installed Immunet a while ago and upgraded it many times, there will be multiple clamav-version subfolders (0.102, 0.103, etc) but only the latest one will be the active one that Immunet uses. This is very important because the database will only be read from that folder. General idea of how it works: My script uses rsync (Windows port) and/or curl (now part of Windows) as necessary to download the custom databases of SecuriteInfo, Sane Security and others. The script then tries to deduce the ClamAV installation directory, with the assumption that Immunet itself is installed to its default location ("%ProgramFiles%\Immunet"). It makes the assumption that the last ClamAV directory to be installed will be the latest version. FOR /F "delims=" %%A IN ('dir/s/b/og/o-d "%ProgramFiles%\Immunet\clamav"') DO ( SET TEMPVAR=%%A GOTO :GetClamDb ) :GetClamDb set db=%TEMPVAR% I can't remember why I did it with two sections like that. I think I use the "GetClamDb" label as a way of breaking-out of a loop or something elsewhere in the script. Either way, what it effectively does is look for the newest subfolder within the "clamav" folder, and sets the "db" variable to be the path of that folder. So now we know where ClamAV (and its database) are stored, and that value is in the variable %db%. The script then stops Immunet, which removes protection from the installation directory to make it writeable: REM Stop the Immunet service, without worrying whether it's called "ImmunetProtect", "Immunet 6.0.8", etc. wmic service where "name like 'Immunet%%'" call stopservice REM Now let's give a short delay to give the service chance to shut down. echo Will hopefully be able to copy files now. choice /t 10 /n /d y (please note that if you type this in on the command line, you don't want two "%" symbols after the name "Immunet", just one. You need the two "%" symbols if running this from a batch file). The script then copies the downloaded database-files to the ClamAV installation directory so they can be used: rem copy db xcopy /F /Y /D /G /H /R folder-i-downloaded-the-databases-to\*.* "%db%" echo Will hopefully be able to restart Immunet now. rem pause so you can see any error messages etc choice /t 10 /n /d y And then all that remains is to restart the Immunet service(s) in the same manner we initially stopped them: rem restart immunet rem The less robust way was this: net start "Immunet 6.0.8" rem now we do the following wmic service where "name like 'Immunet%%'" call startservice Please note I've not put any error/failure handing into these snippets of code, it's just to get you started. Also - you could theoretically use rsync or curl to download the custom databases straight into the ClamAV installation directory, but I prefer to download them to a temp folder somewhere, and then only stop Immunet to copy the changed databases across. That way, Immunet is stopped as little as possible, and you're not being left vulnerable the whole time it takes the custom databases to download. This is particularly important if you're not on a paid SecuriteInfo account, as their free databases appear to be rate-limited to ~384kbps download speed. If it makes your code any easier to understand or more readable, you could just hard-code everything in, however if installation folders or service names change with software-updates, your code will be broken until you edit it. I hope this helps. When I tidy up my installation scripts, I'll post the full code. That said, I don't know when I'll manage it because despite how clunky and botched they are, they work for me. Plus nowadays I do almost all my work on GNU/Linux, and only really boot Windows up to apply updates then shut-down again. I figure it should stay relatively up-to-date just in case I ever need to use it.
  4. I would second Ritchie's recommendation to seek alternatives to Defender, even if the computer isn't really used for anything online. Windows Defender currently seems to get good reviews and provide good protection, according to some of the test labs, however there are three major problems with it: It's the built-in solution, so most malware will target holes in it, be designed to disable it, or will be specifically designed to evade its detection. Its historical record has been extremely variable and patchy. One month it has been the worst performer and the next, one of the top performers. It's not historically been consistent like the well-known names have. Its ransomware and exploit protection ("controlled folder access") is responsible for much of its apparent effectiveness, but is horrendously simplistic and aggressive. It even blocks built-in Windows features such as the commandline utilities format.com, chkdsk, xcopy and so on... It also blocks non-Microsoft browsers such as Firefox. In whitelisting these features, you essentially open-up each one of them to exploit. In order to have a usable system, I had to exclude Firefox, cmd, PowerShell and others from the "controlled folder access". This essentially opened-up the main vector for malware-delivery (the browser), and also opened-up the main two script interpreters used by ransomware, effectively leaving me with no protection at all. Additionally, I find it breaks most installation programs, because it doesn't allow them to save files or create shortcuts! If you really want Windows Defender, I'd recommend running it in tandem with MalwareBytes premium (with "integrate with security center" turned off so it doesn't disable defender), and make sure to disable "controlled folder access" within defender, as MalwareBytes would handle that part of the protection. You could also run MalwareBytes in tandem with Immunet, but Immunet will disable Defender (like virtually all other AVs do). You could also run just MalwareBytes, or just Immunet. Immunet's static file detection rate isn't the best, but it's sometimes better than Defender, and I think Immunet's behavoural blocking is less intrusive than Defender's. It certainly breaks your system less! Besides MalwareBytes, I've noticed Sophos Home Free works brilliantly alongside Immunet. Kaspersky free also works well, but I had stability issues until I put Kaspersky's folders in Immunet's exclusions, and Immunet's folders in Kaspersky's exclusions. F-Secure Antivirus (I haven't tried Total/Safe etc) works perfectly with Immunet too. Comodo Internet Security also worked well when I tried it a couple of years ago, but its behavioural/HIPS/firewall components are incredibly noisy and aggressive, so you have to use it a long time before it learns what's good or not so good on your system. If you want a lightweight solution, I'd recommend Immunet alongside either Voodooshield or NoVirusThanks OSArmor. Voodooshield is pretty noisy at first, but is free (gratis); I think OSArmor is far more polished and user-friendly, and worth paying for. Alternatively, just wipe the hard disk and install Linux Mint, Trisquel, or Debian, and have no worries about all this nonsense.
  5. Your query looks a lot like you are running Immunet in some sort of organisation or corporate environment. Immunet is targeted at home users, so you may find you can only accomplish what you need with the corporate "version", Cisco AMP, instead. Additionally, support is not provided to Immunet users in corporate environments. If you have already tried adding the relevant scripts and program components to Immunet's exception lists, and it still doesn't work, and you're not a home user, just buy AMP. To the best of my knowledge you can't add specific ports as exceptions in Immunet and it's not intended for having config changes pushed remotely (e.g. via Powershell) because those are the sorts of things home users don't usually need to do.
  6. I have found Immunet to play nicely with Sophos home free in the past. It worked with no exclusions added to either; however to be on the safe side, I excluded Sophos's "program files" and "programdata" folders in Immunet, and Immunet's (Program Files\Immunet, Program Files\Cisco\Immunet, Programdata\Immunet, Programdata\Cisco\Immunet) in Sophos. I also tried Immunet with Kaspersky home free and I seem to remember it worked OK but did require each being added to the other's exclusions list to be stable. On my Windows box, I currently use it in tandem with both F-Secure AV and Malwarebytes Premium with no issues (because Malwarebytes itself is also a "companion AV"). To ensure this will work with no problems, I enter each program and add the other two solutions' "Program Files" and "Programdata" folders as exclusions. You'd think it would drag it down but it works fine on a circa-2011 machine with 4GB RAM and a mechanical hard disk drive. That said, I don't use Windows much nowadays as am almost completely a full-time Linux user. The solution is probably overkill, especially for my limited usage, but it's a Windows box, it's the low-hanging fruit that all opportunistic crackers and social-engineering scammers go for. It's the weak point from which all my documents could get trashed or accounts compromised. I figure even it it's overkill, a year's protection from the two paid-for solutions still costs less than a single tank of fuel for your car.
  7. I love that you have kept that machine running so long, and that you still have a use for it! I still use a 32-bit Intel Atom netbook when I need an ultra-portable computer, but that's running Debian GNU/Linux now since XP support ended. You may be pleased to know that ClamWin has come back from the dead and the latest version of the ClamAV engine has been ported to it. I believe ClamWin still supports all Windows versions back to 98. There are only two downsides I can see: (You would also have this problem with Immunet) - The standard ClamAV databases main.cvd, daily.cvd and bytecode.cvd currently occupy ~430MB (at the time of writing) just on disk. In other words, loading them into RAM on your XP machine would consume almost all of its RAM, even before we consider the scanning engine, GUI components and Windows itself. In everyday usage I tend to experience ClamAV occupying around 1GB RAM when doing a scan of a directory, whether that's measured using Linux's "top" command or Windows' "task manager" utility. Therefore you may find that scans on your old XP machine simply don't run, or it pages to disk so much that it slows to a crawl. ClamWin doesn't do "on-access" scanning unlike most other AVs (including Immunet). You have to manually scan things yourself on-demand. Regarding the second downside, years ago I used to just do a daily full scan of all hard disks with ClamWin and a periodic (e.g. hourly) scan of the running processes in memory (ClamWin's "memory scan" option, similar to Immunet's "flash scan"). For an internet-connected machine in the modern day, this wouldn't be enough, but for your offline XP machine I'm sure it'd suffice, even if inconvenient. Regarding the first downside - if you can find some old SDRAM on online auction sites, old computers your friends have in the attic, or even your local computer repair shop*, just max out the RAM on your board. If you get it to 1 or 2 GB you'll probably find it'll run adequately. *A few years ago, an independent repair shop near me still had a few AMD 486-DX4 CPUs and 4MB sticks of RAM in stock. Your PIII's RAM is a lot more modern (probably PC100 SDRAM). You might find your PIII can cope with 4 sticks of 256MB (or possibly even 512MB) each of this stuff, giving you enough of a total to fire-up ClamWin. Good luck!
  8. P.S. to anyone that may have PM'd me about this issue, I'm not ignoring you, I just can't get access or reply on this forum software as it doesn't work properly. I can just see the preview that gets sent to my e-mail. Will keep periodically trying...
  9. Update: I have just tried Immunet on 2 different machines, and my previous trick of enabling ClamAV and database updates, but not blocking mode, and waiting for ages doing nothing, seems to have resulted in an initial download of the databse files main.cvd, daily.cvd and bytecode.cvd on both machines. Now, clicking "update now" from the GUI correctly results in the message "virus definitions are up to date". This is a very strange and intermittent issue. Maybe it is something to do with connectivity issues, especially since it began around a similar time to the ClamAV infrastructure no longer allowing database downloads via wget or a web browser. Having said that, the fact that a database download is attempted but fails to be applied seems rather odd to me, and would suggest it's actually an infrequent issue to do with write permissions to the Immunet installation folder (possibly Immunet's self-protection mechanism?). Anyway, I now have 2 Immunet installations where the ClamAV virus database has updated successfully at least once. Very strange but worth investigating by devs.
  10. I've just tried the latest 7.4 version of Immunet, and the ClamAV update bug is still present. Enabling ClamAV and virus db updates should result in Immunet automatically downloading the main.cvd, daily,cvd, and bytecode.cvd files to %programfiles%\Immunet\clamav\[clamav-version]\ . No cvd or cld files appear anywhere on the partition where Windows is installed, tested over a period of several hours. Manually checking for updates from the Immunet GUI (main screen --> update now) results in an attempt to download the ClamAV databases (starting with daily.cvd), however this reaches 100% and then terminates with the error "The updates could not be installed. Please try again later". This always fails (the error is consistent). None of the various kluges or workarounds I've previously tried with older 7.x versions work any more. Meanwhile, a plain ClamAV installation updates flawlessly via freshclam. So just a warning to other Immunet users - you probably have no offline protection at all (or severely outdated offline protection). And a request to devs to actually fix this longstanding issue. Steps to reproduce: 1. Install Immunet on a fresh W10 x64 PC or VM. 2. Enable ClamAV and db updates, if not already enabled. 3. Wait for database to be downloaded, and/or manually update via "update now". Works on every machine I've tried so far, for the past few Immunet versions. What's most concerning (apart from the very longstanding nature of this bug) is that the failure is silent, unless the update has been triggered by the GUI. The silent failure potentially leads users into a false sense of security, thinking they have protection via ClamAV when in fact they don't.
  11. Many generic Windows installers can be called from the "run" dialogue (SUPER + R) or from the command prompt with the "/silent" option. It's generally undocumented and support is not universal, but it sometimes works. So, if the Immunet installer is called "setup.exe" and resides in the root of drive D:, you'd hit SUPER+R, and type "D:\setup.exe /silent" in the box, then hit enter/OK. Other commandline options that may get you what you want: /silentinstall or /verysilent or /y I've not tried any of the above but I've seen and used them for various other installers. I'm fairly certain Chocolatey makes use of this trick for most installers, so you may want to see if you can find Immunet's NuGet install script on Chocolatey's web site to see how it calls Immunet's installer. To deploy this on another machine, you'd have a .bat file calling the installer with the correct commandline option, and run that instead of running the installer directly. This does of course sound a bit like you might be managing some sort of commercial deployment, so if this is the case then AMP will suit your needs better and is of course licenced and supported for such scenarios. Sometimes it's worse to use the wrong tool for the job than to just not do the job at all. If something's worth doing, it's worth doing right. If you're doing this for an organisation, just get AMP.
  12. I suspect that adding Adobe's "program files" directory will do little or nothing to alleviate your problem, unless it also uses that location for its cache. Do you know (or know how to find out) where your Adobe software stores all its cache files? Seeing as all the file reading and writing is causing Immunet to repeatedly scan everything as it's read/written, you need to find out the location on this disk where all the reading/writing is taking place. I.e. you need to find the directory that Adobe uses for its cache. If you exclude this directory, you may find that performance returns to normal acceptable levels. Good candidates to watch would be any "Adobe" related folder that resides within %programdata%, or see if Adobe creates an "Adobe" folder within %temp%. In the meantime, you can speed up your systems slightly by de-activating the ClamAV engine, and/or blocking mode - however the former will decrease your offline-protection and the latter will decrease your overall protection. Good luck.
  13. I've just had a look at the Blackmart app description and I'm not surprised Immunet's quarantining it. It's an unofficial app store, so contains code to download other apps - hence might have code similarities to trojan droppers. So could be a false-positive. But there are much bigger concerns with this app: It's worth noting that Blackmart's description says it makes-available cracked versions of premium software. I'd therefore suggest you don't use it as you're far more likely to get a virus or trojan in cracked software and the app-stores that promote such software. Shady developers of cracked apps already have less morals, therefore are more-likely to insert malware to further their own ends. They have no problem stealing from developers, why would they suddenly develop a conscience when faced with the choice of stealing your bank details or uploading your nude selfies to porn sites? They also come into contact with other shady developers and shady apps more often, therefore are more likely to have been compromised themselves, and therefore are more likely to unknowingly be inserting malware into their apps. I'd recommend steering clear. There's no need to ever crack an app when there's almost-always a freeware or free/open-source app with the same functionality. Try to stick to app-stores such as F-Droid (free and open-source), UpToDown (virus-scans their apps and supplies legitimate apps), the /e/ store (legitimate apps) and Aptoide (if you stick to the verified apps and avoid cracked apps, there are a few security checks performed on them). If it's a particular game you want to crack, or something else that you can't really find an equivalent to, make your decision: it's either worth paying-for or it's not worth playing at all.
  14. You're right, an Android .apk will not harm a Windows system, as Windows can't execute an APK by itself, without an Android emulator. However, it's common (and a bit of a courtesy) for virus scanners to detect malware for other platforms - ClamAV, the engine that powers Immunet's offline detection capabilities, wouldn't exist if this wasn't the case, as it was originally developed for Unix-like platforms at a time when viruses for these platforms were simply not observed in the wild. The ability to detect threats in .apk archives is therefore handy for people who sideload apps on to their Android devices using ADB, etc. - Just as scanning a word .doc on your BSD or Linux system helps prevent you passing an infection on to a Windows user when you send it to them. If you don't know where the APK file is coming from, I suspect a web site is dropping it on your computer in an attempt to infect you. Most web exploits used to target Windows, but with the massive amount of Android devices now, as well as the fact that manufacturers stop releasing security-patches for them far too early, this means that there are millions of people browsing the net on insecure Android devices, which makes them a desirable and easy target, much like Windows used to be. One of the web sites you're viewing may have been compromised, (or more likely, the ad network displaying ads on it has been compromised) and it's speculatively dropping an infected apk onto your machine, in the hope you're an Android user who can get infected. Immunet rightly detects the apk and attempts to quarantine it. If the site deletes it before Immunet has had the chance to quarantine it, then quarantine will naturally fail. Also, if Immunet is your secondary protection, your primary protection might neutralise it before Immunet gets the chance, resulting in the "quarantine failed" message. If you have downloaded the APK manually yourself, there's a good chance that the .apk file is compromised and has a trojan in it along with the legitimate program. Sometimes it's a malicious download where someone's compromised a popular app and uploaded it to one of the many download sites - and sometimes it's the developer's fault because they often bundle in telemetry and adware into apps (especially gratis ones). After e-mail, the biggest vector I've ever seen for malware-distribution is the advertising/tracking networks. You can embed an ad in your website or app one day, thinking it's clean - but the ad will be different each time it's viewed, and each time is an opportunity for a malicious ad to get displayed. The ad networks don't care so don't check their own ads before serving them. Again, this will result in a detection from Immunet and a quarantine-failure if either the file is deleted or your primary AV cleans it, before Immunet gets the chance. It might be worth doing a full scan of your system with Immunet, and then another with your primary protection (and/or Windows Defender) to root-out anything stubborn. Don't use your computer until the full scans are all complete, and try to close anything you can that's running in the background before you do the scans (temporarily close/exit any unnecessary tray icons like Skype, your printer software, your Sat Nav updater, iTunes, and so on).
  15. If you are running Immunet in parallel with another AV like Norton, you can safely disable the ClamAV module in Immunet. ClamAV is very CPU-intensive, and you may find that this is the component that's causing the CPU-spike. I personally leave ClamAV enabled, because I often add custom signatures to it - but it does really hammer that CPU. You should also make sure you've gone into Immunet's settings and excluded Symantec/Norton's directories under %programfiles%, %programfiles(x86)% and %programdata% as relevant/necessary. You may also want to add Immunet's folders to Norton's exclusions (these are %programfiles%\Cisco\Immunet, %programfiles%\Immunet, %programdata%\Cisco\Immunet, %programdata%\Immunet if you are running 64-bit). I'd be willing to bet a lot of your trouble is Norton and Immunet scanning each other whenever they do anything. As WilliamKing321 states, updates and things also cause this behaviour. I know when my W10 is running an update because Immunet in particular starts consuming massive resources scanning it all. And seeing as I'm a fairly infrequent Windows user, this is very noticeable every time I have the misfortune of needing to boot that operating-system.
×
×
  • Create New...