Thanks to one of my fellow InfoSec brethren and fellow security product developer, he got me thinking as to how to detect a situation he presented me, and well, I finally had an engram kick-in and off I went to see how I would I detect this condition. We are all too familiar with port scans against our firewalls from a myriad of ne'er-do-wellers and how a firewall or other specialty network device detects and blocks reconnaissance behavior. Simply stated, one IP hitting multiple ports, OK, a lot of ports in a fairly short period of time, is the main indicator. But what about inside your network, not just Internet facing systems, how would you detect a port scan occurring? Say, recon by a malwarian already inside a compromised box, a misguided employee, rogue admin, Pen Test consultant, etc. As long as there is a firewall or network device between the source (bad guy) and target that is being logged you could detect a port scan. Or if you have an IDS/IPS inline between the two hosts involved, you could detect the port scan IF you have logs being monitored and alerting on this kind of behavior. If you have a managed service IDS/IPS provider then they should be calling you, or at a minimum alerting you to an internal port scan, so this is a way to see if they are doing what you pay them for, or you have short comings in malicious network detection capabilities. I will also assume that switches are not being logged as this produces more noise versus value in most cases.
But what about same segment port scanning? What if a malwarian is on one host and scans ONLY that subnet and surrounding IP's, could you detect a port scan? Is your IDS/IPS connected to a span port that can see ALL traffic going between systems within a switch or network segment? If not, what else could you do? Would you believe Windows Logs to the rescue if the target is Windows? You could do the same with IPTables on NIX systems by the way. The Windows Firewall Logs can detect this behavior, but not a setting I normally recommend because of the noise it normally generates that is not of much value. And thus why this blog post. So if you test your port scan detection capabilities, and I suggest you do, this is where my InfoSec Musketeer comes into play. Thanks Marcus for planting the seed and "Hey.. where is my avatar on the main page???". VThreat is an all browser based solution that enables you to test your ability to detect various nefarious activities and your ability to detect them, one of which is a port scan. Many of you might be wondering right about now, does my IDS/IPS cover this condition? Could you detect a port scan between two hosts, workstations or servers or the same segment, an IP or two apart? Check out VThreat if you want to test for it! Or play with what I list below, at a minimum if you can detect a local segment port scan successfully. You should be able to detect most of them with well tuned tools that VThreat can help you test.
For Windows systems and Group Policy, if you enable "Filtering Platform Connection" under Object Access found in Advanced Audit Policy and you enable "Failure", where normally I recommend only "success", you can detect a local port scan where your network devices may fail you. The logs will provide you with EventCode 5156 "failed" attempts to create a connection to the Windows host, and in quantities that are never normal. An example where I generally recommend not to enable this option, but an example of why you might want to. Remember, you do not have to send this data to Splunk or other log management solution. You can collect it locally and craft some script to query for this data as you see fit. Of course LOG-MD will collect this information if enabled for a tactical solution, IR work or you want to test if your network devices and logging are up to snuff.
Here is a sample Splunk query for you to ponder and expand upon. Just adjust the ports you want to cover (<20000) and the quantity over time (>10) and then search over the past hour and do some testing.
index=win_logs LogName=Security EventCode=5156 | table host Source_Address, Source_Port, Destination_Address, Destination_Port, Protocol, Keywords | search Source_Port < 20000 | stats count dc(Source_Port) AS Port_Count values(Source_Port) AS Port values(Keywords) by Destination_Address | where Port_Count > 10
Japan's National CERT released a blog on the breakdown of Windows commands abused by attackers. This is GREAT WORK and one of the best articles to reinforce what I have been saying in my presentations, Windows Logging training and of course the 'Windows Logging Cheat Sheet'. Logging command line execution is critical for a mature Detection and Response program. JP-CERT broke down the commands into 3 categories:
Initial investigation: Collect information of the infected machine
Reconnaissance: Look for information saved in the machine and remote machines within the network
Spread of infection: Infect the machine with other malware or try to access other machines
This is the first time someone has tried to break up the commands into categories to better understand what the hackers are doing and at what stage. I have a slightly different opinion on this, but I do not have the luxury of compiling data like they do to create this kind of breakdown. Most of the p0wnage I have been involved with is pure 'spread the infection' with some recon or investigation occurring during the spread. Much of what they do is scripted, so identical behavior, other attacks had indications that there was more than one malwarian involved by the mistakes made (the Newb) and the way the other hacker worked and the commands used. I have never really thought of breaking these commands into these three categories or more, but it might lead to so ideas to craft some logging alerts or tool tweaks From the behavior based solutions and our own work. I promote The concept of 'Malware Management', the review of malware reports and analysis to gain artifacts used by the malwarians. These artifacts are used to help tune, tweak and improve your SecOps, Active Defense and Blue Team capabilities. I also promote the 'Windows Logging Cheat Sheet' to encourage enabling Command Line Logging to catch malicious behavior. You can get the Cheat Sheets here:
I have been involved in some hairy advanced attacks by a very persistent hacker group and the commands the malwarians executed can be a fantastic way to separate normal admin or developer behavior from malwarian behavior. I recently saw a Tweet and disagreed on the point that 'a good hacker in indistinguishable from a developer'. I just don't agree and the commands attackers execute as the data from JP-CERT show is something that can be distinguished from normal behavior and the quanties of execution is key as the data shows. While doing malware analysis in my lab I also get to see what commodity malware of all types do from crapware to RansomeWare to the Dridex Trojan. What commands are built into the delivery, execution and call back and the follow on commands executed are also telling and help to improve Detection and Response, if we listen. If you look up some of my presentations On SlideShare (MalwareArchaeology) you will see what commands were executed, malware payloads used, and built-in Windows commands abused by the malwarians. I further the need to log command line execution and the importance by providing a sample query I created in Splunk for my 2015 Splunk .Conf presentation which can be found in the 'Windows Splunk Logging Cheat Sheet' also found on my website at the link above. Now my list of commands to watch out for is more extensive than the ones in the JP-CERT blog for what I recommend people monitoring for. But all the commands I monitor for have been added in part to practicing Malware Management, analyzing malware to see what commands were executed, actual infected and compromised systems and all the reports folks and companies like us put out. Once you see and experience an actual advanced attack and are able to capture and see the malwarians behavior first hand, a light will go off and you will be able to tweak and adjust your tools to improve your Detection and Response capabilities. Keep in mind that combining the Windows commands with other process executions, minus your normal program executions will allow you to separate the developers and admins from your adversaries. Consider looking at where the commands are executed, such as user space \AppData\ versus All Users \ProgramData to the program and Windows core directories. The data will begin to speak to you, of course ONLY if you have adequately configured logging like the Cheat Sheets recommend. Happy Hunting! JPCERT blog on Windows commands used by hackers #InfoSec #MalwareArchaeology
