ENS Exploit Prevention - "Suspicious Double File Extension Blocked" Signature Still Be

[Former Member]

Hey Nick,

Just sending you a private message with a suggested template.

[Nick_B]

Hi guys,

Many thanks - I received an email from Cara which I've taken a look at.

Hopefully, I've understood it correctly! 

Can I just ask - in my ENS_AP_Rules.dat file for example - there is nothing listed in the "Rule  {" section at the top (for Rule ID 413) whereas in the example one that was sent across it has 12 lines of code in the "Rule {" part, starting with "set os_major_version [iSystem Major]" and another 11 lines after that. If those lines are not already included in the customer's ENS_AP_Rules.dat file, do they need to be copied into the file anyway?

Thanks for all your help, it is much appreciated!

Speak soon 😉

[Former Member]

Hey @Nick_B 

🙂 no worries at all.

And absolutely correct.

[Nick_B]

Hey Hey Hey @Former Member 

Brilliant, thanks again!

I've replied to the customer explaining what needs to be done, so hopefully we've cracked it this time.

If I don't speak to you before, have a great weekend 😉

[Kenchee_etf]

Hello @Nick_B 

Whenever you have the issue with 413 signature being triggered over the something that is legit on customer's end, procedure is to:

01. Disable 413 signature completely because this signature examines the target executable value and only the source executable can be excluded aka ENS is not able to exclude the target. Also this being default McAfee provided signature it is not possible to make any modification of it.
02. Open SR with Support.
03. To address this issue, the Support will assist you in creation with an expert rule that has the same syntax that is used by the current 413 rule where you should be able to add exclusions for the filename or folder location that needs to be excluded.

"Disable 413 and replace with expert" is the proper and the only supported way to do this where I am not familiar with anything that possibly involves ENS_AP_Rules.dat file.

I hope this helps.

[Nick_B]

Hi @Kenchee_etf 

I see, thanks for the clarification on that.

I received a template from one of your colleagues last week, around creating the Expert Rule and I've provided the information to the customer so he can replace the 413 Rule on the affected system(s).

He hasn't replied as yet so I don't know whether he has even tried to create the Expert Rule.

Your colleague did explain that under normal circumstances it was best to raise a SR.

I'll let you know the outcome when I hear back from the customer.

Thanks again!

[Nick_B]

Hi @Former Member , @Kenchee_etf ,

How are you guys keeping?

I just had some feedback from the customer to say that the Expert Rule worked!

He did have a couple of questions however, which I'm including here and would welcome your comments:

The customer is asking what the below command means (the part setting the environment variables) and whether it is necessary to put it in? Personally, I wouldn't have thought the Expert Rule would function correctly without these elements! I'm not including the entire command here due to the need to retain its confidentiality but essentially it is the top 4 lines as seen below and the four set WOW64_HKLM lines from the code block.

Also, he notes that "I don't see -v C:\\<filename> excluded in rule 413". By this I assume he is referring to the existing in-built 413 rule. If so, then that would not be listed anywhere in the default, in-built rule I wouldn't have thought.

Rule {

set os_major_version [iSystem major]

set os_arch [iSystem os_arch]

if { $os_arch == 320 } {

set WOW64_HKLM_ProgramFiles_32 [iReg value "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion" ProgramFilesDir]

...

...

...

}

I look forward to hearing from you guys!

[Kenchee_etf]

Hello @Nick_B

If you take a look at:
*** Logging environment variables
https://docs.mcafee.com/bundle/endpoint-security-10.6.0-threat-prevention-product-guide-windows/page...

You will see that your assumption is correct about environment variables and, as you already know, there are slight differences between 32 and 64-bit OS.

Unfortunately, I don't have any additional public documentation to provide for your to forward to your customer, where the fact that Engineering defined the rule the way they did should be sufficient to leave it as is.

Now, can your customer decide to modify it?

They may do what ever they want in their environment, however, let them know that modification outside of what is given will not be supported, it is not tested and we don't know potential results and if they break their machines it is on their own convenience. Also it is important to set the expectation that some of the questions may not be answered due to proprietary nature of those answers.

As for -v C:\\<filename>, it is expected not to have this included in built-in rule that comes as the default.

I hope this helps.

[Nick_B]

Hi @Kenchee_etf 

Thanks for this, I'll just make the customer aware about this and I'm sure he'll understand!

Take care 😉

[SWISS]

The DOUBLE File Extension IPS is very important these days. We had so many discussion with several people at Mcafee and they don't understand that their rule is faulty and generates a lot of False/Positive. I mean if the rule BLOCKS the batch NSTALL_APPV_CLIENT_4.6_SP2.CMD

where is the DOUBLE EXTENSION there?

SP2 and CMD?

Complete fail!

Look what they told us:

1) Disable rule 413

2) Click on "Add Expert Rule" button. Copy and paste below rule in Rule content window (and set it to type: Process, with severity high, and block and report enabled)

3) Add excludes at the bottom below -v **INSTALL_APPV_CLIENT_4.6_SP2.CMD

Then on a brand new dell:

NEW DELL Modell w10 WITH gfx Card Driver not working with

ENS 10.6.1 at OTHER Mcafee Customer (15 years Mcafee customer)

DISPLAYLINKCORE64.EXE

Module Name:	Threat Prevention
Analyzer Content Version:	10.6.0.8701
Analyzer Rule ID:	413
Analyzer Rule Name:	Suspicious Double File Extension Execution
Source Process Signed:	Yes
Source Process Signer:	C=GB, S=CAMBRIDGESHIRE, L=CAMBRIDGE, O=DISPLAYLINK, CN=DISPLAYLINK
Source File Path:	C:\USERS\FZ\APPDATA\LOCAL\TEMP\DL2.TMP\NIVO
Source File Size (Bytes):	12841176
Source Modify Time:	11/13/18 10:49:07 AM CET
Source Access Time:	11/13/18 10:56:11 AM CET
Source Create Time:	11/13/18 10:49:19 AM CET
Source Description:	DISPLAYLINKCORE64.EXE /EXELANG 1031 ALLOW64BIT=YES DL_NO_EULA=YES DL_PRODUCT_NAME="DISPLAYLINK GRAPHICS" DL_BRANDING_UPGRADE_CODE="{78A36ACD-80D5-490F-B4C4-83D7FCC08391}" DL_BRANDING_PRODUCT_CODE="{5DA8E5C0-4B7C-4238-94AE-E766DFB3D3B4}" DL_BRANDING_CAB="C
Target Hash:	74f4dba463d237a1d294926071bdddf6
Target Signed:	No
Target Name:	EXED413.TMP.BAT
Target Path:	C:\USERS\FZ\APPDATA\LOCAL\TEMP
Target File Size (Bytes):	310
Target Modify Time:	11/13/18 10:56:11 AM CET
Target Access Time:	11/13/18 10:56:11 AM CET
Target Create Time:	11/13/18 10:56:11 AM CET
First Action Status:	Not available
Second Action Status:	Not available
Description:	PENTAAG\fz ran DISPLAYLINKCORE64.EXE, which tried to access C:\USERS\FZ\APPDATA\LOCAL\TEMP, violating the rule "Suspicious Double File Extension Execution", and was blocked. For information on how to respond to this event, see KB85494.
Duration Before Detection (Days):	0
Attack Vector Type:	Local System
Access Requested:	Execute, Read