Traffic Logs with Session End Reason as Threat

by asampath on ‎10-07-2015 06:13 PM - edited on ‎10-07-2015 06:14 PM by (14,478 Views)


Certain traffic logs show the Session End Reason as Threat, although no threat is observed in the Threat Logs or Data Filtering Logs for the source and destination IP pair. The following is a snippet of the traffic log detail of such a log:



The Threat Log in the image depicts the threat as a Type: File for SkypeSetupFull.exe, with action Forward. The Threat ID under the Details section shown is 52060. 

Find the threat ID 52060 in the screenshot above without any Threat Name. Using the CLI, run the following command:


> show threat id <threatid>



admin@104B-PA-VM-100> show threat id 52060

Microsoft Portable Executable (PE) file upload or download has been detected.


The Threat ID observed is that of a File Type Identification ID. This states that a PE file was downloaded/uploaded in the network and triggered this ID. This ID cannot be located on the Threat Vault and can only be identified via the CLI.


This is expected behavior and is occurring due to File Blocking Profile with actions Alert, Forward, and Continue-Forward for the different file types downloaded. File type identification signatures have threat IDs associated with them.


by shganesh
on ‎12-10-2015 09:56 AM

We should change the name threat to someother name like file signature ID or something. This is highly confusing!

by John.Petrucci
on ‎01-30-2017 12:11 PM

What about a traffic log with Session End Reason = threat, but no associated threat (or any other type of) logs in the bottom pane?  Everything points to action = allow, except Session End Reason.

by akapucu
on ‎01-15-2018 11:40 AM

I am also interested in  John.Petrucci`s  question

by Lucky
on ‎01-17-2018 07:55 AM

For people interested into session end reason threat but without associated threat logs  - it is usually a result of some misconfiguration or an error, please open a TAC case so it can be looked at closely.

by JBal
on ‎02-16-2018 08:34 AM

I have the same question: traffic log with Session End Reason = threat, but there is actually no threat log entry for this session. 

At the bottom under the details there is a line displaying the application (in my case smtp) with action (allow) and the sec. rule, but nothing else.

I have antivirus, antispyware and vulnerability enabled in the profile. So how can identify what happened - without doing a flow basic debug? 

by Lucky
on ‎02-20-2018 04:05 AM

Hi Jozsef,


it can happen that decryption is broken. It is known issue that if decryption gets broken during the transaction, it doesn't get reported clearly in the detailed logs, so it is a bit inconclusive. Can you check your logs and/or counters for such issues, do you see any messages on proxy or decryption failing?


Best regards

by JBal
‎02-20-2018 05:00 AM - edited ‎02-21-2018 05:48 AM


thank you for your answer. A few more details:

This is an inbound SMTP TLSv1.2 decryption, which works in general very well. All emails arriving from O-365, are being decrypted, scanned and forwarded to the internal mail GW.

But if the email contains a specific PDF (type-A), the connection does not go through. 

The tarffic log shows that the session has been decrypted with session end reason: threat, action is allow. But no threat log and no threat id or threat type is visible. The app is correctly identified as smtp. 


If we disable decryption in general, the email with PDF/A goes through. I scanned the email+pdf on virustotal, nothing found. 

I cannot disable the security profiles (av, vuln. spyware) for this test, because it affects all the mailflow, and we cannot narrow it down to this particular traffic, because all mails are coming in from various O-365 IP addresses. We never know in advance, which O-365 IP will be the source for the test email, so we have to capture all smtp traffic and filter it afterwards. We see from captures the PA sending back an RST. Global Counter does not show any proxy/ssl-related failure, only an injected RST - but here I am not entirely sure, because the filter set is quite wide, lots of emails are arriving at the same time. 


I remember from past cases that failing decryption can cause the above behaviour, but I thought this has been sorted by now with the newly added session end reasons (decrypt-error etc.)? Btw customer is using 8.0.6.

So... yes, it might be that decryption is failing because of the pdf/a; or the PA does not tolerate something in the SMTP conversation if it contains a pdf/a and sees it as a threat?


I think it`s time to open a TAC case  :-)


by Lucky
‎02-20-2018 08:02 AM - edited ‎02-21-2018 04:39 AM

Hi Jozsef,


open a case, upload TSF, let TAC check :)



by Farman
on ‎02-26-2018 03:17 PM

Just to add here. The session end reason will also show as threat, but no threat logs will generated when the URL-Filtering profile is applied with action "Block/Continue and override sessions.


by JBal
on ‎02-26-2018 03:21 PM

In my case the root cause was a decryption failure.

by Anon1
on ‎05-07-2018 03:58 PM

Hi Jozsef,


how was the decryption failure fixed in the end?

by JBal
on ‎05-08-2018 02:02 AM

Hello Anon1,
In my case the decryption error was caused by a bug and TAC provided a CLI command to switch off the feature causing it, until the issue is fixed.
As per TAC, I cannot publish more details here in the forum. Anyone experiencing similar issues please open a support case.

by Sreeharshakamisetty
3 weeks ago

I faced similar issue, Url is being blocked saying that session end reason: threat, but we dont see that Url is being filtered with any Threat/Spyware. when we checked the Url category, it is listed under allowed category in Url-filtering policy. However when I verify this on CLI using "test url <url>" it was not getting categorized successfully. when I check the url-cloud status using "show url-cloud status" command on CLI, it was showing as disconnected. Hence I fixed this by downloading the PAN DB url-filtering license again from the cloud and post which I can see url filtering being categorized properly.

Ignite 2018, Amsterdam, Netherlands
Ask Questions Get Answers Join the Live Community