Introduction
PowerShell is really useful to automate actions for operations, security, and others. This is a really useful and powerful tool, but it this usefulness can also be abused by attackers. For instance, we can automate the update of some software, we can download and execute the update, but we can also download malware and infect a machine. Also, we can search files that are too old and delete those in order to safe space or comply with data protection, but we can also search for interesting files that we may want to exfiltrate.
These are some examples of things that are possible and can be done on PowerShell. We as defenders want to be able to detect this malicious attempts but also maintaining the benign PowerShell use. For this we will need to detect this attempt and Microsoft has some good features for this, but before enabling this there are some things we will need to consider.
Logs space
On a lab you will be able to maintain your logs for long time before those get overwrite, but in a normal environment the default space will be overwritten many times a week or a day. This is terrible if we don’t store those in other places. Even if we store them on a SIEM or other repository, it’s good to have more space for logs in order to be able to have them during forensics.
This is the first consideration, and not only for PowerShell events, ensure your logs can be as long as your computers allow. This should be done with all logs, but the ones that are not going to your SIEM should have more space. This may help in case you detect malicious activity, and need to verify some events like remote PowerShell, WMI usage, RDP usage, etc.
So first consideration: space for your logs.
Network
When sending your logs to a SIEM the amount of data you send can cause some problems on the throughput. The amount of data you may start sending after enabling this logs can be up to terabytes per month. Some networks will have issues with this amount of data and for that reason you have to consider it.
You don’t need to be precise with the amount of data, but you have to at least have an idea of how much data you will start sending.
CPU usage
Some environments have old systems with low resources, these systems can be easily overloaded, so be careful with the amount of data that your system can handle. All the consideration until now we can avoid by doing some testing on some development servers.
SIEM, costs and more costs
When storing our events we need to consider the costs, we won’t have unlimited budget. If you have an on-premise SIEM the disk, RAM and CPU will constrain on the amount of events you can store. We want to have those events for at least 6 months, time that can take us to discover a breach. I personally believe that 1 year of logs will be enough to do investigations in case of breaches.
You may have 1000 TB of space, but your CPU and RAM could be not enough to query the data or take up to days to return any result. You will have to be sure that your resources are good enough, some documentation will help on this.
Other options are hosted SIEM, this can come on different plans. One can be hosted, but you pay for the disk space. This can be the ideal for many companies. Other type of plan can be with a MSP, this can be really useful for bigger companies, not because you can fire all your security team but because some of this came with “unlimited space”. This unlimited space can vary from provider to provider, some can give you up to 1 year of storage. The yearly payment can be high, but the benefits you will receive can out weight the costs.
Cybersecurity Team
You can have the best SIEM, with all the logs of the world and alerts for every type of events, but if your team doesn’t know how to respond or use your logs it will be for nothing. Some companies have gone to offload the security team to other providers, this can be good for many companies. But an inside team can create custom alerts and baseline your environment, also they can look for weakness and correct them.
Conclusion
Well yes, this was a bait. It’s not only about PowerShell, but also for all events on our environment. Consider, investigate, plan, test and deploy.