Hunting Trickbots Instead of Turkeys
Growing up in Pennsylvania, many of my friends would go hunting the days leading up to Thanksgiving. I had always wanted to go, however my family was not big on hunting, so I was never given the chance to give it a go. Since then, I have been hunting numerous times, but still haven’t had the chance to go out before Thanksgiving.That all changed this year, but it wasn’t in the traditional sense with a gun and something I could eat, but to me it was just as thrilling.
This past couple of years we have seen a surge in brutal attacks the days leading up to holiday weekends. Whether it was the pipeline attack leading up to Memorial Day Weekend, or the Kaseya attack leading up to Fourth of July weekend, a trend has emerged that threat actors will strike when frims are understaffed and distracted with their personal lives. This Thanksgiving was my first “holiday” weekend at my new role, so knowing this, I was on edge all week. During the week, I saw a lot more phishing attempt come in with malicious office documents, but nothing more than that. That was until late in the workday on Tuesday
Over the course of the day, I saw a lot of phishing emails coming from compromised email accounts that were trying to pass malicious documents as invoices. Most of our clients reported these and we were able to put rules in place to stop them from coming in. At the end of the day we got a call from one of our clients that earlier that day on of their employees received an email from someone they knew with a document. They had opened it and nothing enable editing, but nothing was in the document, and they moved on. However later in the day they got a call from that person who said their email was compromised, and that was when they reached out.
It was the end of the day when we got the call, so we ran a scan on their Domain Controller, the ETA was 8 hours so we decided to call it a day and I would tackle it first thing in the morning the next day. It weighed on my mind all night, and I logged into their machine right away when I got in on wednesday morning. I check the results of the scan, and there it was… 7 files that the AV wouldnt remove or take action on, however it indicated that it could be from Trickbot.
Killing the Trickbot
Trickbot is a trojan that orginally was used in FinTech attacks to load banking malware, but has recently emerged as a popular attack vector for the Ryuk Ransomware. I have read up a decent amount on this through various info sec blogs and articles. So when I saw the name I knew the risk and knew that I needed to take action immediately. My first step was to research the IoC and the artifacts that it leaves on the machines. I was able to find a great article from Mandiant and another from Crowdstrike on how to identify and remove Trickbot on machines. I began to look through the Domain Controller and was able to locate its processes running as svchost.exe and kill them with SysInternals PSkill. I then began my hunt for its artifcats and found that the files that the Antivirus had identified were not in the normal location of App Data\Roaming, but instead were in a created temp folder in system32. This led me to believe that this could be a variation and a more thorough hunt would be necessary.
I removed the artifacts from the Temp folder and began to look for the persistence methods. In the crowdstrike article it said to check for scheduled tasks, so that was my first place to check. There were no scheduled tasks, but I knew that any threat actor worth their salt would want to establish persistence. In my free time, I have been working through the PEN100 and PWK200 course from OffSec and recently completed a module on establishing persistence through registry keys. I checked and sure enough there were registry keys under HKLM\Software\Microsoft\Windows\CurrentVersion\Run that were to start the same service to maintain access. I removed these from the registry.
One of the malicious DLLs from the Trickbot was a “worm” DLL, so I assumed the worst and assumed it had spread across the connected machines on the client’s network. I went through the proess of manually checking each machine and was able to follow the same steps on those machines to completely eradicate the malware from the network. All of that before I had the chance to have my morning coffee in the office. After the malware was cleaned I made sure to write an email to the client and let them know that they should all be changing passwords and of course to be vigilant and confirm with the sender on another form of communication before opening an unsolicited attachment.
Wrapping Up and Lessons Learned
In my role, I have had some opportunities to deal in incident response, however they usually amount to running an AV scan and the AV taking care of the issue. However this was my first chance to “Threat hunt” on an a production network. During the incident, I learned that although you can identify a threat, you cant just go off of what others have found. Each threat actor is different and adds their own twist to malware, and you need to apply your knowledge and think like a threat actor in order to keep your network safe. After going through and reviewing how I handled the incident, I can see areas of improvement. I realize I was not efficient with my time, after removing the malware off the first machine, I should have written a script to automate the process on the remainder of the machines in order to save my self some time.
This incident while intense and fairly high stakes, was enjoyable in a sense. I found it challenging, but also a confirmation of my progress as an Info Sec professional. I feel as though this incident allowed me to flex the knowledge I have picked up while being able to help prevent something nasty on a client’s network. This incident again also shows that although my title doesnt have a flashy cyber security title, it is still something I am responsible for in my role!