Sophos Free Tool

[Elia Khensamphanh]

areyou referring to a specific issue?

The Windows Installer is used for installation and consequently it's the tool to uninstall. It should remove all active components, registrations, and system modifications. A few items might be left behind (IIRC used to be used upon a reinstall of a managed endpoint) - naturally "unknown" content (i.e. something put into a Sophos folder by a non-Sophos process or the installer) is preserved.

One common cause for "issues" is the removal of the cached .msi from \Windows\Installer\, and an upgrade fails because the previous version can't be uninstalled without it. The tool in this case would be the previous .msi (guess you could get this from Support if you have no other means).

Corrupt Sophos Endpoint Client

always the question how this comes about.

"Wipe" tools can't expect the unexpected. If they can get the system from an unknown state to a consistent and clean one - why not using them in the first place or design the regular uninstall so that it can handle pathological cases? Even as they appear to be able to clean up the mess they have to be used with care (a prominent example is the former msicuu2.exe now replaced by the Fix-It for install/uninstall problems). There's the danger that such tools are used indiscriminately (Symantec themselves display a warning on the CleanWipe page - use as a last resort).

A tool is undoubtedly convenient but in most cases I have experienced (in a dozen years with several thousand endpoints) it's not necessary - and at best it doesn't induce other issues. Perhaps I'm an antediluvian* but I believe analysis and specific correction are the better course of action.

So I decided to have a meeting in London a few months ago with @sophossecurity and it literally blew my mind. They showed me how easy it is for cyber criminals to hack you - but also how easy it is to stop those trying to get to you.

I have scoured all I can and looked through the log files, but I am admittedly naive when it comes to determining what could even be the root cause for this. We've been using the tool for over a month now to migrate clients and this issue just started on Monday.

Can you please confirm me if you still facing the issue? We have recently completed a change over to a new CDN supplier in order to increase the reliability of our content delivery systems. This migration completed for all addresses on the 2nd May 2018 as described here.

Sophos does not recommend whitelisting CDN IP addresses as the range of IP addresses that are presented on the URLs is subject to change. With the previous CDN, there was a set range of addresses that customers could exclude. However, with the new CDN supplier, customers will need to identify IP addresses to then exempt.

Open a web browser and enter the following three addresses into the address box. If a successful connection is made you will see the message "it works - authed", "Connection Successful" or "it works".

Thank you for your reply and description of the issue. Unfortunately, I can get to all of the links you listed above, but the tool is still showing that it is unable to download the latest cloud readiness assessment data. The Windows firewall is actually off on this box, so I don't think that is an issue. Lastly, there are no proxy's running on my connection.

Please give a try to the KBA Sophos Cloud Migration - Windows 2003 root certificate not installed. If the KBA doesn't resolve/ Apply to your environment, please collect the below logs and contact our support.

1) Install Wirehshark from www.wireshark.org

2) Capture the traffic of the network adapter used by the DBArchive Server to connect to the Sophos Cloud

3) Reproduce the issue of the Sophos Migration Utility

4) Save the wireshark log with the extension pcapng and compress it

5) Create a new SDU Log for us to investigate.

6) Send the SDU and the Wireshark Log to us.

I have managed to migrate 96 PCs and then it has stopped with the error message described. It stopped a month ago with Problem downloading latest cloud readiness assessment data displayed at the bottom of the migration tool

Did you make any progress on this? I am seeing the same thing on a 2012R2 server which definitely is not a 2003 server and has the latest updates on and checking those three urls above see them as valid certificate chains

There is obviously an issue here, but I haven't heard any more out of Sophos on a fix. We're resorting to a GPO deployment, which was also a nightmare because there is no official sophos MSI. Good times..

I was also running this on Server 2012R2. After speaking to Sophos, I understand there is a version 2.0 of the Migration Tool being released soon. Maybe to fix this issue? In any case, this was enough to persuade me to cease my trial of Sophos Central and go in a different direction. Hope they find a fix for you guys soon.

