We would like an information channel, where MS disposes information on the behavior of the Endpoint Protection product. Especially when things change but also how things are now (logic, build-in defaults, parameterization and how to configure, etc...).
E.g. : We recently had a 'false positive' Worm:Win32/Bluber.A detected in C:\Windows\System32\sysinfo.ocx file. In this case, we chose to 'quick fix' this issue by performing a 'Restore files quarantined by this threat' (see picture). This action creates an exception rule for the detection and remediation of this particular threat, on the SCCM EP GPO. This exception is only temporary; it used to be valid for 7 days. However, this was changed! Now, the releases of the DAT files make out when this exception expires. The precise details seem to be known only by product DEV team. Hence, an info channel , used by MS to volunteer this kind of information (and other significant changes) would be most useful. Why? For defining a precise action plan (timing!), in case of a false positive or a real virus outbreak as well. "What is the full potential of the tools at our disposal?" In my opinion, precise and detailed answers to this question is most 'key'.

In the client Policy for SCEP we have "Auto Sample Submission" turned on as the default. However this only works for some files that are suspicious. There are actually two other levels of Sample Submission that can only be obtained by changing registry values and pushing out these settings as a script via SCCM, or GPO. Would love to have these exposed through the GUI.

Talking about these settings:

Problem:
SCEP is prompting for submission of suspicious files when in policy "Auto Sample Submissions" are enabled. Trying to find out why we are getting prompts.

Resolution:
I received and reviewed your log files, specifically, the MPRegistry.txt file to determine how you have MAPS configured and found the following:

[SpyNet]

SpyNetReporting                          [REG_DWORD]    : 1 (0X1)

SubmitSamplesConsent              [REG_DWORD]    : 1 (0X1)

Per our February 2015 update, here are the values and descriptions:

MAPS Configuration
Registry location:
HKEYLOCALMACHINE\Software\Policies\Microsoft\Microsoft Antimalware\SpyNet
DWORD name: SpyNetReporting
DWORD values:
0 – Off
1 - Basic Membership
2 - Advanced Membership

Sample Submission
Registry location:
HKEYLOCALMACHINE\Software\Policies\Microsoft\Microsoft Antimalware\SpyNet
DWORD name: SubmitSamplesConsent
DWORD values:
0 (default) – Automatic sample submission disabled. End-users will always be prompted for samples.
1 – Most samples will be sent automatically. Files that are likely to contain personal information will still prompt and require additional confirmation.
2 – All sample submission disabled. Samples will never be sent and end-users will never be prompted.
3 – All samples will be sent automatically. All files determined to require further analysis will be sent automatically without prompting.

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

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