I suggest to add the “source IP” field to indicate where the worm like malware comes from, especially for Ransomware WannaCrypt.

We know that Wannacrypt exploits vulnerability in SMBv1 to spread as worm, so in such scenarios, if the detection alert can have an attribute about which source computer exploits the vulnerability and drops the malware payload, that would be great help to customer locating the source computer. This applies to other worms.

Expected detection from 3rd party AM product

=== Event Details ===
Event ID: 147613895128
Start Time: 21 Sep 2017 10:25:47 CST
End Time: 21 Sep 2017 10:25:47 CST
Manager Receipt Time: 21 Sep 2017 10:26:38 CST Generator Name: Virus - Virus Propagation Host
Priority: 8
Correlated Event Count: 1
 
Attacker Host Name: CNXXXXXXXX
Attacker Address: 10.140.159.173
Attacker User Name: cnXXXXXX
Target Host Name: ACXXXXXXX
Target Address: 10.143.17.210
Target User Name: appXXXXX
 
File Name: G:\public\anna liu\UltraEdit\KeyGen.exe
 
Name: Unwanted program, clean error, deleted

Hi all,

I found two strange things in the 'Antimalware overall status and history' SCEP report.

The first (Overall Endpoint Protection status and history part):
(q1a.png, q1b.png, q1c.png included)
The problem is that when the daily data goes to the historical table the ‘inactive’ and the ‘not installed’ counters will be the same. For instance, if I have 50 inactive clients they will be represented as with 50 ‘not installed’ too. Or customer was nerves about this statistic, because no machine can go into the production network without SCEP, but they see lots of ‘not installed’ in the report. This bug was in the first SCCM 2012 R2 build to, and the current branch is affected as well. If you see the screenshots you will found out that in the q1a the client count is more than 300 but in reality the customer has 300 clients only, and the ‘inactive’ and the ‘not installed’ rectangles are always same, you can follow this in the q1_c.png easier.

The second (Definition status on computers part):
(q2.png included)
The other oddity is with the signature updates. There was an issue with the new firewall of our customer and the SCCM server could not connect to MS Update sites to download the new SCEP updates. The clients should go to the red zone (‘From 3 through 7 days’ state) but most of them stayed on the Current status…
I made some drillings into the report and the SQL tables (yes, not supported…) and find out what the problem can be.
I made the SQL query below, and exported the Current state to an excel sheet, then the two dataview were vlookuped.
SELECT VRS.Name0
,VRS.Active0
,VCC.ClientActiveStatus

    ,AVS.LastMessageTime

    ,AVS.LastMessageSerialNumber

    ,AVS.Enabled

    ,AVS.Version

    ,AVS.ProductStatus

    ,AVS.AntivirusSignatureUpdateDateTime

    ,AVS.AntispywareSignatureUpdateDateTime

    ,AVS.AntivirusSignatureAge

    ,AVS.AntispywareSignatureAge

,datediff(day,AVS.AntivirusSignatureUpdateDateTime,GETDATE()) 'Days after last contact'

    ,AVS.AntivirusSignatureVersion

    ,AVS.AntispywareSignatureVersion

FROM EPAntimalwareHealthStatus AHS
inner join VRsystem VRS on AHS.MachineID=VRS.ResourceID
inner join vCH_ClientSummary VCC on VRS.ResourceID=VCC.ResourceID
order by VCC.ClientActiveStatus,VRS.Name0

The problem is that the computer said the update age not the SCCM counted from the last reported(!) update time and the current date. Because it doesn’t do it, I found a machine which has a broken SCCM agent who could stay the machine account in active state but the SCEP part could not report anything.
So according to the client the 1.229.385.0 signature was up to date, but the 1.245.140.0 was the last.
The other less bad scenario that some clients report they are on Current and they sent it with the last status updates 2 days ago.
Summarizing if the client could be on active state the report will show what the client says but I think the SCCM server should count the reported update intervals from the real current date and the last update date because the clients are always lying … :o)

Best regards, M

Almost every AV product I have ever worked with gives the administrator/user a configuration choice to scan All Files or just "at risk" or "common" file types (real-time or scheduled scan). McAfee and Symantec products for example clearly have this option. I have found using that configuration simplifies configuration and reduces the likelihood of problems with performance or breaking other applications. For example if a vendor says "don't scan our X folder with AV" that problem is usually a non-issue if those file types in folder X are not in the list of "common" programs or "common" data file types.

i.e. only scan (scheduled or real-time) at-risk files like COM, BAT, CMD, DOC, DOC?, DOT, DOT?, EXE etc. etc. etc.

This feature is in almost very other AV product in existence. It saves admins like me hours and hours of time, as well as headaches or downtime for end users who stumble across issues caused by AV touching files we need to be excluding.

This is going to make our migration away from SEP to SCEP was more time consuming than I had hoped.