"Honey... Did you make sure you locked the basement door and activated the security system? I can't wait to get to the Big Rock Campground, the kids are going to love the waterslide..." Sound familiar? The majority of new homes today have some sort of physical security system protecting the property while the family is away, but are these security systems fail-proof? Are they fool-proof? Most will secure the obvious entry points to a home, but rarely is there 100% coverage. Today, there are tens of thousands of individuals, organizations and even governments that are after the data on your company's servers, your personal computers, as well as your personal devices. In this article, we ask: "Are You Prepared?" The analogy I use above regarding a home security system is in fact similar to a computer system; both have multiple entry/exit points, both support multiple protocols for communication monitoring, both are protecting "desirable" components an enemy wants, and both have back-doors! You say, "Well, I can feel, see and touch my back door at home, but just what is a 'back-door' in regards to a computer system?" A 'back-door' is a common method intruders set-up to provide a path to/from your computer systems. When exploited successfully, it allows an unwanted intruder to attach to your computer system and send and receive data at will, including your company's data and your personal data. Back-doors can be placed on a system for temporary or long-term use. They typically disguise themselves as legitimate processes and can be set-up for a period of time in what's called an "Advanced Persistent Threat" (APT) where the threat shifts from one system to another, making it hard to track. An example of this is the APT29 threat group using the newly discovered Hammertoss malware to spy on its victims. In today's world, it's imperative that security engineers and IT professionals deploy, implement and maintain software/hardware products that mimic a good team of physical security officers in that they are always watching, protecting and alerting when suspicious intruders attempt or appear to have compromised critical infrastructure.
What's Needed
It is a well-known fact that you cannot protect an infrastructure of varied interconnected devices without knowing what there is, how it's connected and how it communicates. Therefore, a thorough discovery and profiling product is the first step in building a top-rated manageable and functional security model. What are some of the most common steps taken for protection?
- Hardening systems/applications per a specific regulatory or policy guideline
- Maintaining a consistent/persistent state of existence – a solid baseline
- In place threat detection tools that alert when something alters or attempts to alter that persistent state
- Vulnerability assessment and management
- A solid/proven patch management system
- Anti-Virus detection on all end-points
- Log Management/SIEM auditing solution
Back to that thing called a "back-door." New vulnerabilities in computer systems and applications are discovered daily. As a result, manufacturers create patches to try to plug those back doors. Unfortunately, not all systems get patched on a timely basis, leaving users exposed to the enemy. In other cases, it's the enemy that exploits a previously unknown back-door that leads to emergency patches to be released. One of the most common methods the enemy will use to ultimately exploit a network is what's called a "port-scan." Using tools readily available on the internet, an intruder will scan a network to assess what ports and protocols are available. Using that information, they will utilize known techniques or develop new techniques (bad-code) to get through the discovered armor of protection.
Indicators of Compromise
How can I protect the infrastructure I am responsible for? What if someone gets through? How will I know? What are my "Indicators of Compromise"? For purposes of this article, I will focus on what I consider to be some of the most overlooked compromises that take place: ports, processes, users and code. As previously mentioned, it is imperative that security engineers and IT professionals have a "known good state recorded of their systems." Of course, this state does need to be maintained, updated and monitored for deviations. Using our security solution in the screenshot below, you will notice several items that have indicated and alerted on changes from the desired state.
- My list of valid local users has changed, and a new local user account has been created.
- My list of allowed software has changed, and new software has been deployed by the "new user."
- My list of allowed listening ports has changed, and I now have a new listening port.
- My list of allowed processes has changed, and I now have a new process running.
- My list of established ports has been compromised, and someone/something is connected to my computer.
In this scenario, it appears the intruder is using some sort of remote client based utility that has the ability to connect to the new running process/server from somewhere and he/she/robot is preparing to do something with this new connection. What's truly an indicator of suspicious activity is the timeframe in which all these changes take place. Let's take a look at that screenshot.
Let's look at those timeframes: User account created on: June 14th at 22:18PM - "ahatcher" New file dropped by new account on: July 7th at 19:11PM New listening port opened on: July 7th at 19:12PM New process started on: July 7th at 19:12PM New established port opened on: July 7th at 19:13PM Well how do I know those events are not just coincidental? How do I know for sure they are related? To answer that, there must be something glaringly in common among the events. Using the proper security tools, you should be able to "drill-down" into those events and look for related context. Let's take a look by drilling down a bit on these "Indicators of Compromise." In the screenshots below we are comparing the context of our "baseline" (left column) to the change (right column) New local user creation change from...
Listening port change from baseline...
Established port change from baseline...
New process change from baseline...
Reviewing the Indicators of Compromise
First, the new local user "ahatcher" was created on June 14, so the account has been around for a while. If we had noticed this new account on June 14, we would have investigated and likely "deleted" the account immediately. We may also implement policies that do not allow or limit the use of local user accounts. This is a good reason why actionable security monitoring of Indicators of Compromise must be in place. Next, we see that the user "ahatcher" dropped a new file on my system on July 7, indicating that a period of about three weeks passed between the time the account was created and the actual breach occurred. Next, we see that the "new file" was executed, and as a result it opened a new "listening port" and also started up a new process disguised as a "print spooler." Within a minute or so, we see a new "established port" change. In the drill-down screenshots, we see that the "listening port" was 3333 and that it was using a process id (PID) of "1888." We also see that the "established port" of 3333 was using a PID of "1888" and that the connection (intruder) was coming from IP address "192.168.97.49." Finally, we see the new process "printspooler.exe" is also tied to PID 1888. The commonality here is the PID of 1888. Thus we can safely say these events are all linked. Though the screenshots in this example are incriminating, having an audit trail of related log events will assist in forensics and trapping the entire process.
Conclusion and Next Steps
We have discussed what a "back-door" is, how they can be used to compromise a system, how to look for and recognize them, and how to tie events together to paint a picture. So, what next? A good security solution should be actionable. In our scenario, the moment a new user was activated, an automated tool should have fired to have it reported or deleted. The moment the new file was dropped on the machine, another action should have taken place to notify staff, determine if it was "authorized," and if not, it should have been deleted or moved to a quarantine location immediately (for review). A simple automated example could look like this: Conditional Action: Was the file dropped outside the maintenance window? TRUE --> Was the file dropped by a legitimate user? --> FALSE --> Delete or Quarantine immediately. Workflows can be more in-depth and include assessments against your CMDB as to whether the file was approved for deployment before you take further action. In our case, the file was not deleted or quarantined, allowing the user to execute the file and creating a back door server. New ports "not" falling within the stated baseline should be dropped. An easy way to kill those ports would be to immediately terminate the new running process/server as it did NOT match our stated baseline. Sometimes there is no chance to check on a new process for validity. Therefore, for security reasons, immediately shutting down the process and analyzing later may be the best practice. Better to safeguard data now then find out you've been successfully compromised later.
Hash Forensics
Remember that file that was dropped? The right security products should be capturing the "hash" value of all files. So what is a hash? A hash value is simply a type of file ID created by a hash algorithm performed on the file that creates a unique set of characters to represent the file or text string. How can we use this? A common task would be to assess whether this new file's hash value is resident on any other system in your infrastructure and to also be on the lookout for further occurrences. Running a "hash" search should be a common task feature of your company's suite of security tools.
Back to Our Story....
"Wow this campground is great! Hun, I am going to take the kids on over to the waterslide while you shop at the onsite gift store... See you in a bit!" Two hours later... "The kids loved the waterslide. Tonight there is a karaoke in the pavilion, this truly is a fun family campground." Cell alert goes off: "Alert! Alert! This is an automated message from your security system. The motion sensor in your basement has been triggered, authorities have been notified." "OMG honey, the basement alarm system has been triggered. Someone is in our home. What do we do?" "But I made sure the door was locked" "It's not the door it's the motion sensor!" "Someone must have broken through another way! We have to pack up and go now!" Are you prepared? Are your systems prepared? Title image courtesy of ShutterStock
