Following my custom signature discussion here, the command execution test on DVWA results in cmd.exe being called in the background. Access to cmd.exe via a publically facing web page is obviously something that needs to be controlled, and I would expect something to trigger - in this case it did. After executing a test POST as per my previous discussed, the local HipShield.log showed 5 entries for signature 1148. The first entry is as follows, and the following entries were exactly the same with the exception of "VIOLATION:
Sending the events to ePO only shows 1 event (I expected this - there must be some reason why 5 were logged in HipShield, however - possible 5 'communications' with CMD, ie the 4 pings plus the 'type' command?). The event details are as follows:
I am just wondering, from an operational perspective, if I had seen this, what would my next steps be? The threat source process is svchost.exe and it has read cmd.exe. What was the attack vector used? What arguments were actually passed to cmd.exe? How do I determine if this is benign or malicious?
The initial request is passed via PHP shell_exec. If this is somehow going via svchost.exe, then surely it must be possible to catch this earlier on, and give us a little more information to determine what has actually happened, and possibly catch the arguments that have been passed to cmd.exe? I admit I am not au fait with the inner workings of the processes and OS, but I am not currently sure of what my next steps would be if I had seen this event type...
Thoughts and ponderings appreciated!
For what you're doing, HIPs event info can be pretty bad, and this rule in particular is terrible. It's just the way the tool was made. It's not powerful enough for today's demands of ever changing APT threats etc. Who cares if scvhost.exe executed cmd.exe? That happens a million times a day.
What you can do is take it to the next level and combine events from different rules together, or even combine HIPs events with other log sources (network ids, windows logs etc) to paint a better picture. This correlation has been successful for us so far, but you need a powerful log aggregator with a query language to do this work automatically, as well as plenty of time to craft these correlation rules through RE.
If you want to stay on the host side and care enough to detect this behavior, you would want to work up or down the chain of bad events here and make rules for those. Maybe make a rule watching anything executing scvhost.exe (with a large whitelist), or try to figure out what cmd.exe sets off next. The common problem is that even these next-step rules provide just as terrible event data, and they are much too loud. Even worse is when you need events but they are too loud and if you whitelist something, you are left with nothing.
It's up to you to figure out what events will be quiet and high fidelity enough to paint a picture when put together, and it's not an easy task with this tool.
Thanks for the feedback! When you say this happens a million times a day, I am assuming that this is expected behavior, and would require an exception. That is unless you have some external logging subsystem that has the ability to aggregate and correlate (and have the money to do so - even the less expensive ones need investment with regard to configuration and tweaking). I guess that the main point of this is to highlight that a)if possible, Host IPS needs to provide more information, and b)that any security product has limitations if those who use the product do not know how to interpret what they are seeing (when you say 'who cares', that is fine is you actually know that this is expected behavior, but not everybody does - I have seen a lot of deployments where in the initial setup they have simply configured exceptions for everything that has been seen, which potentially misses an attack during baselining). Another consideration of external SIEM/a.n.other log aggregator is that exceptions will tend to not be configured on ePO as you need visibility above everything else, potentially leading to more strain on the ePO environment. A lot of consideration - it aint easy but it is certainly interesting :-)
I agree wholeheartedly with 'It's up to you' - security tools can only provide so much interpretation, and a lot of that interpretation is only if relevant rules are configured. What I do want to see, however, is the tool providing as much information as possible - I think in development that it has been a case of 'we have detected this, here is the data', with little thought as to how the tool may actually be used operationally - there needs to be a view of the bigger picture, and I personally think that McAfee are up to that task - they have some great technical minds working for them.
Exceptions are great if you are in a governed environment with a few hundred hosts and you know what should be happening on your entire network. This is not our case. We don't have the time to grab someone around the world to see if cmd.exe executing wscript was bad or not. We especially don't have the time to do it thousands of times a day. Even more so, we can't always white list these things because the moment one is bad, we're in trouble. So yes, we ask for visibility and worthwhile information from an IDS. HIPs has trouble here in large and/or federated environments.
This is why we took the approach of creating generic HIPs rules (but better than this cmd rule, say "An executable in temp folder creating a run key"), and combining them with other HIPs or IDS rules. It works, but is a development (RE and deployment) time sink, and log storage money sink. If a Snort alert is that puzzle piece you pick up and think "Aha, it goes right here!", HIPs are those one off puzzle pieces you have sitting out to the side forever until it becomes clear where they belong. This isn't acceptable. Nor is it necessary. Host IDS/IPS needs more information and more ways to detect things than what HIPs has provided for it to be useful. We've solved the problem to a degree by dumping money into space in our log aggregator and using correlation techniques, as well as spending days developing and deploying our own custom rules that don't bring down the ePO servers.
A great example against white listing is trying to white list explorer.exe from a certain rule. Most people would probably say you see it all the time in HIPs rules. In this case it was 90% of the event's makeup. But guess what, when combined with another event, it was TP 1% of the time. That's a crappy situation because we can't white list explorer at this point. But if we had a better host based IDS we could make the rule in question higher fidelity.
I'd kill for true regex in HIPs, or the ability to look for any API calls and their arguments, as well as being able to correlate inside the HIPs tool itself to save everyone time and headache. I may sound jaded because I see what a host IDS product could be after using HIPs. It really could be quite incredible. It would be limited by how good you are at reverse engineering. So in essence, I think I'm in agreement with you.
The only reason you sound jaded is because you are passionate, and from my perspective that is a very good thing. The community (and IT, and other industries) need more people like you. It is the passionate ones that get the most frustrated :-D
Had a quick look at your profile, and love your posts - would be grand if we could get some McAfee feedback! 64235 was fantastic write up, and 63717, 63824 could do with McAfee input.
In general, there are many undocumented options that you can find if you look hard enough. PM me if you want more info on how to find them.
Also, Ambush IPS was a thing that almost happened. It would of been quite powerful.
Very interesting stuff - I need to get me some time to play around more :-)
Also found the following via Google (looking for Ambush), which looked good: PwnDizzle: Custom McAfee HIPS Rules That Actually Work
Yeah that was a great post. I responded to it with the info for grabbing the McAfee custom rules if you're interested. That discussion with the author is what kick started the idea of correlating "potentially bad" rules together for higher fidelity for us.
I certainly am :-)
by the way, regarding the PM comment above, I used to be able to do that but the functionality no longer appears to me - are you aware of a way to do this now?
Yeah, not seeing the ability to pm anywhere within reason. As for the info to see the McAfee rules, check out #1 in the first comment in that blog.