We recently had a pen test and had positive results. We do not use URL filtering, but have everything else.
However, on 12/24/2017 we can now see a reboot.txt file sitting in our Windows\temp directory on an Oracle OAM server.
Luckly, Carbon Black flagged the file as it was trying to be run and denied, running from cmd.exe.
We can also see a new Windows task scheduler task created on 1/2/2017 that calls to run schtask1.ps1, that we did not create. Also cannot find that file. Did a restore of the VM to 12/21/2017, no trace of these new files and settings.
We continue to our threat alerts denying malicious traffic. Quick searches so far seem to indicate cryptocurrency mining.
I see there are a couple of PA references out there for this.
Curious if anyone has any comments as we continue our investigation or any of this rings a bell?
I've been searching our traffic logs for cryptocurreny as mentioned here, but nothing so far.
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).
Sorry for your troubles, never a good time. As a quick solution, you may want to try the following. While you wont get the bells and whistles without being a customer, it will block DNS qureies to their known bad sites:
The steps mentioned in that Reddit article are pretty good, and would be my immediate reaction. Honestly though you should really be looking at how someone was able to access your OAM server in the first place and mitigate that. Crypto mining isn't really a 'threat' per say, since they are just stealing your resources. However, if enough access to your server is actually allowed for this to happen then you could be leaving yourself open to bigger issues in the future.
Thank you for the feedback folks.
Yes, I we are wondering how access was gained. This is a server behind our PA with an internal IP, behind a load balancer with an internal IP. We do NAT of course from a public IP to the load balancer private IP.
We do see that there are several Weblogic patches for vulnerabilities, and we are likely out of date. But trying to figure out how access was gained in the first place.
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.
You are correct. PAN see's malicious traffic and is blocking it.
There are several types of actions the PAN can take.
A reset both just means that the PAN sent a close socket to both the attacker and victim in this case to prevent a DoS scenario.
Here is some info on those IP's:
I would say it depends on what you are looking for as your next steps. Some like to let the traffic continue and try and analyze to see if they can figure out where it can from. Others just want to shut it down ASAP, meaning put in policies to deny traffic to/from those IP's and any others that are not legit.
I guess the trick is to know which are legit or not, and block them automatically if not legit.
We have not made any changes to remediate yet, since Carbon Black seems to be preventing it to run and PA is blocking traffic. But don't know how it got there in the first place.
We have a call with a security provider tomorrow morning...will update.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!