File hashes fed into a SIEM have a potential to help detect both APT and Insider Threats like IT Sabotage. This blog post focuses on the business case and the technical challenge at a high level. Scott Taschler will cover the implementation guide for this use case in a later blog post. Let us both know what you think of this approach.
Using Hashes for Malware Detection – AdvancedThreats
An Advanced Threat to a company is one that combines multiple hacking techniques: social media reconnaissance, spearfishing, command-and-control servers using fast-flux DNS, and remote control malware such as Trojans or rootkits. An Advanced Threat (sometimes called Advanced Persistent Threat, or APT) almost always uses one or more zero-day exploits to install malware. Below is one fictional example of an Advanced Threat.
Joy is an engineer working in the research division. One day she gets an email titled “Wow-last night”. She doesn’t recognize the name of the person who sent the email, but they appear to know her because they tell her that the pictures from Saturday are up on Flickr. She knows she was out on Saturday (it was epic), and she wants to make sure the pictures won’t get her in trouble. She clicks on the link, and gets a “Image not found” error page. “Maybe it got taken down already, whew”, she thinks. Relieved, she closes the browser window, deletes the email and goes back to work.
Halfway around the world, a message pops up on an IRC window at one of the computers. It is the middle of the night, but there are seven hackers who just started their shift. One notices the message, types some commands, and watches as some needed software is installed on Joy’s computer. All of the input from her keyboard typing is now spooling onto a file to be reviewed later for passwords and web history. Occasionally the malware takes a screen shot of her work, waits a bit, then turns on her webcam and takes a picture. These are encrypted, compressed, and sent out to a remote server on a timed delay. Later, when Joy is not using the computer, another shift of hackers will use the computer to log on to the company intranet and go hunting for valuable corporate information.
A zero-day exploit poses a significant challenge for security software that uses signature-based detection. Writing a signature requires a number of samples to be analyzed and their common attributes identified; a zero-day exploit maybe the only one of its kind, perhaps never seen by the security community. What can be detected, however, are the changes to a system that the malware may cause. If a rootkit installs a new copy of a system file, the hash of that file will change. Similarly, if a user is added to a Unix machine, the hash of “etc/passwd” will change. For critical files that are not expected tochange frequently, monitoring for these changes can provide an indicator of suspicious or malicious behavior.
The technical challenge is the same for Using Hashes for Insider Threat – IT Sabotage. Love it when that works out!
Using Hashes for Insider Threat – IT Sabotage
The term “Insider Threat”, while it captures the misuse of trust that is a defining part of the threat, does not adequately give enough definition to design controls to mitigate the risk. Using an industry-standard sub-categorization makes it easier to tie the threat to the mitigation. In this use case, IT Sabotage is the risk a company is working to mitigate. IT Sabotage is the abuse of trust by someone in a system administration role, either to tamper or inappropriately use information assets at a company. Below are two fictional examples of InsiderThreat – IT Sabotage
Bruce sees himself asthe model corporate citizen. Each morning, he conscientiously devotes a portion of his morning to logging on tothe email server and going through the email of all the company executives. He knows they are busy and wants to make sure that important news makes it all the way down the org chart. During yearly reviews, Bruce makes it a point to read all performance reviews to see if they really merit the pay increase they receive. Bruce isn’t quite sure what he’d do if he found out the executives were not communicating important news or someone received an undeserved pay raise, but he keeps printouts of his work just in case.
Josh has been contracting at XYZ for about six months now. It’s a good job, even if it is only temporary. There is so much work that sometimes he needs to catch up at home. Since the company security policy prohibits remote access for contractors, Josh set up his own remote access software, giving him a backdoor through a DMZ server so he can access his systems from his home. Due to some temporary funding issues, his contract was shortened and he was walked out on Friday. Now, on Saturday night, Josh is logged into the company network cleaning up and removing his remote access. Well, at least some of it; it will be easier to get up and running when he starts working a contract again.
Organizations often spend most of their security resources on securing the external perimeter. While this may lower the pervasive risk of an external attack, it may leave the organization without time or budget to address threats occurring from inside the perimeter. The company can address this issue by re-using some of the same detection controls for the external and internal context.
A change in the hash of a critical file is an important element in detecting both external and internal attacks. For external attacks, it can indicate a successful install of a Trojan horse, rootkit, or other malware. For internal attacks, a new hash can indicate unauthorized software installs, new cron jobs, or creating new accounts on a server. Monitoring for changes to critical files is a way for companies to mitigate the risk of both advanced external attacks and internal threats like IT Sabotage.
To implement this use case, a company would first need a process where hashes of critical files are generated and then collected in a data source. The data source would be pointed toward theMcAfee SIEM and then the file hashes would be parsed. To monitor for critical file changes, you would monitor for new hashes that were not in a “known-good” watchlist, then alert on any hashes that met this criteria. The detailed task list follows:
- To use hashes in watchlists, correlation rules, and enrichment, you will need to create a custom type to hold hashes.
- You will need to create a data source to receive the logs. A syslog example is given in the implementation guide.
- You will need to create a custom parser to map fields into your new hash type. An example is given in the implementation guide
- You will also need something that generates the hashes for your critical files. There are many solutions for getting this list of hashes, from simple PowerShell script , to an open-source project , to a full-featured McAfee solution [3, 4]
- You will need to create a correlation rule to fire on new hashes
- You will need to create an alarm to trigger on the correlation rule firing