Skip to content

Process Wolf is a command line program that works to rename processes in the Task Manager by changing the names of the EXE files The name comes from the saying “A Wolf in Sheeps Clothing” which represents the tools being disguised to the malware that was trying to find it.

Notifications You must be signed in to change notification settings

elg2605/ProcessWolf

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

7 Commits
 
 
 
 

Repository files navigation

ProcessWolf

Process Wolf is a command line program that works to rename processes in the Task Manager by changing the names of the EXE files The name comes from the saying “A Wolf in Sheeps Clothing” which represents the tools being disguised to the malware that was trying to find it.

For my final project, I started off with the idea to create one or more new software reverse engineering tools with the intention of focusing on defeating anti reverse engineering techniques used in malware. I intended to use the Agile workflow in three-week sprints to accomplish this and to develop multiple tools in the time allotted, however there were only six weeks to complete the project so any delays in either tool would result in one of the tools not being finished, so I ditched the 3-week model early on and focused my efforts on making one tool better.

The tool concept I settled on was a process name scrambler I called Process Wolf. The name comes from the old nursery rhyme where the wolves hid among the sheep wearing a sheep disguised so that the authorities did not detect the wolves hidden in the flock. In this analogy, the malware anti-tool detection algorithms would be the authorities and the wolves would be the reverse engineering tools as the malware is trying to analyze the running processes for tools it determines as threats to it as this would indicate that it is being analyzed by an engineer and will subsequently abort the exploit. I got this idea from a discord account stealer that I had found on Github that was being used by script kiddies to steal discord accounts by masquerading the executable as a game that they were “developing” and proposed that the victim be an early beta tester for the game. They even provided screenshots of other games to prove its authenticity and attached random DLL files with it that upon inspection were sourced from GTA San Andreas, as evidenced by its metadata. However, the scammers left enough information for me to find their Github page for the exploit tool which had a module written in python for anti-reverse software, which had several rather simple techniques for detecting software engineering tools. One of which was to list out all the running processes and grep them for matches to a hard coded list of tool names that it would look for and exit the program if found.

Assuming other script kiddies did similar things for their scripts, I figured I would create a script that attempted to change what the list of running processes output and allow the tools to get through this sophisticated anti-SRE method. The goal was to have the script not be able to properly identify the programs it was looking for as per its source code.

To accomplish this, I began by researching how to mask the process names. This turned out to be harder than I thought it would be as the processes had to have an alias added to them, and then the original program had to kill any running instances of the processes and restart them. This caused problems as it limited me to using the program only when the virtual machine had just been started and not while programs were already running, thus making it prohibitively difficult to create a Ghidra plugin for this tool as the program would have to kill Ghidra to rename the process it was hosted on. Also, this method didn’t have any persistence as the aliases would revert to their original filenames when the virtual machine was restarted. These discoveries were found over the course of several weeks as some weeks I was too busy to devote time to it.

The second method I tried was more successful and I was able to circumvent some of the shortcomings of the alias method, which was to rename the main executable files that the offending applications ran when spinning up. This allowed better persistence as the filenames would exist even after windows crashed or bluescreened, however I needed to come up with a way to store the filenames of the files that were changed so that they could be reversed back into their original states. I did this by storing the data in a CSV file which would contain the original name, the hashed name, and the full file path to the directory that held the file without the filename attached. This CSV file allows the project to have some persistence in it and can always reflect the current state of the machine as the offline method of storing the state allows the database file to roll back with the virtual machine so that the python program always has the most up to date version of the current state. This is by design as an online database would hold information about files and conversions that would not reflect the current state of the machine I the event of a rollback or state change and the necessary changes would have to be synced manually if data was lost or rolled back.

For the file names, I used Base64 to encode and decode the file names as the file names don’t need to be changed in a way that is too complex, just ensure they are not an exact match for the names the malware is looking for. Base64 is a scheme that is easily decoded without a key and can be read by different programs so decoding the hash to get the values is easy for a human, but a hacker would have to specifically protect against this program to bypass it and find the process names anyway. However, the functions to encode and decode base 64 have their own wrapper functions in the program so if someone built a workaround for the rename function, it can be patched to use a different encoder scheme easily and therefore would be trivial for the reverse engineer to change. I wrote a test script to do this conversion on a one to one basis as an early proof of concept, which was later implemented into the final product.

