About apackard

apackard · ‎09-03-2018

Does anyone know if the credential phishing agent requires different\additional permissions to the base User agent? I have installed with our 'standard' account and I get this in the logs:- 09/03/18 18:05:33:996 [ Info 2036]: ------------Service is being started------------ 09/03/18 18:05:33:996 [ Info 2043]: Os version is 6.2.0. 09/03/18 18:05:33:996 [ Info 389]: Load debug log level Info. 09/03/18 18:05:33:996 [ Info 247]: Service version is 8.1.3.10. 09/03/18 18:05:33:996 [ Info 392]: Product version is 8. 09/03/18 18:05:33:996 [ Info 313]: Named pipe for UaService created. 09/03/18 18:05:34:028 [Error 716]: Unable to extract credentials. 09/03/18 18:05:39:028 [Error 716]: Unable to extract credentials. It is also possible this is due to a security setting on the server itself I assume. Thanks

apackard · ‎08-02-2018

Fraid not - we're currently escalaing this with Palo. In a way it's good to know others are impacted by this as we're being told it's never been seen before. Interestingly for us we see this much more in our US locations - we have same hardware, same OS version, same rules in EU and Asia locations and we're seeing 90% less unknown trafic types being logged.

apackard · ‎06-12-2018

We are seeing some of our Palo's periodically logging (almost) all traffic as unknown-tcp. As the traffic is being allowed through (and logged against) rules that do not allow it we assume this is a problem with the logs, rather than traffic being miscategorised. However we do seem to be be experiencing some random issues that may, or mayt not be connected. Rebooting the Palo seems to clear the problem. Just wondering if anyone else has see this (we are 8.1.1) before opening a support call.

apackard · ‎05-25-2018

Has anyone noticed an increase in the number of false-positives being generated by Wildfire in the last few weeks? I seem to be getting a increased number of alerts for WF learnt viruses on apps that have never caused issues before. Always worried that it is indeed a real alert, but as far as we can tell it's not. Just wondering if anyone else has had something similar and\or if anyone knows if PA have deployed new detection criteria etc? Thanks

apackard · ‎05-15-2018

I have an IP IoC feed that I would like to ingest and re-publish via MM. The feed is ordered by priority i.e. earlier addresses are newer\more active\higher risk, but if I ingest and publish (miner -> output) it is re-ordered by numeric order. Is there any way to prevent this and maintain the initial order? Technically I have a way around it by inserting another solution between the original source and MM (ultimately I'm trying to limit the number of IoC's as there are more than we can ingest into our PA's and I was using the ?n=x option) but it's a bit clunky!

apackard · ‎05-15-2018

Thanks very much! Though, believe me, you don't want my cide anywhere near the product...!

apackard · ‎05-11-2018

We are looking at various options to build a SOC framework and one of the objectives is to be able to have an internal 'queryable' API that we can use to investigate a single IP\IoC. Is there anyway to make MineMeld work in that manner i.e. so we can query a list to see if an IP is included- https://minemeld/feeds/badlist?ip=8.8.8.8, rather than downloading the entire list and then having to muge the data as a secondary task.

apackard · ‎05-11-2018

Update to close this one down. It was an issue with the 2FA provider - the intermediate RADIUS server was randomly rejecting the 2nd factor auth before it had even been attempted!

apackard · ‎04-06-2018

Thanks for the reply. I've also seen the format sensitivty (it is especially annoying as a failed transparent auth presents a pop-up to enter username\password and it seems to automatically populate the username in domain\name format so we're going to have to educate users to delete the domain portion!). To be concise however, the second RADIUS auth request is going to the same server (no load balancing etc). We've done some packet captures of good (left hand) and failing (right hand) sequences. In both cases everything looks good in terms of expected flows (request -> challenge -> request -> result, challenge 'state token' presented at step 2 and re-presented at step 3, MFA option passed in the password field of step 3) but when it fails it does so in <1ms. This is too short (as far as we can tell) for it to try and check the '1' as a password. We're leaning more towards the RSA RADIUS server having the issue as that seems to be where the actual error is triggered, but cannot discount there is something off with the request that causes it.

apackard · ‎04-06-2018

We are trying to get 2FA RADIUS based authentication working with our Palo's and are seeing unreliable results. After much hunting and teeth gnashing we think we may have found the issue, but not the cause. The below is a debug dump from the RADIUS server (RSA AccessID) using Panorama GUI logon as the test case. The first shows a good 2FA auth and the second a failing one; it looks as if the Palo is not correctly replacing the username attribute in the 2FA RADIUS request (assuming it's not a processing issue on the RADIUS server) so the request is being rejected. Would anyone know anything about this? We're particularily confused as it is not consistent - if it always failed I could chalk it up to a bug but it sometimes works and sometimes doesn't... Will be opening a TAC case but always like to get others users experiences in first! =========== GOOD AUTH =========== First factor authentication (LDAP AD username\password) is successful 2018-04-06/17:30:15.568/UTC [AuditEntryProcessor] INFO RADIUSAUDIT[81] - ----------START_RADIUS_USER_LDAP_AUTHENTICATION---------- EVENTID=RADIUS_USER_LDAP_AUTHENTICATION DATETIME=Fri Apr 06 17:30:15 UTC 2018 IN_RESPONSE_TO=ed53938a-4193-4a8e-83fe-901b39d3f4ef DESCRIPTION=RADIUS â€“ LDAP authentication succeeded. NAS-IP-ADDRESS=<snip> USER_NAME=jbloggs CLIENT_ID=RADIUS: Panorama RADIUS_RESPONSE_TYPE=Access-Challenge STATUS=SUCCESS REQUEST_ID=ed53938a-4193-4a8e-83fe-901b39d3f4ef POLICY_ID=Global Protect Employee VPN TENANT_ID=<snip> ----------END_RADIUS_USER_LDAP_AUTHENTICATION---------- Second factor authentication (mobile push) is successful - and the username has been replaced with the 2FA method 2018-04-06/17:30:27.973/UTC [AuditEntryProcessor] INFO RADIUSAUDIT[81] - ----------START_RADIUS_USER_APPROVE_AUTHENTICATION---------- EVENTID=RADIUS_USER_APPROVE_AUTHENTICATION DATETIME=Fri Apr 06 17:30:27 UTC 2018 IN_RESPONSE_TO=f6f3c7df-0ae1-4c36-bb62-0e4df22db374 DESCRIPTION=RADIUS â€“ Approve method authentication succeeded. NAS-IP-ADDRESS=<snip> USER_NAME=MOBILE_METHOD_REFERENCE_ID CLIENT_ID=RADIUS: Panorama RADIUS_RESPONSE_TYPE=Access-Accept STATUS=SUCCESS REQUEST_ID=f6f3c7df-0ae1-4c36-bb62-0e4df22db374 POLICY_ID=Global Protect Employee VPN TENANT_ID=<snip> ----------END_RADIUS_USER_APPROVE_AUTHENTICATION---------- ========= BAD AUTH ========= First factor authentication (LDAP AD username\password) is successful 2018-04-06/17:30:59.015/UTC [AuditEntryProcessor] INFO RADIUSAUDIT[81] - ----------START_RADIUS_USER_LDAP_AUTHENTICATION---------- EVENTID=RADIUS_USER_LDAP_AUTHENTICATION DATETIME=Fri Apr 06 17:30:59 UTC 2018 IN_RESPONSE_TO=3e86e627-7498-4663-8fb1-59c6a00707da DESCRIPTION=RADIUS â€“ LDAP authentication succeeded. NAS-IP-ADDRESS=<snip> USER_NAME=jbloggs CLIENT_ID=RADIUS: Panorama RADIUS_RESPONSE_TYPE=Access-Challenge STATUS=SUCCESS REQUEST_ID=3e86e627-7498-4663-8fb1-59c6a00707da POLICY_ID=Global Protect Employee VPN TENANT_ID=<snip> ----------END_RADIUS_USER_LDAP_AUTHENTICATION---------- Second factor authentication fails - and the username has not been replaced. 2018-04-06/17:31:04.017/UTC [AuditEntryProcessor] INFO RADIUSAUDIT[81] - ----------START_RADIUS_USER_APPROVE_AUTHENTICATION---------- EVENTID=RADIUS_USER_APPROVE_AUTHENTICATION DATETIME=Fri Apr 06 17:31:04 UTC 2018 IN_RESPONSE_TO=cfd1f7ae-13d4-494a-9d4d-6cd1584f4475 DESCRIPTION=RADIUS â€“ Approve method authentication failed. NAS-IP-ADDRESS=<snip> USER_NAME=jbloggs CLIENT_ID=RADIUS: Panorama RADIUS_RESPONSE_TYPE=Access-Reject STATUS=FAIL REQUEST_ID=cfd1f7ae-13d4-494a-9d4d-6cd1584f4475 POLICY_ID=Global Protect Employee VPN TENANT_ID=<snip> ----------END_RADIUS_USER_APPROVE_AUTHENTICATION----------

apackard · ‎04-04-2018

Cheers both; we are about to raise a TAC call. FWIW the hardware is new (circa 2 years old). Fairly sure it's not a queue issue - the commit job starts fine, gets to 98% and just sits there; we had a commit take 24 minutes the other day, then another one later in the day was 20 secs. Will feed back when we find the cause so others may learn from our pain.

apackard · ‎04-03-2018

Anyone who's used Palo's since the early days may roll their eyes at this question..! We have a bunch of 3020's and one can take an age to perform commits; for example this morning we performed 4 - the first 2 took <30 seconds, the 3rd took >10 minutes, the 4th took >30 seconds. The only aspect to the 3rd commit that I can think was different was that it was after a new address object was created. We are well used to old boxes taking an age, but this is a 3020, and as noted above commits usually are fine but occasionally take forever with no obvious reason. It only appears to occur to one box so we've been thinking it's something unique to the network that this is on (difficulty resolving FQDN objects, other connectivity issues etc) but just casting the net to see if anyone else has seen this specifically (not generally slow commits, but a specific box that is either very fast or very slow..). Cheers

apackard · ‎04-03-2018

I was running 8.1.0-x, but have dropped back to 8.0.8-2 and that seems to have fixed the issue.

apackard · ‎03-29-2018

Thanks, yes, they are showing up in the monitoring logs. I'm going to try downgrading our agents to see if it is something to do with that. Rgds

apackard · ‎03-28-2018

We do, but these entires seem to be coming directly from a UserID agent service as we can see them in the monitoring logs.

Member Since	‎09-23-2010 09:13 AM
Date Last Visited	‎08-30-2020 02:59 PM
Posts	138
Total Likes Received	11

Online Status	Offline
Date Last Visited	‎08-30-2020 02:59 PM

About apackard

Re: Reliability of "name-of-threatid" in threat log searches

Reliability of "name-of-threatid" in threat log searches

Re: Syslog listener to python script possible??????

Re: Cobalt Strike Potential Command and Control Traffic(18927)

Re: Cobalt Strike Potential Command and Control Traffic(18927)

Cobalt Strike Potential Command and Control Traffic(18927)

Feed with mixed IP \ domains

Re: Custom Prototype for 'basic' weblist mining

Re: Custom Prototype for 'basic' weblist mining

Custom Prototype for 'basic' weblist mining

Cobalt Strike Potential Command and Control Traffic(18927)

Re: Using Minemeld to do FQDN refresh for security rules

Re: Almost all traffic identified as unknown-tcp?

Almost all traffic identified as unknown-tcp?

Blocked Applications cause Reset, not Block Page

Re: Threat ID 39341 - Metasploit Windows Meterpreter Reverse HTTPS Detection

Crednetial Phishing Agent Permissions

Re: Almost all traffic identified as unknown-tcp?

Almost all traffic identified as unknown-tcp?

Increased FP's for Wildfire Viruses

Non-reordered IoC feed

Re: Query MineMeld for a single IP\IoC?

Query MineMeld for a single IP\IoC?

Re: 2 Step RADIUS Auth Reliability

Re: 2 Step RADIUS Auth Reliability

2 Step RADIUS Auth Reliability

Re: Very Slow Commits

Very Slow Commits

Re: UserID Reporting Computer Names

Re: UserID Reporting Computer Names

Re: UserID Reporting Computer Names

Unlock your full community experience!

About apackard