This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Execute remote command through AutoUpdate

Hi everyone,

in a recent analysis of a ransomware attack, where BitLocker was used to encrypt the disk, I found that the company was using Sophos.

In the folder C:\10577-Sophos\AutoUpdate\data\warehouse, I found some files with XML extension that contain executable code and activate BitLocker, using a command like the following from disk A: to Z:

manage-bde -on F: -rp 599368-358941-467368-368093-397672-261921-132506-522577 -sk C:\ -s

I'm not really into Sophos management and administration, but I read that the folder warehouse can be use as a cache for the update installations.

 

Is it possible that the attackers abuse this Sophos functionality to execute remote command activating BitLocker on the remote host?

 

 

Regards,

Matteo. 



This thread was automatically locked due to age.
Parents
  • Hi  

    It is very difficult to confirm if Sophos was "abused" or not but from my experience, I have not seen anything similar and I believe that this is not possible. Having said that, we will need to conduct a full investigation and confirm things like the Sophos products used in the infrastructure, the policy settings, GPO settings, etc. to come to a conclusion.

    I would request you to get a support case opened by visiting the following link for more details regarding this - support.sophos.com. You can PM me the ticket number so that I can follow up on it if required.

    Thanks,
    Yashraj Singha
    Manager | Global Community Support
    Are you a Sophos Partner? | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question, please use the "Verify Answer" button.
    The New Home of Sophos Support Videos!  Visit Sophos Techvids
  • Hi Yashraj,

    thank you for the answer.

     

    In order to give you more evidence, I'll attach some files that I found under C:\Sophos\AutoUpdate\data\warehouse.

    If you are able to give me more information I'll be very grateful. Otherwise, I'll manage to request a support case as you said.

     

    Any information about the files would be very useful.



  • Hi  

    I'd recommend you open a support ticket to leave no stone unturned in the investigation. Please visit the following link - support.sophos.com. To expedite this, I'll be sending you a PM to get your contact details.

    Thanks,
    Yashraj Singha
    Manager | Global Community Support
    Are you a Sophos Partner? | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question, please use the "Verify Answer" button.
    The New Home of Sophos Support Videos!  Visit Sophos Techvids
  • Hello Matteo and Yashraj,

    this seems strange.
    First of all, is the path really C:\10577-Sophos\... or C:\Sophos\...? Should be C:\ProgramData\Sophos\....

    AutoUpdate does not execute anything from the warehouse, the XML files contain only metadata and no executable code. A file's name is its MD5 with a suffix and the consistency of the warehouse is checked using hashes.

    Furthermore - there are fragments of alc.log (that's under %ProgramData%\Sophos\AutoUpdate\Logs\) at the end of the file that suggest that the on.premise SESC was in use in May. It likely has been replaced with Central as the fragments suggest successful updates from a UNC share and a warehouse is only created when the endpoint updates from Sophos. As said, these fragments are from May.

    All in all pretty weird and as Yashraj has said this requires in-depth investigation.

    Just my two cents.
    Christian

Reply
  • Hello Matteo and Yashraj,

    this seems strange.
    First of all, is the path really C:\10577-Sophos\... or C:\Sophos\...? Should be C:\ProgramData\Sophos\....

    AutoUpdate does not execute anything from the warehouse, the XML files contain only metadata and no executable code. A file's name is its MD5 with a suffix and the consistency of the warehouse is checked using hashes.

    Furthermore - there are fragments of alc.log (that's under %ProgramData%\Sophos\AutoUpdate\Logs\) at the end of the file that suggest that the on.premise SESC was in use in May. It likely has been replaced with Central as the fragments suggest successful updates from a UNC share and a warehouse is only created when the endpoint updates from Sophos. As said, these fragments are from May.

    All in all pretty weird and as Yashraj has said this requires in-depth investigation.

    Just my two cents.
    Christian

Children
No Data