Thanks both for that; that not very clever that they have updated the server but have seemingly hardcoded the fingerprints of the SSL certificates of the old servers into the tool so it is then throwing a wobbly claiming it thinks it is subject to a man-in-the-middle attack! I am not surprise it looks like the copyright dates on the current v1.0.1 tool are back in 2016.

The stupid thing is they also look to have hardcoded the Central supported feature sets at the point of compiling it which appear to have changed in the intervening period blocking 90% of the machines in the environment I am trying to migrate from being seen in a migratable state. :-(

Oh and to compound the issue in the case I'm working on Enterprise Console has stopped downloading updates as they have expired the credentials so I have the account manager trying to get some backend licensing team to set them working again!

After having many issues with attempting various forms of Sophos Client removal, I decided to attempt to write my own removal script\tool. This tool will close all Sophos related tasks, stop all Sophos services, and then search the 32 and 64 bit registry hives for the uninstall strings. The strings are passed to variables that enforce the silent removal of the various portions of the Sophos products. Then, the Sophos directories in Program Files, Program Files (x86), and ProgramData are removed, and all related services are deleted.

Please feel free to use, share, and update the tool as you see fit. It may not be perfect, but in our environment it definitely has been getting the job done. I hope this helps all of you who are having issues with the removal of the Sophos Client!

I know exactly the pain you are talking about. That is exactly why I created this script and exe tool; I got so fed up that I just kept pounding away until I came up with something that jsut worked. Give this a shot, and if it works out for you let me know. I am open to making any and all changes needed, or you can grab the powershell code and tweak it till it works for you. Just give me props if you modify the code and release it as your own haha!

I understand that Sophos development are currently working on an official removal tool for cases where the regular uninstaller (as run from Programs and Features) does not work successfully or only partially. It's not going to be designed to bypass tamper protection but is designed to clear out anything that can prevent a successul re-install.

BYOVD (Bring Your Own Vulnerable Driver) is a class of attack in which threat actors drop known vulnerable drivers on a compromised machine and then exploit the bug(s) to gain kernel-level privileges. At this level of access, attackers can accomplish a lot: hide malware, dump credentials, and, crucially, attempt to disable EDR solutions.

Another possible reason for BYOVD becoming popular with lower-tier threat actors is that off-the-shelf kits and tools are now bought and sold on criminal forums. One in particular attracted a significant amount of attention in May 2023, when a threat actor known as spyboy advertised a tool called Terminator on the Russian-language ransomware forum RAMP. The seller claimed that the tool, priced between $300 USD to $3,000 USD, could disable twenty-four security products.

Even multiple months after the initial discovery, the drivers are still a popular topic in darknet forums. For instance, we discovered the following November 2023 post on a Russian-language criminal forum:

On September 13, 2023 and October 10, 2023, Sophos thwarted attacks which both used very similar methodologies. In both cases, initial access was likely obtained via exploiting a vulnerable Citrix application. From there, the attackers injected a payload into the Windows Error Reporting process, wermgr.exe. Next, they tried to disable Sophos by issuing the following commands:

Tamper protection was enabled on the targeted devices, so the attempts to simply disable and remove the Sophos services failed. Finally, the threat actor switched to deploying an EXE file named ter.exe. The binary unpacks itself to a slightly modified version of Terminator. The driver itself was dropped separately before this.

On December 15, 2023 we blocked an attack targeting a healthcare organization. Immediately after initial access, the attackers attempted to execute a PowerShell command to download a text file from a C2 server.

Later, the threat actors tried to disable the EDR client via running ternimator, the Nim version of Terminator, on one of the infected machines. The attempt to load the driver was also blocked by behavioral protection rules.

In this attack, which occurred on Christmas Day 2023, the threat actor gained access to a single machine, although the initial attack vector is unclear. First, they tried to load the Zemana Anti-Logger driver, masquerading as updatedrv.sys, from different locations:

After these attempts failed, they switched to using AuKill, another known EDR killer, where the Process Explorer driver was named ped.sys in the temp folder. We reported this to the customer, and did not see any further detections triggered; we are therefore highly confident that the attack was thwarted.

3a8082e126