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 

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..

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..

Adaptive Attack Protection shouldn't be causing extra work if it's not invoked.

Some details: https://support.sophos.com/support/s/article/KBA-000008632

it's an extra set of behavioural rules that are enabled as needed.   .

You can manually enabled it for a period of time if you suspect the computer is compromised:



I suspect it was the act of rebooting rather than those features.

I would run:

wpr.exe -start GeneralProfile

Leave that running for 1 minute before running;

wpr.exe -stop C:\trace.etl


and review with Windows Performance Analyzer. 

have you execpted the folders and processes that MS wants?

https://learn.microsoft.com/en-us/exchange/antispam-and-antimalware/windows-antivirus-software?view=exchserver-2016

it's quite a huge list so it´'s possible, that not all items have been excluded.

Have no performance issues with Exchange and Sophos Endpoint.

ok, i am using the automatic exclusions. so it´s better to create the exclusions manually from that list?

Yes. Exchange is not included in the auto-exceptions https://support.sophos.com/support/s/article/KBA-000003338?language=en_US

a snip of such exceptions.

in the end, Sophos will not "know" much of what Exchange is doing but the OS is protected and commands run by admin accounts etc. are monitored.

OK, strange, look at this?

just a Snippet..

i have no problems over years, started on friday...

If auto-exclusions are on in policy, it will see that the uninstall key for certain products, like Exchange, SQL Server, are installed and add some basic exclusions.

It's not clear to me where the work is coming from, only something like an ETL trace will tell you in significant enough details if you can capture the high CPU usage.

I've overlooked that Exchange IS on the list in the auto-exceptions. my fault.

So you need to compare them with the list from the MS Exclusion article and then follow Sophos User930 s suggestions to monitor the behavior. be sure, to let is monitor only for a short time on the server - may cause lot's of logging and may flood your disk.

ok, but does we need also AMSI exceptions or does you know is there a list for AMSI?

i will adjust the policy now with the missing one

you said, the issue appeared suddenly. After a sophos program update?

eventually, Sophos has unintendedly rolled back fixes mentioned here?

support.sophos.com/.../KBA-000007760