This means that when there’s a new release of said tool, that the GPO needs to be updated. Intrusions typically start at the desktop level, so if you’re monitoring them (which most organizations don’t), you may as well get this information.Īlso of note, my AppLocker GPO is using a hash value of these tools. I know that’s not always good practice, but I did this in case you’re using SCOM to monitor desktops as well. Most of these alerts are targeted towards Windows Computer. I cannot emphasize enough that good alert management process is the key to making this MP work in any capacity. The point is that each time an alert is generated by these tools, it should be investigated. But by default, WinRAR use will not generate alerts, as I suspect it would generate more noise than good, but if this tool is not in use in your organization, then it would be wise to track it as for whatever reason, the bad guys like it too.Īlert flood detection is NOT enabled for these rules. If you don’t use this in your environment, I’d recommend updating the AppLocker GPO to audit its use as the bad guys seem to love this tool for whatever reason. It happens to be a very useful and legitimate tool, and it is somewhat prolific in normal user environments. I created a rule to check for it, but I did not add it to my GPO. For those who are unaware, it’s a compression tool (think WinZip). You’re welcome to enable the individual rules, but I suspect they won’t do much good. As such, the only rule enabled for this section is the “Prohibited app in use” check which does not discriminate based on tool (the info is in the event description of the alert). The reason for this is that it’s very easy to bypass this check by simply renaming the executable. I have individual rules for each of the tools we are checking for, but those are disabled by default. If they recompile the executable (or you choose not to continuously update the AppLocker GPO with the latest hashes), it essentially renders this check relatively useless. I will also note that sophisticated attackers can get around a lot of these rules. These events are found in the Microsoft > Windows > Applocker > EXE and DLL log. It is looking for event ID 8003 with an EventDescription containing the software package in question. It is, however, something that should be investigated. This isn’t to say that each alert generated by one of these tools in necessarily proof that your environment is compromised. As a caveat, it is worth noting that many of these tools can be used internally for various reasons. I’ve provided a custom GPO I’ve written to audit the use of a few known hacking tools. These rules are only going to work if you have AppLocker GPOs in place to audit your environment. I’ve added this as a courtesy, but if that is all that is being used in this management pack, then it is not accomplishing anything. Traditional anti-virus works to detect many of these tools, and while an attacker can corrupt AV pretty easily, it’s also just as easy to recompile these tools so that they leave a different signature that a typical AV/malware detector cannot find. I’ll be honest in that these are included because they are easy to do, but in reality, they do not provide much in terms of protection.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |