…And just like that, it happens! You get the call you've been dreading... A user is complaining their machine is running slow and items keep popping up. During the troubleshooting discussion, you discover the critical mistakes that were made.
[MISTAKE 1] A user opened a file from a personal thumb drive that was given to them from a family member for a school project.
The first thing you are thinking is "where's the file and thumb drive?" Continuing the conversation, the user reveals the file was a MS Word Document (.docx), they’ve already deleted the file from the computer, emptied the trash can, and took the thumb drive home.
As confident as you are in your anti-virus, you are wondering if this thumb drive included some unidentified executable, in which the docx file called and installed, or worse reached out somewhere in the world and downloaded a random file. Right now, the only things you know is the following:
User opened up a personal file
The file came from a personal thumb drive
The file is a word document
This happened 48 hours ago
There was no A/V or Network Alerts
The system is experience high processes
[MISTAKE 2] Assuming your network is not breached. Many administrators focus on the infected system because of user pressure and make network investigations secondary. Any potential infection must trigger a network investigation and add a deployment of additional monitors for any infected system to post remediation.
[MISTAKE 3] The most common first steps are making sure the latest A/V patches and system updates are installed, restarting the system, and running a full virus scan. This could take another 30-60 minutes (or more) if the administrator is not distracted. This basic troubleshooting time is giving potential threats and hackers more time to embed themselves deeper into your environment. Today, smart hackers don't smash and grab data; rather attempt to setup a hacker paradise using custom root kits, key loggers, and scrappers wherever and whenever they can. So what should you do? Hang up the phone, turn off your remote desktop to the user, and manually unplug the system if on premise.
[MISTAKE 4] You have to assume the worst so take nothing off the table. Chances are your network, various systems, and user credentials are compromised. Before you travel to the system, you need to take the keys away to your data and disable/change all network credentials from this user. If this system IS compromised, then you have to consider all credentials are as well. Doing this in unison insures the user can no longer connect to your network and prevents any threats from using those credentials.
[MISTAKE 5] Not explaining to the user that if they logged into a personal email account, banking, or social media portal recently chances are these services are compromised and they must change their password from a different PC that never used the thumb drive.
[MISTAKE 6] The investigating administrator needs to make clear to the user that the thumb drive is suspect and that the user needs to notify those other networks or systems that the thumb drive was shared with. For example: home, school, friends, or other other business. Chances are each of those systems and networks are compromised. Additionally, once the threat is discovered, the investigating administrator needs to provide the threat details to the end user so they can provide this information to other victims. If you do not share this information, there is a chances this can happen again.
[MISTAKE 7] Do not take the computer to a test bench. It is very customary to not disrupt the user's day-to-day business and move it to a test area, which would require turning the system off. It is important that the system is NOT rebooted immediately. Valuable information can be lost if the system is restarted. At this point, we want to gain as much information on what has infected this system so we need to look at local system logs on the system in question.
[MISTAKE 8] You start looking at logs on the infected systems. You choose to sift through Windows Event Manager and you discover auditing is not very revealing. Unless you plan on dissecting compiled files, your not going find anything on the local system at this point that will provide any silver bullet. Many administrators get stuck in the mud trying to find things of these infected systems to get the user going. The more important thing, at this point, is the bigger picture and you must confirm your network has not been compromised. The infected system is isolated and can not cause anymore damage. Get its IP address, mac address, machine name, and get started on identifying what this system has been doing on your network. Trying to confirm there is a virus first is the wrong place to start. None of your security measures have identified this possible threat.
[MISTAKE 9] When the investigation begins, it always seems to start at the firewall logs. They look at the the source IP address and begin sifting through connection data. Unless you have a device like PacketViper that provides immediate IP details, you will get stuck in the mud scouring through egress IP data.
[MISTAKE 10] You decided to not store a great deal of connection data on your firewall because you felt 48 hours was enough time to find problems.
[MISTAKE 11] Because it's vital to understand where and what the infected computer was reaching out to first, your investigation should start at the switch. I can not tell you how many times I found limited to no logging on core switching. One of the main reasons is the shear amount of logging involved. For the one or two times a year this logging may be needed, it could be the difference of days to weeks for threat discovery. Also, looking at just the firewall logs from the original infection point is only going to show egress traffic from that machine. If the potential threat has embedded itself in other systems, the firewall will only show you a part of the story.
You have to think like the hacker. Remember, hackers have already resigned themselves. They know that once the exploit is launched, they only have a small window to bury deep into an environment. So today the smash and grab data approach is for the misinformed hacker, while state sponsored and more sophisticated hacker groups goals are to build networks within networks.
Don't get stuck on cleaning the PC first! Isolate the PC quickly because valuable time is ticking by. You are responsible for the business network as a whole so think in those terms. Also, you have short term thinking with logging. While it's true that too much logging can cause network blindness and delays, not enough logging has dire consequences as well.