Suspicious Recipe App

Hello World! Let me introduce you to Tampered Chef.

 Yesterday I came across the following article Malvertising Alert: Recipe App Hijacks Credentials and Appears to Establish C&C Connection.

This got me a bit curious, so I decided to dig a bit deeper. I manually went to recipelister (VirusTotal)  and downloaded recipelister.exe. After reading the aforementioned blog, which observed the 7z-out folder, I figured why not 7zip extract recipelister.exe. Within this was app-64.7z, which I again extracted. At this point we have the main contents of what would appear in "AppData\Local\Temp\2w1rXpxZnwDUwuTeNvdD6FUkeI0". 

Extracting app.asar:

In order to extract app.asar to be easier to look at, I used this 7z asar plugin. 

This is where things get interesting. When we start looking at main.js, all the while running Fiddler, we  observe a lot of suspicious code and activity. 

The main.js file starts with some interesting decode functions.

This is rather interesting as it takes Unicode characters which normally do not display as text, converts them to binary 1's and 0's and performs various operations, including converting to and from base64, decrypting with hardcoded AES key, and deriving the tag and other parts of the AES decrypt from the ciphertext, then if successful, it decompresses the data. 

In Fiddler this looks like the following image, which clearly shows the Unicode characters in the request to be decoded:

So What does it do with this decoded data? Unfortunately I have yet to find a part to decode successfully. Even with writing some custom Python decoders, using CyberChef and finally launching 

Recipe Finder - Recipe Lister.exe --inspect (which allowed me to inspect the code as follows)

What I learned from inspecting the code, is that the requests keep coming, and keeps looping through the decode functions. Obviously each time the nonce, buffers, ciphertext, and tags are different, but the hardcoded key is the same. I ran this for at least an hour, each time it hit the exception when attempting to return the decipher.final... Instead catching return null.

So what would it do if it hit a request the returned true? Well we can make some educated guess based on more code in main.js. Including this part which describes finding and executing stegnographic content.

If this fails it falls back to original clean data response from the API call. There are a couple other interesting and suspicious items in main.js. Including much of the "Close Window Event" being commented out, what happens here is that when you close the windows (and prompted if you want to exit) it appears closed, however, process hacker, and fiddler show the process still running. 

One final note on main.js. Dev Tools are disabled in multiple spots. However, like I stated previously, you can launch this with the --inspect parameter.

Some quick final notes. Running Procmon, didn't really give me any new data about this. I know it creates a AppData\Roaming\recipe-finder directory, containing it's own chrome based content such as code cache. 

I know it launches with a command line that points to the roaming directory. However, I don't see any obvious persistence, after reboot, the application is not running, not did I see any tasks or registry keys created for persistence. 

At the moment, nothing "malicious" has occurred while running this app... Even when I looked up a recipe, watched the associated YouTube video, or downloaded the PDF, I didn't observe anything malicious. The PDF is clean, no javascript, no auto-open, no embedded objects. 

What am I to make of this? That the correct request needs to be made in order for the decrypt to work and the stegnographic functions to work? Maybe someone controlling the server-side can "flip a switch" at some point when enough people have downloaded this and then the requests will start running these functions? Maybe this will never run anything malicious. I have looked at all the DLLs in the sample I have, and so far none of them appear malicious.

Minor updates: Additional sites with this campaign include lookupkitchen[.]com and fast-forks[.]com

Another site Layer8Security posted about this. Specifically hitting the healthcare industry. I never saw the other domains outlined in their blog being called in my lab.

Another fantastic analysis of this campaign can be found on Malware Analysis with Dingus

Quick IOCs:

RecipeLister.exe: 1619bcad3785be31ac2fdee0ab91392d08d9392032246e42673c3cb8964d4cb7

Forks.exe: d8bff72de51213510004a2652b9e31b48a25e2eb0d7184fab4ef9014fc85e145

lookupkitchen.exe: 4331c79e34c13857f419448cfdad67c1216f90d27629514ca6ad3281592a4dbf

main.js: 9f369e63b773c06588331846dd247e48c4030183df191bc53d341fcc3be68851