Jump to content

zombunny2

Members
  • Content Count

    59
  • Joined

  • Last visited

  • Days Won

    9

zombunny2 last won the day on November 3 2020

zombunny2 had the most liked content!

Community Reputation

14 Good

About zombunny2

  • Rank
    Advanced Member

Recent Profile Visitors

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

  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.
×
×
  • Create New...