topic Re: Testing 8.0 Credential phishing prevention in General Topics

Testing 8.0 Credential phishing prevention

dkordyban — Thu, 11 Jan 2018 21:39:12 GMT

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?

Re: Testing 8.0 Credential phishing prevention

mivaldi — Thu, 11 Jan 2018 22:52:48 GMT

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

Re: Testing 8.0 Credential phishing prevention

dkordyban — Fri, 12 Jan 2018 11:26:54 GMT

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.

Re: Testing 8.0 Credential phishing prevention

dkordyban — Sat, 13 Jan 2018 14:17:31 GMT

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?

Re: Testing 8.0 Credential phishing prevention

RyanGates — Wed, 07 Feb 2018 14:01:36 GMT

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,

Re: Testing 8.0 Credential phishing prevention

staustin — Sun, 22 Apr 2018 14:35:46 GMT

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

Re: Testing 8.0 Credential phishing prevention

dkordyban — Mon, 23 Apr 2018 13:06:25 GMT

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.

Re: Testing 8.0 Credential phishing prevention

RyanGates — Mon, 23 Apr 2018 13:56:15 GMT

Hello,

How did you test to see if it worked?

Thanks,

Re: Testing 8.0 Credential phishing prevention

dkordyban — Mon, 23 Apr 2018 14:11:02 GMT

Went to netflix.com and and tried domain creds.

Re: Testing 8.0 Credential phishing prevention

RyanGates — Mon, 23 Apr 2018 14:27:45 GMT

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

Re: Testing 8.0 Credential phishing prevention

staustin — Mon, 23 Apr 2018 14:37:58 GMT

@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.

Re: Testing 8.0 Credential phishing prevention

dkordyban — Mon, 23 Apr 2018 16:11:28 GMT

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

Re: Testing 8.0 Credential phishing prevention

dkordyban — Mon, 23 Apr 2018 18:21:51 GMT

I see. I wasnt aware of that restriction.

thanks

Re: Testing 8.0 Credential phishing prevention

dkordyban — Mon, 23 Apr 2018 18:27:15 GMT

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

Re: Testing 8.0 Credential phishing prevention

staustin — Mon, 23 Apr 2018 19:14:59 GMT

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.

Re: Testing 8.0 Credential phishing prevention

ArthurEmr — Thu, 24 May 2018 22:01:53 GMT

Hi,

The issue has been raised a little while back. Support for the "Domain Users" group may be ported into 8.0.10 but has not been yet.

Re: Testing 8.0 Credential phishing prevention

Brandon_Wertz — Tue, 26 Jun 2018 17:24:56 GMT

Has anyone made any progress getting this working?

I'm currently in the process of trying to get this deployed in my environment (have an active support case) but am running into a fair amount of obstacles.

We have multiple RODCs in our environment so we created a new RODC just for this purpose. We removed the inherent "Allowed RODC Password Replication" group vice adding to this group as we didn't want to cache accounts globally across the enterprise.

Looks like we're initially being told from TAC that the credential software will only query this inherent group . (which we've removed - FR likely to query something other than "Allowed RODC Password Replication" ) Instead we added "Domain Users" to be allowed to be cached locally on this RODC in question.

We probably have 25,000+ user/service accounts and so far we only have 570 cached account on the RODC post allowing "Domain Users" to be cached.

*EDIT* UIA/Cred software is creating a Bloomfilter that currently only contains 20 user accounts

My AD guys are telling me that the caching process only occurs when the RODC proxies an auth request for a specific account. Apparently you can force the RODC to cache an account, but it's on an individual account basis and can't be done via user/security groups.

*EDIT* Using RODC 2016 - UIA/Cred software 8.0.9-6 (also tried 8.0.8-2)

Re: Testing 8.0 Credential phishing prevention

staustin — Tue, 26 Jun 2018 17:32:14 GMT

Hi @Brandon_Wertz,

There could be a few reasons it's not working. I want to confirm I understand you correctly first. Are you saying that you removed the "allowed rodc password replication group" from the password replication policy tab of the RODC? And then you replaced it with "Domain Users" and set it to allow in the password replication policy tab of the RODC?

The first reason this doesn't work is because the PAN credential agent cannot enumerate users in "Domain Users". The reason it can't do it is because "Domain Users" is a special AD object and the credential agent does't form the ldap query properly. In addition to the aforementioned issue, I don't know if the credential agent will query any group that's not in "allowed rodc password replication group" (this is a conjecture as i've only nested groups in "allowed rodc password replication group". The second part may not be a contributing factor.

What I had to do to get it working is as follows:

1. I created an AD object called allmyusers and added all user accounts to the group.

2. I added allmyusers object to "Allowed rodc password replciation group"

3. Bounced the pan userid and credential agent

Until PAN fixes the issue, "Domain users" will not work and you have to create a different group that essentially does the same thing but isn't the build in "Domain users" group.

Re: Testing 8.0 Credential phishing prevention

Brandon_Wertz — Tue, 26 Jun 2018 17:41:20 GMT

@staustin wrote:
Hi @Brandon_Wertz,

There could be a few reasons it's not working. I want to confirm I understand you correctly first. Are you saying that you removed the "allowed rodc password replication group" from the password replication policy tab of the RODC? And then you replaced it with "Domain Users" and set it to allow in the password replication policy tab of the RODC?

Yes

@staustin wrote:
Hi @Brandon_Wertz,

In addition to the aforementioned issue, I don't know if the credential agent will query any group that's not in "allowed rodc password replication group" (this is a conjecture as i've only nested groups in "allowed rodc password replication group". The second part may not be a contributing factor.
.

This is what we did, and we're being told the user-agent / cred software is likely only coded to query this inherent group. We don't want to use this inherent group utilized across our enterprise on other RODCs (scope creep / security risk...why push cached creds to RODCs on RODCs that don't need it)

@staustin wrote:
Hi @Brandon_Wertz,

What I had to do to get it working is as follows:
1. I created an AD object called allmyusers and added all user accounts to the group.
2. I added allmyusers object to "Allowed rodc password replciation group"
3. Bounced the pan userid and credential agent

Until PAN fixes the issue, "Domain users" will not work and you have to create a different group that essentially does the same thing but isn't the build in "Domain users" group.

There's the inherent problem with our deployment. Why would we replicate our entire enterprise password cache to "sensitive" locations in our environment by putting all users in an inherent / global group? This doesn't seem very secure.

I've actually got this working previously using software on a writeable domain controller. it seems like it would be smarter to just utilize a writeable DC and not touch what should be this protected group.

Re: Testing 8.0 Credential phishing prevention

staustin — Tue, 26 Jun 2018 17:46:08 GMT

Your concerns about security are definitely valid. I was able to work with the constraint in my environment because we only have 2k users and all our DCs live in the same place. PAN heavily recommends not using a writeable DC, but there's nothing stopping you. You can still try not using the global allowed rodc password rep group and create a custom group with like 20-40 users in it first to see if the cred agent will try and query it.