Jump to content

zombunny2

Members
  • Content Count

    59
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by zombunny2

  1. I made the assumption that everyone still logs out of sites when they're not using them, so forgot to mention... Because of the way the malware works, if you've been affected you should log out of all of your sites and services, as well as changing your password. I also forgot that "Edge" is a browser too. I've never had any desire to subject myself to it, but I believe it can now run Chrome extensions too, so if you're an Edge user who's installed Nano, you could also be infected.
  2. ClamAV eats a lot of CPU, especially if you have "scan on install" combined with "blocking mode" turned on. This will slow your machine so the best thing to do is only enable ClamAV if you are using Immunet as your sole AV. As ClamAV is signature-based, it should display no network-usage at all, unless updating (or attempting to update). Your high network usage can only therefore be coming from checking task-manager while ClamAV is attempting to perform an update. You are likely seeing ClamAV attempting a lot of updates because it keeps failing, so therefore stays "out of date", and therefore keeps trying again. There is a bug in the latest version(s?) of Immunet, where ClamAV updates keep failing. I have noticed that any installations I've performed "the proper way" (by downloading from the Immunet web site) display this problem, whereas when I installed using Chocolatey it didn't. I'm not sure if it's coincidence or if it's something to do with the Chocolatey install process, for instance the commandline-arguments that Chocolatey passes to installers. If you want to try this, uninstall Immunet first, selecting "no" to the "keep settings" dialog, to make sure none of the old configuration remains. YMMV.
  3. This is not stricly related to Immunet, but may be worth highlighting to visitors of this forum. In October, the lead developer of the popular adblocker extension "Nano Adblocker" and companion extension "Nano Defender" sold the identity and code-repository access (effectively "sold the extension") to some previously-unknown Middle-Eastern developers. In his defence, he had been unable to keep up with the maintenance requirements of the addon, and wanted its development to continue rather than leave his users "high and dry". He also performed some (albeit) minimal background-checking on the new developers before the sale, although he may have been a little naive and therefore too trusting. Unfortunately, the first thing the new developers did was introduce some very crudely-obfuscated spyware into the popular extensions. In a rudimentary attempt to conceal the existence of the spyware, the developers even attempted to have the extension detect if the browser's developer console was open, and modify its behaviour accordingly. If you use Chrome, (which is arguably a piece of spyware in and of itself), it is important that you remove these extensions immediately. I suspect the same extension will also be used in Opera/Vivaldi/Brave, so if you are a user of those browsers this could also apply to you. Fortunately, the Firefox version of the extension has not yet been updated with the malware changes, as the extension is developed for Chrome, and ported to Firefox by another maintainer. The new spyware was exposed before the Firefox maintainer had pulled-in the upstream code-changes. That said, it would be a smart move to delete this extension if you are using it on Firefox, as I don't see any updates being made to it from now on. You will probably find Gorhill's uBlock Origin a suitable replacement for Nano Adblocker, and in fact it is the extension from which Nano takes most of its (non-malicious) code. If you are already a uBlock Origin user, please doublecheck that you didn't install Nano Defender at some time, to protect uBlock. Fortunately, at the time of writing, this malware is easy to remove: Simply uninstall the Nano Adblocker and Nano Defender extensions. Then change all of your passwords. If you are extremely worried, and want to make extra sure that your browser profile is clean, delete your browser profile and create a new one. To the best of my knowledge Immunet does not yet detect these extensions when installed. I think it'd be a good idea for us to all treat this as a warning that an extension is only as trustworthy as its developer, and that the same developer may not always "own" an extension. It'd therefore be a good opportunity to have a look at all your browser extensions, and uninstall the ones you don't use. You could also take a look to get a feel for the public profile of each developer. Uninstall any that make you uneasy. Broadly-speaking, if it's not under a free (libre)/open-source licence, you can't verify that the code is benign and you need to be confident that you know how the developer(s) are paying for their time and resources. More info: GHacks Article Ars Technica Article
  4. This thread gave me a smile (much like the kind of smile you get when you wake up, open your coffin-lid, and see that the moon is full)! I have been doing a bit of investigating on every Windows machine I can get my hands on. Update Bug It seems that when I install Immunet the "normal" way, I get varied results. Whenever I have installed Immunet via the "Chocolatey" package-manager, it's worked perfectly and as-expected. This could be a coincidence, but it might be worth looking at the Chocolatey install scripts to see how the Immunet installer is called. All my Chocolatey-installed Immunet installations update the ClamAV engine as expected, with no kluges or workarounds necessary. "Restore from Quarantine Failed" Bug I think I detailed on another thread elsewhere on this forum, that occasionally, the "restore" feature failed, causing a quarantined file to be lost for good. I have noticed that this failure only occurs if the machine is under load, especially if you try to restore the file while Immunet is still performing its scan. A workaround is therefore to ensure that any Immunet scan has completed, and the machine is sitting idle, before attempting a restore from quarantine. This to me implies some sort of "timeout" issue between separate threads of Immunet - for instance the GUI thinking that the service isn't responding because the load on the machine is causing it to take too long. The solution would of course be to increase the relevant timeout value to a few minutes at the minimum.
  5. Ritchie, I'm surprised you haven't used BCUninstaller before. I do recommend you investigate it, because it's free and open-source (less incentive to spy on users, and less ability to hide such anti-features - also means programmers can contribute to or fork it). Most importantly, from the perspective of the "average Joe" who probably doesn't know or care about freedom-issues or spyware, it's a bit more thorough than Revo, and detects things like optional Windows components and Chocolatey packages. For those who are interested there's actually a massive discussion-thread over at Wilders where somebody tested every single uninstaller they could get their hands on, although I don't have the patience to read it all, and it also indicates that there's no cut-and-dry "best" or "better" one for all possible use-cases. By the way, I have no connection with BCUninstaller or its developer(s) and I still regard Revo pretty highly too. Using either in one of the "safe mode" options of Windows should purge Orbital out of the system. You can get into safe mode by starting your PC and then pressing the reset button as soon as it's started booting. If you do this 3 times, Windows detects the failed attempt at booting, and gives you the option to enter safe mode. Another option is to shut down the PC holding the shift key, and then navigate through all the counterintuitive menus and submenus until you accidentally stumble-across the hidden option to enter safe mode. It's a far cry from just holding down F5 when your computer starts (or F8 to get the boot menu). I think Microsoft's design-team have spent too much time sniffing glue or something.
  6. Note: I wouldn't normally advocate registry-cleaners, especially CCleaner, but this is the one instance where I think they can have some merit. I also forgot to add that another reason I tend to favour BCUninstaller is that it is often pretty clever at telling you if any processes need to be killed in order to remove an installed program, and gives you the option to kill those processes.
  7. Goodness me, these last few versions of Immunet have been am embarrassing bug-ridden mess, haven't they!? I'm sure Ritchie or the Immunet staff will have the best solution, but I find BCUninstaller (it stands for "Bulk cr*p uninstaller") to be very good at removing all traces of an installed program, even if it no longer has an entry in "add/remove programs", or uninstallation fails. BCUninstaller is similar to the well-known "Revo Uninstaller", except I find it to have the two advantages of being more effective, and also being under a free (libre) licence rather than being proprietary and closed-source. Having said that, if you are already familiar with Revo, it should still do the job well. Prior to using BCUninstaller or Revo to remote it, you may need to reboot your box into safe mode (or even safe mode with command prompt) to make sure that Immunet/Orbital isn't running and trying to protect itself from tampering. If the worst comes to the worst, it might be possible to boot into a Linux live USB and manually delete the Immunet/Orbital program files, then use BCUninstaller/Revo (or a registry cleaner such as CCleaner) to remove the remaining traces.
  8. Hello Frank, yes I do overwrite the old ClamAV version, effectively making a "FrankenImmunet" with version 0.103.0 of ClamAV in Immunet's "0.102.1.76" folder. Critical files such as freshclam.exe etc. get overwritten, and the module seemingly loads correctly (and even detects things if you manually put the ClamAV database in there yourself) - it just doesn't update itself. I don't think it's a ClamAV version issue, as old versions of ClamAV on Linux boxes (or even the abandonware ClamWin package) are still capable of updating themselves, although really old versions of the engine of course balk at newer databases and won't load them properly. Also - at least one of my Immunet installations has updated itself at least once since I started noticing this issue. I think it might be some sort of Immunet self-protection issue, as the update is attempted and at least one cvd file will download to 100%, but it then won't subsequently be installed in Immunet's ClamAV dir. It's still not ideal that Immunet are bundling an outdated ClamAV engine with their software. I will try to update my FrankenImmunet again, because this solution fixed update-problems on previous versions of Immunet. It may be that after doing this modification I didn't realise my database was still current, so naturally there'd be no updating to do.
  9. Hello Ritchie, the machine that started working experienced multiple failures updating the database after this first initial update - and then I think might have subsequently updated successfully. --- As an additional test...: I have tried Immunet on a second machine and nothing works to make the ClamAV module update on the second machine: I tried editing freshclam.conf to change the timeouts to much larger values. Update still fails. I tried booting from GNU/Linux and manually copying recent (a couple of days old) clamav cvd files to Immunet\clamav\[version] folder. Update seems to have been attempted once and failed. No further updates are attempted when clicking "update" in the Immunet GUI. I tried uncompressing the latest windows 64-bit clamav portable zip file from the ClamAV official website, overwriting the files in Immunet's %programfiles%\Immunet\clamav\[version] folder. No updates are attempted when clicking "update" in the Immunet GUI. I'm not sure what the difference is between the two machines. They're both 64-bit Windows 10 and Immunet was a fresh install (i.e. any previous installation had been removed with the "save settings: no" option). There is a log file in Immunet's ClamAV dir, which indicates that the ClamAV engine itself loads into memory, but I've not found any log file detailing what happens during an update attempt. It's a shame, as ClamAV can actually have a really good detection rate if you supplement it with the Securiteinfo and Sane Security custom databases. While attempting to diagnose it, I'm reluctant to customise my installation beyond anything required for the diagnostic effort, though.
  10. Hello Ritchie, in answer to your question, I never save my settings when I uninstall. I like to keep a new install / upgrade as "pure" as possible because it has historically saved me from various issues with Immunet - so I do a fresh install and manually add my settings or exclusions back in.
  11. Hmm, restore from quarantine seems fine now. I suspect this might just be related to system load. If the system is under stress when an attempt is made to restore from quarantine, it probably takes slightly too long for the GUI to communicate properly with the Immunet service, so the GUI assumes that the service isn't running, and/or the operation has failed. Intermittent error are the worst to diagnose and fix!
  12. It seems like there might be another issue in build 7.3.2, although I think it's an exacerbation of a long-standing one. I was running a full scan as a test in 7.3.2 and a few items (all false-positives so far) have been quarantined. Attempting to restore from quarantine results in "Restore from quarantine failed. Check agent is online". The agent is definitely online because I can still run more scans and quarantine (well, permanently lose) even more items. The unfortunate thing is, once a restoration attempt has failed once, Immunet won't let you even try to restore the item from quarantine again. This means that any files that have been quarantined and not restored are lost forever (subject to having adequate backups). This was always an intermittent (but rare issue) in Immunet, but in this latest build, it has happened on all but 1 of the detections in my initial test scan. This is why the "ask me" option in the settings should ask the question *before* quarantining, not after like it currently does.
  13. Wow, that's strange! I've just reinstalled Immunet (I had uninstalled it, selecting "no", so that all data and settings would be deleted). The first thing it did was update the ClamAV databases successfully! I hope this was just a temporary glitch. Fingers crossed it's now fixed...
  14. Another thing that had occurred to me, is that it could be a "self-protection" or "permissions" issue. The Immunet program folder is not writeable while the service is running. I wonder if Immunet has forgotten to give itself permission to write the databases to the folder?
  15. Sorry to have been the harbinger of doom! I agree with lavamagma in that it is probably some sort of timeout issue. A while back I started experiencing update timeouts with both Freshclam and the "clamav-unofficial-sigs" scripts on my GNU/Linux boxes. It was basically caused by a time-out value that was too low in freshclam.conf (or wget/curl's default settings, in the case of the unofficial signatures script). Once the database had grown to a certain size, it was impossible to download it quickly-enough for the entire file to be complete before the timeout was reached. This was initially noticeable with the unofficial signatures script, because the SecuriteInfo "old" database is extremely large (~300MB), and SecuriteInfo restricts download-speeds for free users to circa 384KB/s. I believe a change to the default freshclam.conf fixed this in one of the recent versions. I suspect that you won't see this issue if you've already downloaded all the ClamAV databases once, because subsequent updates only require downloading the latest .cld patches. One way to test this would be to manually download the ClamAV databases from the web site, stop Immunet's service, copy them to Immunet's ClamAV dir, and then restart Immunet. Another option, if Immunet honours freshclam.conf settings, is to look to see if freshclam.conf is present in the folder, and set the ConnectTimeout and ReceiveTimeout settings to something like 300 (5 minutes) and 3600 (1 hour) respectively. I may have a quick look at these two options when I am next back in Windows.
  16. Hi, Well, I tried out version 7.3.2 as it appears to have been released within the last few days, but alas there are still bugs... Basically the clamav module won't update. Steps to reproduce: enable clamav and definition updates in the settings click "update now" in main gui. Expected result: ClamAV main/daily/bytecode cvd files are downloaded GUI says "update completed" main/daily/bytecode cvd files appear in C:\program files\immunet\clamav\[version number]\ Actual result: The updater downloads daily.cvd, which reaches 100%, and then the GUI notifies the user, "unable to apply the updates. please try again later" No cvd files appear in c:\program files\immunet\clamav\[version number]\ (although one file, windows.cvd, already exists in this folder). This was done on a completely fresh installation of Immunet. I've tried restarting the computer. I know clamav isn't the greatest, but I still like to have some offline detection. Hopefully it's just a quirk on my particular computer, or maybe the server is temporarily busy. Has anyone else observed this?
  17. ...but seeing as we're on "keep your ideas coming", I'll add to the suggested new features, based on the assumption that Cisco decides to bug-fix and allocate some resources to Immunet, so will be capable of implementing them: A toggle-switch in the UI that enables/disables integration with the Windows Security center. Malwarebytes has this option. This means that you can choose to use the product alone (integrate with security center) or as a companion app (don't integrate with security center). At present, Immunet integrates with the security center, which means that you can't use it in tandem with Windows Defender at all (it disables WD automatically). Also, if you use it as a companion to another AV, Windows security center warns you that you shouldn't run two AV at the same time. Of course, this warning is unnecessary because Immunet is designed as a companion AV. Additionally, one of the best use-cases for Immunet free would be as a companion to boost Windows Defender's detection-rate!
  18. I stopped using Immunet a while ago due to its unreliability, but had previously been using it since its pre-Clamav, pre-Sourcefire, pre-2.0 days. Virtually the public beginning. I check here periodically to see if things have improved, but haven't reinstalled it yet. I definitely second the option of a commandline version, however before adding any new features or messing with the interface, it's imperative that Cisco/Sourcefire/whoever addresses two show-stopping issues: 1. The relentless bugs - e.g. losing files upon quarantine (inability to restore), the blank alert boxes when the user's locale is set to an Asian language, the myriad update issues that get constantly reported but never fixed, and the serious oversights such as when the devs accidentally got rid of the "ask me" option upon detection. These things all erode confidence in a piece of software with immense power: if it malfunctions, it could let malware through, or even worse, destroy legitimate files itself! 2. Decide whether you can be bothered (or are even able) to develop and support it. Users need to know if this software is abandonware or current, and they also deserve to know whether you have the resources to do it. Over the last decade or so, it's spent a couple of clear periods of time where it seemed distinctly abandoned and unsupported, although the cloud infrastructure seemed to still be online. Even to this day, no one knows what the devs are doing, or if they're even doing anything at all. Devs occasionally pop up on here, seem really competent and helpful, and then mysteriously disappear (e,g, RobT), leaving no official Cisco staff offering support, just enthusiasts like Ritchie doing their best. IMHO it would be better to let Immunet die, and offer no "free" product whatsoever, than to waste your limited resources giving users a false sense of security by continuing to put out a shoddy product. Otherwise, you waste your own resources and actually do your users harm. It doesn't matter if it's free, you should either put out an acceptable product or divert your resources to your paid products such as AMP. It does far more harm to put out a bad free product than no product at all. Even if it's free, it should still work. If you can't put out something good for free, then don't. It'd be better for you and the users, to just charge people for AMP or revive Immunet Plus. For goodness' sake, please either cure Immunet or put it out of its misery once and for all. The new features, new UI, new logs etc. are too many steps ahead. Until you fix Immunet's 2 core issues, they're just wasting time on unnecessary fluff.
  19. I can't really test properly as I stopped using Immunet a few months back due to its sheer bugginess - can't complain, Immunet's offered gratis, so obviously Cisco can't devote many resources to it... however I did make a fresh install recently to test, and found this exact behaviour. I couldn't trace it, but it does remind me very much of the excessive hard-disk access problem that was so difficult to pin-down it went unfixed for a couple of years, around version 2.0/3.0. As a bit of background: lots of users at the time reported their hard-disks being thrashed mercilessly, especially after Immunet had performed a full or custom scan. It would bring their computer to its knees, slowing everything to a complete crawl. The only users who didn't notice this problem were the (at the time) lucky few who could afford SSDs, as the increased disk performance was masking the problem. It turned out to be an issue with Immunet constantly updating/changing its history database (I think it's an internal cache of scanned files, so that it doesn't re-scan known clean files). Basically the way Immunet was handling this file was extremely sub-optimal or buggy. So the ironic thing is that performance was being severely reduced by a feature that was supposed to be an efficiency-improver! From what little I could tell, the current performance issue appears to be in the same area, although it looks as much CPU as disk-related now. With regards to running Immunet with just the ClamAV module... don't. If cloud-lookups are working, great. If they're not, you're relying solely on a signature-based detection engine with a detection rate of about 20% (own tests, sample of ~200 malware samples, ranging from about 2 years old to the present day, with last ~50-100 being current in-the-wild threats). Use Windows defender until cloud lookups are working again. Or at least complement it with something like OSArmor or Voodooshield. (Or if you're in the mood to tinker, write a batch file that uses curl (now part of Windows) to fetch the latest Sane Security and SecuriteInfo databases, stops Immunet, copies the files to the ClamAV dir, and restarts Immunet - This will give a static detection rate approaching that of something like Kaspersky, but of course won't have the latter's sophisticated system-watcher/behaviour blocker etc).
  20. Hi guys, if my solution doesn't work for you it's precisely because you're not doing it as the very first thing on a completely fresh installation. I always completely remove Immunet, say "no" to keeping all data, reboot and do a fresh install. I've only ever had problems when upgrading Immunet via the GUI so I just never chance it any more. Sorry, I forgot to make that bit completely clear.
  21. It could also be that Immunet has trouble with Asian fonts. I note OP's locale is "jp-JP", and I remember a while back a Chinese user was reporting blank alert boxes too. Might be worth testing in a VM with the language set to CN/JP/KOR and see what happens.
  22. It has caused all manner of havoc for many Windows users I know. On any Windows boxes I manage for friends/family, and my one Windows box I keep at home, I defer all non-critical updates for as long as possible. This is the only way to have a remotely stable experience with Windows 10, without having it constantly break and require fixing. I don't know if the setting is available in Windows 10 Home, but it's definitely there in Pro, which might explain why your Pro box is fine but your Home one is bricked. If you delve into the settings app, and go to Windows update, go to the advanced settings. From there, you can see that there's an option to defer "feature updates" for x number of days. I set this to the maximum, 365. Security updates will still happen as usual, but new features (the less-tested things that usually break people's computers) will have a year to be bug-fixed before rolling out to your machine. It's the best of both worlds. You have a stable computer but you also have all the latest security patches. You can also tell Windows update to pause all updates for up to 35 days. This might be a useful setting to use when you know a large feature update is coming to Windows. That way, you have a chance to see if it's bricking everybody else's computer before it rolls out to yours. The downside of this of course, is that your box will be unpatched for 35 days. I liken an out-of-the-box Windows 10 installation to Debian Sid. It's unstable bleeding-edge beta-testing software, which can and will break... and you're the guineapig. Defering updates makes your Windows 10 installation more like Debian stable. You don't get the latest, fanciest features, but you can rely on it to just keep going and going. So that will hopefully avoid the problem in the future, but what do you do now to solve the instability? Well, one of my work colleagues wasted his whole evening trying to fix his home computer, and told me nothing worked. It remained unstable with broken drivers, broken features etc, even after he rolled-back the update. In the end, he gave up and reinstalled Windows from scratch.
  23. Do you mean Immunet detected a Google update as a threat? If it's a genuine update triggered by Google's auto-updater for Chrome (or whatever) I think it likely to be a false-positive; however due to their monopoly, and the tight integration of their services contributing to "vendor lock-in", not to mention Google's Surveillance-Capitalism business model, it would be healthy to consider alternatives to Google's services. Competition is a healthy thing. Any competition that can exist outside the surveillance business-model is an essential thing. ----- ATTENTION MODERATORS: As this is an Immunet forum, I don't know if the text below this line is acceptable, it's just intended to be helpful. ----- For browsers, I recommend Mozilla Firefox and Vivaldi (both check HTTPS certificate revocation correctly, whereas Chrome trades security for speed and doesn't - or at least didn't last time I checked). For maps, check out OpenStreetMap (for the UK it seems to be a bit more up to date/accurate, but you don't get street view or realtime traffic info). For e-mail, try ProtonMail, Tutanota, or others. For search, maybe Duckduckgo or Qwant, both of which provide results of at least equal quality to Google, for my purposes. For an app-store, try F-Droid. For cloud storage, find a provider of a Nextcloud instance, and perhaps even encrypt your files end-to-end using Cryptomator. Cryptomator also works with other cloud storage (e.g. Dropbox, Google Drive).
  24. I noticed that I get the "not updated" status on a fresh install until I manually perform a scan (even just a "flash scan" will do - and it only takes a minute or two). Even after manually updating Immunet, I noticed that closing and re-opening the GUI (or restarting the computer) resulted in the "not updated" status. The only way to fix it was to update then scan. On every machine I've tried so far (all some variant of Windows 10), the following seems to fix it: 1. Open Immunet GUI 2. Manually check for updates. Wait a few minutes, to give the ClamAV database a chance to update, then close the update dialog. 3. Now run a flash scan (or full scan, but beware a full scan can take hours whereas a flash scan only takes minutes). It seems as if forcing an update then forcing a scan resets Immunet's indicators and it all works again.
  25. Hey all, For a more "generic" way to start/stop Immunet, you can do the following (possibly only works in Windows 10, I haven't tried on earlier versions * ) : Stopping Immunet From the command line: wmic service where "name like 'Immunet%'" call stopservice or from a batch file: wmic service where "name like 'Immunet%%'" call stopservice (Re-)Starting Immunet From the command line: wmic service where "name like 'Immunet%'" call startservice or from a batch file: wmic service where "name like 'Immunet%%'" call startservice The advantage of these is you don't need to know what version of Immunet you're using, so you don't need to work out the new service name after upgrades or edit any scripts you have. I have a custom script that downloads some of the Securiteinfo, Sanesecurity and RFXN custom databases, stops Immunet, copies them to Immunet's "ClamAV" dir, and restarts Immunet. By identifying the "newest" ClamAV dir and using the more-generic way of stopping the service, my script doesn't need editing every time Immunet upgrades. For my case, this increases Immunet's static file detection rate from about ~75% to >95%. I originally worked this out a while ago because I did a couple of upgrades where the Immunet service changed name from something like "ImmunetProtect" to "Immunet 6.0.4" --- * I don't know much about Windows as I've been primarily a Unix/Solaris/GNU-Linux user for both work and play since the late 1990s. I only maintain a Windows installation for the tuning software that allows me to flash custom maps to my car's ECU.
×
×
  • Create New...