topic Re: Palo Alto not flagging dangerous/malicious IP addresses as such? in Advanced Threat Prevention Discussions

Palo Alto not flagging dangerous/malicious IP addresses as such?

yschinck — Wed, 31 Jan 2018 15:26:01 GMT

Hi,

Today I sent two requests to get 2 IPs categorized as malicious (Command and Control) to Palo Alto. The IPs are:

45.33.9.234

199.59.242.150

The current category for both of them is: insufficient-content

However, these IPs are being associated with botnet/command and control behavior by our SIEM and flagged as such, as our Palo Alto Networks allows sessions connecting to these IPs to go through.

Here's what I submitted for each IP when I request a new categorisation.

45.33.9.234

https://www.virustotal.com/#/ip-address/45.33.9.234

https://exchange.xforce.ibmcloud.com/ip/45.33.9.234

https://otx.alienvault.com/indicator/ip/45.33.9.234

199.59.242.150

https://www.virustotal.com/#/ip-address/199.59.242.150

https://exchange.xforce.ibmcloud.com/ip/199.59.242.150

https://www.alienvault.com/open-threat-exchange/ip/199.59.242.150

You can see from the VirusTotal reports alone that there's plenty of suspicious activity coming from these IPs, and that other vendors are also flagging them as malicious.

My question is: do Palo Alto really consider these IPs as safe, and not harmful? What other pieces of evidence should I have linked with my request to put more weight into it? Are VirusTotal reports, threat intel from other sources (IBM X-Force Exchange, AlienVault, etc.) not enough? Do you need an actual malicious sample (SHA-256, MD5 hash, etc.) or else?

Has anyone else been in the same situation as me?

Thank you.

Re: Palo Alto not flagging dangerous/malicious IP addresses as such?

bvandivier — Wed, 31 Jan 2018 16:32:08 GMT

Hello, while it does appear that both IP addresses you have mentioned are associated with suspicious activity we will often categorize certain sites as insufficient-content due to the following reasons:

"Insufficient content"

Websites and services that present test pages, no content, API access not intended for end-user display, or that require authentication without displaying any content that suggests a more specific categorization. Sites absent of content, or those with no useful content such as server test pages make it difficult to identify the intent or business of a site and categorize accordingly.

If you would like to open a case with our support team we would be happy to investigate these IPs further and request C2 categorization on your behalf.

Re: Palo Alto not flagging dangerous/malicious IP addresses as such?

yschinck — Wed, 31 Jan 2018 16:35:55 GMT

Hi bvandivier,

Thank you for your answer. I understand the "Insufficient content" categorization, though from the description, I hope that Palo Alto doesn't try to simply access the IP to see if it displays anything, and if not, put it in the "insufficient-content" category. A more thorough investigation of the IP (DNS records, associated activity, etc.) should be done in my opinion.

I'll open a ticket with the Support and see if they want to push the investigation a bit deeper.

Thank you.

Re: Palo Alto not flagging dangerous/malicious IP addresses as such?

mivaldi — Mon, 05 Feb 2018 21:22:05 GMT

IP addresses that are typically associated with malicious activity tend to be ephemeral since the devices engaging in C2 are often times benign devices that have been compromised.

URL Categorization is for websites, and it's limited to HTTP traffic, that's why you would see an insufficient-content categorization.

IP Addresses in the pre-build EDL's (High-risk, and Known-malicious), are exhaustably manually vetted to make sure they are not ephemeral benign compromised hosts.

Instead of creating IOC's based on IP's, we are instead interested in identifying traffic by its patterns, so that if the C2 moves to a different IP, the signature continues to be useful, therefore, we would recommend to engage support, and present with a packet capture of C2 traffic, so that we can build a signature based on traffic patterns - instead of destination IP's.