Thank you guys for the responses.
Even though I feel this demonstrates that I am still learning and need to focus more time in reviewing our profiles, wanted to post this update for record, and others.
After reviewing with terrific PA support, I believe the issue started with the fact that our Vulnerability profile was set to default (long before I got here). Therefore, the threat in question was processed as its default action, alert (instead of reset both).
Seems that the traffic was able to pass and then the server in question is an Oracle Weblogic server that was not patched to resolve this exploit!
Since we had Carbon Black in place, the threat was unable to run. One of the behaviors was a powershell script would try to run scheduled or periodically and we blocked powershell to run and monitored its attempts.
We corrected our vulnerability profile, restored the Oracle server from backup (previous to exploit) and so far we have no other powershell execution attempts and see that the threat is now identified and blocked at the firewall (reset both).
BPry
Otakar.Klier
I see there are wildfire traffic and threat detection coming from this server in question. The rule is an outbound to internet rule.
Would this mean that this server is in fact infected some how?
Since it is using wildfire, would that mean unknown or zero day perhaps?
I also see this server attempting to reach out to the internet and session ends in threat.
Thank you guys for the responses.
Even though I feel this demonstrates that I am still learning and need to focus more time in reviewing our profiles, wanted to post this update for record, and others.
After reviewing with terrific PA support, I believe the issue started with the fact that our Vulnerability profile was set to default (long before I got here). Therefore, the threat in question was processed as its default action, alert (instead of reset both).
Seems that the traffic was able to pass and then the server in question is an Oracle Weblogic server that was not patched to resolve this exploit!
Since we had Carbon Black in place, the threat was unable to run. One of the behaviors was a powershell script would try to run scheduled or periodically and we blocked powershell to run and monitored its attempts.
We corrected our vulnerability profile, restored the Oracle server from backup (previous to exploit) and so far we have no other powershell execution attempts and see that the threat is now identified and blocked at the firewall (reset both).
@OMatlock wrote:Thank you guys for the responses.
Even though I feel this demonstrates that I am still learning and need to focus more time in reviewing our profiles, wanted to post this update for record, and others.
After reviewing with terrific PA support, I believe the issue started with the fact that our Vulnerability profile was set to default (long before I got here). Therefore, the threat in question was processed as its default action, alert (instead of reset both).
Seems that the traffic was able to pass and then the server in question is an Oracle Weblogic server that was not patched to resolve this exploit!
Since we had Carbon Black in place, the threat was unable to run. One of the behaviors was a powershell script would try to run scheduled or periodically and we blocked powershell to run and monitored its attempts.
We corrected our vulnerability profile, restored the Oracle server from backup (previous to exploit) and so far we have no other powershell execution attempts and see that the threat is now identified and blocked at the firewall (reset both).
I think this highlights an important fact...It's not necessarily always best to accept a "standard config." At my company I went ahead an made the decision to override the defaults of all "Critical and High" signatures to a "reset." Just for this very reason. I'd rather respond to "why is something being blocked" versus "how did we get compromised.
Your scenario does highlight a positive though...Defense-in-Depth. While one source of protection may not be sufficient, either from misconfiguration or a straight failure, others should always be in-place to catch what might be missed.
