Testing 8.0 Credential phishing prevention

[dkordyban]

Support says eveything has been setup properly for this to work. How would you test that users would not be able to enter domain credentials into bogus site? 

[mivaldi]

I suggest you create a bogus user with a bogus password and test it.

[dkordyban]

That has been done.

The problem I run into is finding a url to test against. Unless someting is not setup correctly.

Real Example:

User get phish message asking them to fix thier O365 account due to unusual activity.

https://www.tasteofthewild.com.au. PA url filter categorizes as person blogs.

User goes to site and is allowed to put in domain creds.

Looking at URL monitor traffic is decrypted and no cred detected. Site has been SSL decrypted and the personal blogs category is set to block user credentail submission.

Maybe it has something to do with the bloom filters not getting propgated to firewall. Not sure how to tell. I was just hoping to get input from someone else already using this.

[dkordyban]

also this is somewhat confusing (from 8.0 Admin guide):

" The firewall automatically skips checking credential submissions for App-IDs associated with sites that have never been observed hosting malware or phishing content to ensure the best performance even if you enable checks in the corresponding category. The list of sites on which the firewall will skip credential checking is automatically updated via Application and Threat content updates."

Does this mean websites with a good reputation will be skippped from credential submit check , even if I have the category set to block cred submission?

[RyanGates]

Dkordyban,

This must be why it did not work for me. Phishing website was in the education category but it was obivously phishing. I tested it with a phony account and never triggered the Cred check.

Thanks,

RG

[staustin]

I know this thread is a little old, but what groups do you have in your Allowed RODC password replication policy?  I think we may be running into the same issue. @dkordyban 

[dkordyban]

I have domain users in the group. It appears to work for me now. Not sure what changed. Maybe it just needed some more time.

[RyanGates]

Hello,

How did you test to see if it worked?

Thanks,

RG

[dkordyban]

Went to netflix.com and and tried domain creds.

[RyanGates]

I thought it would skip that website. Going to give that a try right now. Also, are you running an SSL decryption profile?

" The firewall automatically skips checking credential submissions for App-IDs associated with sites that have never been observed hosting malware or phishing content to ensure the best performance even if you enable checks in the corresponding category. The list of sites on which the firewall will skip credential checking is automatically updated via Application and Threat content updates."

[staustin]

@dkordybanThe reason I ask is that I hooked up a debugging mechanism to the pan user id credential agent connection between the credential agent and its RODC ldap connection that exists locally on the machine, because credential phishing detection (based on username/password) combo was not working.  If i just switch it to username that would work, but that net is too large.

This is the query that the credential agent runs against LDAP to enumerate users in the "Domain Users" group, assuming that's the one of the groups present in "Allowed RODC Password Replication Group".

(&(&(objectclass=Person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))(memberof=cn=domain users,cn=users,dc=saustin,dc=com))

This query would absolutely work for any group EXCEPT the primary group.  The reason is that enumerating users in the primary group can't be done like this in AD and this query returns 0 user names and thus no credentials would be read via the credential agent for that group. 

I verified this in my lab setup and production.  I then added a random second (non-primary) group to "Allowed RODC Password Replication Group" that exist in my AD forest and bounced the credential agent.  The credential agent was able to enumerate those users and create a bloom filter for them just fine.

You can check the number of credentials sent from the credential agent to the firewall by running this command

I have well over 2000+ users in my AD forest, and currently 500~ passwords cached on the RODC (verified via active directory tools) which is quite a bit larger than 67.  67 is conviently the exact number of users that exist in the non-primary group I added to verify my hunch about the credential agent not properly enumerating users in the "Domain Users" group.

If you're seeing that the credential count for the bloom filter on the firewall corresponds to all the users in your AD, i'd be curious to know what version of the credential agent and user-id agent you're using.

[dkordyban]

netflix seems to always be a good test for us. Yes, we decrypt most traffic.

[dkordyban]

I see. I wasnt aware of that restriction.

thanks

[dkordyban]

Wondering if I could just nest the domain users into another global group then make it a member of Allowed RODC users?

[staustin]

That unfortunately wouldn't work as the credential agent just recursively goes through all groups in the allowed rodc password replication group, then runs a direct ldap query trying to enumerate that group.  The only way to enumerate users in "Domain Users" doing a ldap query is to use (primaryGroupID=513).  I'm trying to raise the issue with my account rep.