If you haven’t read Part 1, this part might be a bit confusing
Upon further analysis and some cross referencing, I soon realized that the sample I was analyzing (at least the svchost injected process) was in fact a variant of Tofsee, rather than an adware variant of Graftor, I will explain why further on 🙂
I first ran the original file, and waited for svchost to be spawned. I then attached x32dbg to it – causing the process to stop due to an anti debug method which detected if a debugger was attached to the process. So I restarted the process in an attempt to get past the anti-debug method, which was not incredibly helpful. I found a certain function that caused the process to exit due to the attached debugger, so I decided to analyse that. I noticed a function that is sometimes used for anti-debugging: QueryPerformanceCounter. This call checks timing between certain functions, and so if you are single stepping through an executable, QueryPerformanceCounter will be able to detect that a debugger is attached.
I attempted to attach a breakpoint after the call to QueryPerformanceCounter, however it still kept exiting the process, so I decided to change up my analysis method. I ran the sample, and suspended it shortly afterwards using ProcessHacker. Using ProcessHacker, I was able to view the memory of the executable, which is what helped me to notice that this sample was in fact a variant of Tofsee rather than Graftor. I found several interesting things looking through the regions of memory, including what looks like an embedded executable, as well as strings that would possibly be sent to victims through emails:
As you can see from the strings, it looks like %NAME is just a placeholder. I also located a long list of first and last names, which could be what swaps out %NAME. So this variant seems to be able to dynamically create emails on the fly, hence why the executable is 14 MB large – it contains lists upon lists of names, email lines, pick up lines and domains as well. What I also noticed was a list of Google Drive Document links, however when I tried to access a few of them I got 404’d. Perhaps this sample could be using Google Docs to exfiltrate data?
Not only did I find strings containing %NAME, I also found URLs that also seemed like they would replace a %DATING_URL. This makes me think that the malware devs registered all of the URLs that are embedded into this, yet none of the sites are up? What is the point of putting useless URLs in spam emails? But hey, I’m not the one writing the malware, it’s not up to me.
What tipped me off into realizing that this sample was in fact a Tofsee variant was the appearance of these strings in memory:
Upon further inspection into these plugins, I came across a post by CERT POLSKA detailing the modules that are part of Tofsee. Whilst these strings were stored in memory, I do not believe that they had been installed on the system yet, and were there for when the DLLs had been downloaded. So this sample was a lot more complex than I had thought it was, and because I am still a beginner/intermediate at Reverse Engineering I was unable to perform in depth analysis – hopefully someday I’ll be proficient enough!
Stay updated on new course releases and related InfoSec content