As you can see, you specify the file you would like to change, and it modifies it to use the modified Base64 value name. This particular screenshot is taken from the final product as I added the same functionality into it as a choice for the operator to use if needed. This functionality also allows the user to add additional programs or to remove automatically configured ones if the change created issues. After I created this script to rename files, I combined it with the function that gathered all of the files on the C drive and ran it to see what happened and what I found was that doing this began renaming every file on my windows virtual machine effectively creating my own ransomware virus as it renamed and obfuscated all of my filenames. As I watched it rename anything it could get its hands on, it bluescreened my virtual machine as it had converted some of the system files which crashed the system as essential services tried to open files that, to its perspective, no longer existed. Therefore, to fix this issue, I came up with the idea to have a list of files to look for and convert as I did not want it to ransomware me again.

Once I had restored my virtual machine and had an idea of what I wanted to do, I started planning the script’s architecture and control flow. I knew that I wanted to use a read-evaluate-print loop (REPL) but I wrote up a flow diagram on one of the school whiteboards to help think through the design, as shown below. I created an initialization function that would gather the names of all the existing filenames and compile a list of files based on the list the malware was searching for and then the intention was to automatically convert the filenames adding the conversions to the database automatically however this function ended up being buggy and had to be postponed for later. The REPL loop would continuously loop and request a command from the user which it would execute upon entry, such as “ls” to list the files compiled in the initialization step or “convert” to process one or more files into Base64 format.

I used Windows 10 for the operating system to test on and set up a shared drive between the virtual machine and the host operating system in Read-Only to create a wall between the virtual machine and the host, as the program might affect the script and I did not want my work to be affected. When I was testing it I would modify the script on the host using Visual Studio and run it from a command shell application opened to the shared directory. This is why some of the commands need full file paths as the test directory is in the read-only shared drive.

The results of the program whitelist were that it was successful for identifying files that were related to programs the malware was looking for. After the init program finishes and the Read Eval Print loop starts, the user can use the “ls” command to see the list of programs the initialization sequence identified as potential issues as shown below.

There are a few duplicates, however the program only changes the filenames and not the file extensions so the extensions would remain on the converted files and thus would retain the ability to open them in their default notifications. The program also calculates and stores the hash values of the filenames to be displayed in the REPL using the “ls hash” command as shown below:

Shown above is the exact same list as when seen with “ls” however it has all of the conversion names between the different files. These values are stored in the CSV file used as a database for the program along with the filename as it was before the change and the directory that the file was stored. Thus, as the files are renamed using the tool they disappear from this list as the filenames are not found.

From here the user can pick software to open so that they can still launch the programs they converted. This is because the filenames are obscured so it makes it difficult to find the programs that were changed so a method of launching these files has been added to the program. On the backend, the program simply searches for the program in the list of converted programs and then uses the directory name plus the hashed file name to tell the system to start the program requested.

All of my code will be hosted on GitHub so I can continue to make improvements on it in the future as I would like. I had planned on giving this program some additional features if I had more time to work on it such as adding the program to run automatically at start up by adding a feature to insert itself as a registry key, effectively allowing the user to have the auto conversion run when the operating system starts. Another idea for this script was to write a GUI for it using a framework like QT6 and allowing the user to have the option to see the data in a graphical user interface instead of a text user interface. This would allow the user to select and add files in bulk instead of adding them individually file by file.

All in all, I enjoyed the project I made as I ran into a lot of stumbling blocks and learned some new things along the way. I had a plan and it folded forcing an entire restart and refresh of the core fundamental mechanics of the techniques, and thus the entire program. My original design of this program had it potentially running out of a Ghidra plugin, however after careful review that idea had to be scrapped. This project taught me how to be a better problem solver as I had to experience planning my own project and even pivoting to another plan when plans went wrong. Even though I did not end up with as flashy of a project as some of the other groups, I feel as though I gained a lot of experience and benefitted from the attempt and to me that makes it all worthwhile.

About

Process Wolf is a command line program that works to rename processes in the Task Manager by changing the names of the EXE files The name comes from the saying “A Wolf in Sheeps Clothing” which represents the tools being disguised to the malware that was trying to find it.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages