Revealing the Power of Keylogging: Hunting for the Revealer Keylogger
By Lee Archinal at Cyborg Security
BACKSTORY
Recently I was reading an article by the famed Group-IB security team title “OPERA1ER: Playing God Without Permission” about an advanced persistent threat (APT) they dubbed OPERA1ER. It is a lengthy report but very much worth the time I took. There was a section in the report that mentioned the tools that were being used and within the list was the Revealer Keylogger from Logixoft. The report highlighted that the tool could capture not only keystrokes but screenshots of active sessions. Since I have never really analyzed a keylogger from a log analysis perspective, I was very eager to get my hands on it. Upon visiting the website I was immediately presented with this:
I downloaded the free version, launched it in a lab environment and started searching for logs. What I found was SO interesting that I went ahead and bought the pro version, which included the screenshots and the capability to deliver the logs and screenshots via email, cloud storage, ftp, or locally. (See Appendix A for evidence and Appendix B for capabilities)
HYPOTHESES ON THIS KEYLOGGER
Before I really started investigating, I wanted to put some hypotheses together on how I think a keylogger would operate.
First, if an adversary would want continued monitoring, then there would have to be some form of persistence.
Next, since the tool is generating screen shots and a log file, there must be some files being created, but the main question is: Where?
My third and final hypothesis focused on the network logs. There must be a way to find the traffic through network logs that may provide details about where it is going or what protocol is being used.
RESEARCHERS NOTE:
I used Sysmon logs as my log source and Splunk as my SIEM exclusively during this investigation. You YMMV depending on your log sources.
RESEARCH
HYPOTHESIS 1 — PERSISTENCE:
The goal of this hunt was to use a query that would discover if the keylogger used a common method of gaining persistence. The methods I am looking for is activity that modified the CurrentVersion\Run registry key OR placed itself in the Startup folder of the machine.
QUERY 1:
index=sysmon EventCode IN ("11", "12", "13", "14") TERM("*rvlkl*") (TargetObject="*CurrentVersion\\Run*" OR TargetFilename="*Microsoft\\Windows\\Start Menu\\Programs\\Startup*")| stats values(TargetFilename) AS filesCreated, values(TargetObject) AS registryObject, values(Details) AS registryValues, values(ProcessId) AS pid, values(_time) AS eventTimes, min(_time) AS firstSeen, max(_time) AS lastSeen BY Image, Computer, EventCode| convert ctime(eventTimes), ctime(*Seen)| sort firstSeen
The query is looking at Event Codes 11 (File Create) and 12, 13, and 14 which are all registry key related events in Sysmon. We also set the term to be rvlkl which is the executable’s name.
QUERY RESULTS
FINDINGS:
During installation the keylogger did not modify the “CurrentVersion\Run” registry key (we can see that the registryObject column is blank) BUT what we do see is that a .lnk file has been created in the Windows Startup folder, which tells me that persistence has been established. It is safe to say that once our user logs back into this machine the next day our keylogger should start running. As a threat hunter, and really any blue teamer, our job is not done. We need to confirm this activity through another query. Before we do that, we need to understand that when something executes out of the Startup folder, the parent process will normally be explorer.exe. So lets use that knowledge to design our follow on query.
PIVOT QUERY 1:
index=sysmon EventCode=1 TERM("*rvlkl*") ParentImage="*explorer.exe"
| stats values(CommandLine) AS cmdline, values(ParentCommandLine) AS parentCmdline, values(ParentProcessId) AS PPID, values(_time) AS eventTimes, min(_time) AS firstSeen, max(_time) AS lastSeen BY Computer, Image, ParentImage
| convert ctime(eventTimes), ctime(*Seen)
| sort firstSeenHere we set the Event Code to be 1 (Sysmon Process Create event) and set the parent process (ParentImage) to be explorer.exe.
PIVOT QUERY 1 RESULTS:
FINDINGS:
Now that we have our results, we see that explorer.exe is indeed the parent of child process “C:\Windows\System32\rvlkl.exe”. This can 99% confirm that this activity is related. I will say 99% because explorer.exe is the parent when someone opens up file explorer and manually moves to the executable that they want to run it. In the case of a keylogger, it would be very unlikely for the target or compromised individual to run the keylogger on their own (except in the case of research!).
HYPOTHESIS 2 — FILES BEING CREATED BY THE KEYLOGGER:
The second hypothesis focused on the files that the keylogger was creating. This was derived from the idea that if a tool can ship or exfiltrate the files containing the artifacts that were capture, there had to be some files created. That is what this hunt is designed to look for.
QUERY 1:
index=sysmon EventCode=11 TERM("*rvlkl*")
| stats values(TargetFilename) AS filesCreated, values(ProcessId) AS pid, values(_time) AS eventTimes, min(_time) AS firstSeen, max(_time) AS lastSeen BY Computer, Image
| convert ctime(eventTimes), ctime(*Seen)
| sort firstSeenThis hunt is simply focusing on the Sysmon Event Code 11 (File Create) and using the term *rvlkl* (ReVeaLer KeyLogger).
QUERY RESULTS:
This is just a fraction of the results that were returned from the query
FINDINGS:
Over 7 days there were 320 results. Out of all those results we can remove one value that we have already found, and that is the top value “C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\rvlkl.lnk” That was the event that we determined that persistence was established and then our follow-on pivot query confirmed that when looking at the parent-child relationship between explorer.exe and rvlkl.exe.
Looking at the other 319 results we notice that there is a common location that has been created specifically for the keylogger in the ProgramData directory.
PIVOT QUERY 1:
index=sysmon EventCode="23" TERM("*rvlkl*") TargetFilename="C:\\ProgramData\\rvlkl*"
| stats values(TargetFilename) AS filesCreated, values(ProcessId) AS pid, values(_time) AS eventTimes, min(_time) AS firstSeen, max(_time) AS lastSeen BY Computer, Image, EventCode
| convert ctime(eventTimes), ctime(*Seen)
| sort firstSeenNow that we know where the files are, I was also interested to see if they are deleting them as they are created, at a certain interval, or (because the capability exists to schedule an uninstall) if logs were deleted once the keylogger was uninstalled. I used a query that focused on the directory they were being stored with Sysmon Event Codes that
PIVOT QUERY 1 RESULTS:
FINDINGS:
As we can see files are being deleted by the keylogger, an html along with an .xpd file, all from the ProgramData directory. It doesn’t appear to be deleting the other files that contained the user’s name so it is my understanding that we should be able to find these artifacts on the machine whether it be through file explorer or the use of digital forensic tools.
HYPOTHESIS 3 — EXFILTRATION FROM THE KEYLOGGER:
For the final hypothesis we turn to Sysmon Event Code 3, which gathers information surrounding network connections. This includes source and destination IPs and source and destination ports, as well as the process that initiated them.
QUERY 1 FOR THE KEYLOGGER:
index=sysmon EventCode=3 TERM("*rvlkl*")| stats values(SourceIp) AS srcIP, values(DestinationIp) AS destIP, values(DestinationPort) AS destPort, values(ProcessId) AS pid, values(_time) AS eventTimes, min(_time) AS firstSeen, max(_time) AS lastSeen BY Computer, Image, EventCode| convert ctime(eventTimes), ctime(*Seen)| sort firstSeenThis query is broad and is looking to find any data related to network activity coming from rvlkl.exe first, then the focus can be on the results through the pivot queries. But Event Code 3 is being used as well as the term *rvlkl* to catch anything that may exist related to the keylogger.
QUERY RESULTS:
This is just a fraction of the results that were returned from the query
FINDINGS FROM THE KEYLOGGER:
Looking at the results the first value that stands out is 21, or FTP. This could indicate that the keylogger is exfiltrating the results to a remote entity that could use the results to laterally move, gained privilege access, or gain access to credentials. Image in if this was running and I entered my banking information!
PIVOT QUERY 1:
index=sysmon EventCode=3 TERM("*rvlkl*") DestinationPort=21
| stats values(SourceIp) AS srcIP, values(DestinationIp) AS destIP, values(DestinationPort) AS destPort, values(ProcessId) AS pid, values(_time) AS eventTimes, min(_time) AS firstSeen, max(_time) AS lastSeen BY Computer, Image, EventCode
| convert ctime(eventTimes), ctime(*Seen)
| sort firstSeenThe pivot query was designed to focus only on port 21 since we saw that traffic in the results of the last query which would filter out the other ports for now. The reason to focus on port 21 is that the keylogger has the capability to deliver or exfiltrate the data using FTP (see Appendix B).
PIVOT QUERY 1 RESULTS:
FINDINGS:
From this pivot query I was able to determine that there is only one remote IP that our compromised machine is communicating with, and it appears to be in our network. This could all be spoofed but just looking at the IP address it would support the idea that it is internal.
SURPRISE FINDINGS:
This section gathers some data and findings that I discovered while conducting hunts that were not a part of my original three hypothesizes but it was more stumbled upon.
QUERY 1:
index=sysmon EventCode IN ("12", "13", "14") TERM("*rvlkl*")
| stats values(TargetObject) AS registryObject, values(Details) AS registryValues, values(ProcessId) AS PID, values(_time) AS eventTimes, min(_time) AS firstSeen, max(_time) AS lastSeen BY Image, Computer
| convert ctime(eventTimes), ctime(*Seen)
| sort firstSeenThis query is designed to capture any registry key modifications that are related to the keylogger.
QUERY RESULTS:
FINDINGS:
This may have been one of my favorite finds! During installation, the keylogger added itself to the “Windows Defender\Exclusions” registry keys! In a nutshell, if Windows Defender was your tool of choice, this keylogger whitelisted itself along with the .dll file that supports it, which I thought was extremely clever.
APPENDIX B: NON-SPLUNK FINDINGS
DEFENSE EVASION:
The keylogger uses multiple methods to prevent the user that is being targeted from finding it. Below are some of the methods and evidence that supports that they work!
HIDING IN TASK MANAGER:
Task Manager opened without expanding details
the command *tasklist* was executed to find that the proces is running.
If the keylogger is running, it will hide from this portion of task manager but it does show up when the details are expanded and is found in the background processes section:
Details expanded Background processes section
HIDING IN FILE EXPLORER:
Looking at the logs from the queries, we see that the executable is running out of the Windows\system32\ directory, but if we navigate to that location, we cannot find it!
It should exist between RuntimeBroker.exe and rwinsta.exe
HIDES FROM PROCEXP:
Not only does the keylogger hide itself from the two locations mentioned, but if you try to find it using Microsoft Sysinternal’s process explorer, or ProcExp, you won’t be able to find it either.
Screenshot using Sysinternals Process Explorer
INVESTIGATION WRAP UP AND SHOUTOUTS
SO WHAT?
The behaviors that were exhibited by the Revealer Keylogger were interesting to discover but what are the big lessons here and how does this translate beyond the keylogger?
First, threat hunting focusing on behaviors can lead to some unexpected finds. For example, when I was searching for registry key modifications, I thought I would have found evidence of persistence through the CurrentVersion\Run registry key, but I was proven wrong. What I didn’t expect to find was defense evasion using the Windows Defender exclusion list. This technique, dubbed T1112, or Modify Registry, on the Mitre ATT&CK Matrix can be and has been used by many adversaries and now that we have evidence of that technique in action, and we can now keep it in our toolbox for the next research project or incident.
Second, the techniques used in this research varied in the level of specificity, from very general searches to specific queries driven by a hypothesis and goal in mind. While the starting point of a hunt may vary, these are normal actions for a threat hunt, zooming in and zooming out while following the data. A hypothesis driven search should be more specific than a general search, including terms that support the hypothesis, which can be seen in the first query under the persistence hypothesis section. I included the “CurrentVersion\Run” and “Startup” terms because I knew those locations exist and have been abused many times. If that query had not returned results, that is when we could have “zoomed out” and removed some specific terms but still focus on the “File Create” and “Registry Key” modification activity.
Lastly, I had the “luxury” of using the term “rvlkl” consistently through my investigation because I had control of the tool and the environment. This term is more of an indicator of compromise (IOC) that I knew existed, but had it been a real incident and the threat actor renamed it, I would have been able to attribute the activity to the exact tool. In real incidents it is not uncommon for threat actors to rename their tools or change default settings, so looking for specifics could prove to be difficult. That can be overcome by focusing on common behaviors of tools, malware, and threat actors. It is trivial to change IOCs, like file names, tools names, or IPs, but to change the behavior of a tool, keylogger or not, will take a significant amount of time that the threat actor may not want to invest in. In short, focus on behaviors not just IOCs.
CONCLUSION
The Revealer Keylogger Pro was an extremely fun tool to play with, test its capabilities, and discover the tactics, techniques, and behaviors that it uses while in operation. I was able to confirm some hypothesizes about persistence and file creation, discover network activity that existed over FTP but I was also unable to find the tool in the locations that it said I wouldn’t. At this point, I believe that the keylogger is now acting more of a root kit to hide itself within task manager, but that would take some reverse engineering to confirm and that is not what I do!
SHOUTOUTS
I would not have found this tool if it weren’t for the amazing cyber security team at Group-IB. Their report on the APT known as OPERA1OR is extremely thorough and is on my “recommend read” list. You must enter some information about yourself, but it is so worth it. And check out their other reports, they are all very interesting as well.
APPENDIX B: CAPABILITIES OF THE KEYLOGGER
USER FILTERING:
The keylogger can be configured to focus on everyone or just specific accounts.
KEYSTROKES CONFIGURATION:
Enable or Disable capturing keystrokes and edit the way the interface looks (color of text, etc)
SCREENSHOT CONFIGURATION:
DELIVERY METHODS:
FILTERS CONFIGURATION:
SECURITY CONFIGURATION:
