sophos endpoint defense software exchange 2016

yes it´s uninstalled, i think it has to do something with enabling MAPI over HTTP. and maybe AMSI?

what protection is behind sophos endpoint defense(sophos system protection service) ? 

kind regards,

sebastian

If you expand it:

If you say that it's the "sophos endpoint defense software" process then that is the "Sophos System Protection Service" service, which is the sspservice.exe:

Is the SSPService.exe using high CPU?

If you disable AMSI in policy (or using the local UI as a test, having disabled Tamper Protection), does the workload go down?

Is this the cause:

https://techcommunity.microsoft.com/t5/exchange-team-blog/more-about-amsi-integration-with-exchange-server/ba-p/2572371

Thanks

yes then the CPU goes down, but i thought this was already fixed in 2021? we are moving to M365 and activated MAPI over HTTP, but i need this mailserver the next 2 month.

maybe i can disable only AMSI on the Exchange with powershell?

But this would be only a workaround..

AMSI is the Microsoft Scanning Interface - https://learn.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal. For processes that load the Microsoft amsi.dll, they will automatically pull in any registered AMSI providers on the system.  There could be multiple but usually for one Security provider you have 1 AMSI provider.

From a Sophos perspective, when AMSI is enabled in policy, Sophos registers their Sophos AMSI provider in the registry:

• For native processes:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AMSI\Providers\{19016286-87D5-4D51-A042-2A9C5CBB8D5F}
  
  The native DLL loaded into the process:
  C:\Program Files\Sophos\Sophos AMSI Protection\SophosAmsiProvider.dll
  
  
• For 32-bit process on 64-bit:
  HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\AMSI\Providers\{19016286-87D5-4D51-A042-2A9C5CBB8D5F}
  
  The 32-bit DLL loaded into the process:
  C:\Program Files\Sophos\Sophos AMSI Protection\x86\SophosAmsiProvider.dll
  
  

A list of processes loading the AMSI.dll could be seen running the following PS:

Get-Process | ForEach-Object {
    $process = $_
    try {
        $modules = $process.Modules | Where-Object { $_.ModuleName -eq "amsi.dll" }
        if ($modules) {
            $wmiProcess = Get-WmiObject Win32_Process -Filter "ProcessId = $($process.Id)"
            [pscustomobject]@{
                ProcessName = $process.ProcessName
                PID         = $process.Id
                CommandLine = $wmiProcess.CommandLine
            }
        }
    } catch {
        # Ignore processes that we don't have access to
    }
}

The issue is, there is no way to say, I want Sophos AMSI enabled for some processes but not others. 

If the AMSI provider is registered in the above registry, then for any process that loads AMSI.dll, the SophosAmsiProvider.dll will be loaded.

The SophosAmsiProvider.dll sends data to be scanned by SophosFileScanner.exe.

To see what is being scanned: In Sophos Endpoint Self Help (ESH), Click on the "Tools" menu, then "Product Logging" on the left. Elevate as required to relaunch the tool. Navigate to "SFS" -> "Scan Summaries" and set that to "Debug" level. ESH will essentially create the DWORD "LogLevel" under "HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\Logging\SFS\Scan Summaries" and set it to 0. So you could just do that if you wanted to do it on a remote computer via LiveReponse terminal for example.

Note: Tamper protection does not apply to the logging registry section.

The SophosFileScanner.exe processes will restart with the new logging configured automatically. After the excessive activity, under: "C:\ProgramData\Sophos\Sophos File Scanner\Logs\" there will be one or more .csv files starting with the file name "summary.". This has the files scanned, the time taken, the reason, size of the file, etc.. You can Delete the "LogLevel" DWORD to disable the logging or go back through the UI of ESH. Excel and pivot might be a good way to sort through the data, the scan type will be asmi in this case, e.g.

#Enable CSV Logging for SFS:
New-ItemProperty -path "HKLM:\SOFTWARE\Sophos\Logging\SFS\Scan Summaries" -Name "LogLevel" -Value 0

#Wait for the work to occur then view the data of the created CSV file in a gridview for filtering and sorting e.g.:
Import-Csv 'C:\ProgramData\Sophos\Sophos File Scanner\Logs\summary.240912163727.211668.csv' | ogv

#Disable the logging.
Remove-ItemProperty -path "HKLM:\SOFTWARE\Sophos\Logging\SFS\Scan Summaries" -Name "LogLevel"

-- 

You can create scanning exclusions for AMSI:



If you put in C:\Windows\SysWOW64\inetsrv\w3wp.exe, for example, then this will prevent AMSI scan requests being sent for that process.

Exchange does have the ability to disable AMSI integration as well.  This is mentioned here: https://techcommunity.microsoft.com/t5/exchange-team-blog/more-about-amsi-integration-with-exchange-server/ba-p/2572371 

I hope this helps.

OK, understand .

First of all , thank you for your help.

But why is there no Automatic Exception for AMSI? Or does anyone has AMSI disabled on PowerShell ? 

As i mentioned this error occurs since we have enabled HTTP over Mapi for all Users .

will try to get some logs ..

kind regards 

OK, understand .

First of all , thank you for your help.

But why is there no Automatic Exception for AMSI? Or does anyone has AMSI disabled on PowerShell ? 

As i mentioned this error occurs since we have enabled HTTP over Mapi for all Users .

will try to get some logs ..

kind regards 

I wouldn’t disable AMSI for powershell. I think I would just create an AMSI process exclusion for w3wp.exe. I believe that should help. 

i just created an AMSI exception for the w3wp.exe like you mentioned. i will check and let you know.

thanks for the moment, as i refreshed the policy the service looks normal at the moment.

are there any other protection features behind sspservice.exe? or only AMSI? 

still some high CPU..

It is the main event processor. It implements behavioral protection so processes all the incoming events to help with this. It doesn’t do scanning, it decides what to scan. For example a process opens a file. The Sophosed.sys driver passes this event to sspservice. One job would be for it to decide if the file needs scanning, if so it makes a request of sophosfilescanner. 

if it’s using high cpu, it must be getting a lot of events. If you enable Info level logging for sspservice.exe in Endpoint Self Help. After some activity check the ssp.log under programdata \ endpoint defense\logs to see the events it is being sent.  Registry/file/ip, etc.. the details should be int be json. 

The LuaTelemetry-*.dat files SSPService.exe maintain might also provide a useful summary of events seen for a sspservice.exe session.  For example, what are the highest events for some of the previous sessions if you run the following in an admin PS prompt or admin ISE window:

dir $env:programdata"\Sophos\Endpoint Defense\Data\LuaTelemetry\" -Filter LuaTelemetry-*.dat | % {
    write-host "Processing:" $_.fullname
    $data = $(gc $_.fullname) | ConvertFrom-Json 
    $event_object = @() 
    foreach ($index in $data.events.perEvent){
        $event_object += [PSCustomObject]@{
            Event = $index.event
            Count = $index.count
            TotalTimeMicroSeconds = $index.totalTime
            TotalTimeSec = $index.totalTime / 1000000
        }
    } 
    $event_object | Sort-Object -Property Count -Descending | Select-Object -First 20 | Format-Table -AutoSize
    Write-host $data.summary.eventCount "events in" $([datetime]::FromFileTime( $data.summary.endTime) - [datetime]::FromFileTime($data.summary.beginTime)) 
}

FileOpen is typically the highest by maybe there are a lot of IP events?

hi,

me again.

i think this must be a special problem, because since monday i have some problems on our DCs as well.

lsass.exe high CPU

disabled AMSI and Adaptive Attack Protection => reboot => CPU normal.

very strange, no changes, no win updates, just sophos did some updates..