How to exclude specific user in ENS TP expert rule ?

[bertels]

Hi,

I was trying to convert some rules from HIPS to ENS.
Migrating it to an Access Protection policy (with GUI), I am able to exclude som users by their ID.
Using the expert rules in exploit prevention, I did not find a way to configure this. 
(The documentation only state something about the SID, but that is really horrible 😉 )
Both rule's are using the AAC, so I expect it should be configurable.

Does anyone have experience with this ?

Example of what I want to accomplish, but is not working:

Rule {
 Process {
  Include OBJECT_NAME {
   -v ** 
  }
                 Exclude USER_Name {
   -v "Domain\MyReadableUserID"
   }
 }
 Target {
  Match FILE {
   Include OBJECT_NAME {
    -v cmd.exe
   } 
                         
   Include -access "EXECUTE"
  }
 }
}

[Daveb3d]

My understanding is that this will need a PER.  I had some exchanges with engineering several months back on how to exclude based upon users and the output was that the old way isn't currently possible.

Dave

[bertels · Accepted solution]

Good news, I got in touch with an engineer and received the following solution:

Include EXP_USER_NAME { -v "MyUserName" }

I tested it and it seems to work.
I am not going to need a PER after all.

[Daveb3d]

Very cool!  

Do you know if this was a new add to 10.6?  

[bertels]

Hi,

I have no idea, but I realy hope that it will work because of 1 important reason.
I read the following in the ENS expert rule syntax:

McAfee Endpoint Security provides information in the EndpointSecurityPlatform_Errors.log file about rules that didn't successfully compile and so were not enforced. Because all Expert Rules are compiled into a single group, when an Expert Rule generates an error, no Expert Rules are enforced.

So if it does not compile/enforce into ENS 10.5.3, no rules will be active there.
If this is true, it will be really dificult to implement new features of expert rules in a corporate environment.
Important to check, if I had not upgraded all my testmachines to 10.6 ... 🙂

[BG]

I implemented this in a rule last year and it worked.  Today it does not.  Test system is running 10.6.1 with November 2018 update.  Is it still working for you?

[cn]

Does EXP_USER_NAME still work?  I tried using it in an AAC Expert Process rule and it did not seem to work for me at all.  I tried it as the initiator and under the target, but whenever I use the account that should trigger it, nothing shows up.  I take it out and it works fine.  Did this get removed in 10.6 or am I simply not using it correctly?  The admin user is something like someadmin1, but when I launch any of the browser processes with the account and even never gets generated unless I remove EXP_USER_NAME from the rule.  Please help

Rule {
Process {
Include OBJECT_NAME { -v ** }
Include EXP_USER_NAME { -v "*admin*" }
}
Target {
Match PROCESS {
Include OBJECT_NAME { -v iexplore.exe }
Include OBJECT_NAME { -v chrome.exe }
Include OBJECT_NAME { -v firefox.exe }
Include OBJECT_NAME { -v MicrosoftEdge.exe }
Include -access "CREATE"
}
}
}

[jess_arman]

@cn Try changing the variable syntax to just USER_NAME and see how it goes as examples I'm finding use that instead of EXP_USER_NAME. 

Here's an excerpt from a previous syntax guide (PD27574) which shows the variable as that and not having the EXP_ part

Rule {
service { Include "Alerter" }
application { Include "*"}
user_name { Include "*" }
directives service:stop
}

user_name { Include
“*” }
Indicates that this rule is valid for all users (or more precisely, the security context in
which a process runs).
To limit the rule to specLfic user contexts, list them using the form Local/user or
Domain/user.

Also, when in the expert rule creation screen, if you have "use Expert Rule template" checked, and select "Illegal API use" as the type, you can see in the example template that the variable is just user_name {Include"*"}

Was my reply helpful?

If this information was helpful in any way, or answered your question, will you please select "Accept as Solution" in my reply, or give kudos as appropriate, so together we can help other members?

[ktankink]

@cn Here is the Expert Rule I used that worked for me.  Chrome.exe is allowed for DOMAIN\USER1, but blocked for DOMAIN\ADMINISTRATOR.

 Rule {
Process {
Include OBJECT_NAME { -v ** }
Include EXP_USER_NAME {-v {domain\administrator}
}
}
Target {
Match PROCESS {
Include OBJECT_NAME { -v iexplore.exe }
Include OBJECT_NAME { -v chrome.exe }
Include OBJECT_NAME { -v firefox.exe }
Include OBJECT_NAME { -v MicrosoftEdge.exe }
Include -access "CREATE"
}
}
}

Basically just executed "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" from a CMD prompt opened by my each domain account (Administrator and USER1).

2/20/2019 5:57:59 PM mfeesp(2020.6192) <SYSTEM> ApBl.BOPAP.Activity: DOMAIN\Administrator ran CMD.EXE, which attempted to access CHROME.EXE, violating the rule "Process block browser by username", and was blocked. For information about how to respond to this event, see KB85494.

I used these variations successfully

Include EXP_USER_NAME {-v {.\user} worked to block a local user account (named "user").

Include EXP_USER_NAME {-v {localsystemname\user} worked to block the same local user where localsystemname is the local computername (e.g., SYSTEM1\User)

I am unable to get it to work with wildcards though.

Did not work

Include EXP_USER_NAME {-v {.\use*}

Include EXP_USER_NAME {-v {localsystemame\use*}

Include EXP_USER_NAME {-v {*\user}

Include EXP_USER_NAME {-v {**\user}

[cn]

Thanks for the response.  This was most helpful.  I was also able to get it to work on specific accounts.... However, I need to be able to wildcard it to pick up certain domain accounts that start with a bb which identifies it as an admin account.  These accounts are AD accounts that uses xccedium to elevate.  I am trying to figure out a way to create a process related alert to track when a user decides to open a browser using this type of admin account. 

I wanted to be able to do something like.

Rule {
Process {
Include OBJECT_NAME { -v ** }
Include EXP_USER_NAME { -v {domain\bb*}
}
}
Target {
Match PROCESS {
Include OBJECT_NAME { -v iexplore.exe }
Include OBJECT_NAME { -v chrome.exe }
Include OBJECT_NAME { -v firefox.exe }
Include OBJECT_NAME { -v MicrosoftEdge.exe }
Include -access "CREATE"
}
}
}

Of course this does not seem to work, which limits my use of the rule.  Is there a better way to block admin privilege browser launches with another match type?

Thanks,

Chris