So we don't actually use WinRar in any official capacity at my company. However, I work in InfoSec and noticed we had a couple of endpoints running base64 obfuscated powershell around a week or so...
Exemplary
So we don't actually use WinRar in any official capacity at my company. However, I work in InfoSec and noticed we had a couple of endpoints running base64 obfuscated powershell around a week or so ago. Naturally that flagged all kinds of alerts in our EDR and I began an investigation. This is related I swear.
Turns out the endpoitns were running curl against a compromised server, which was serving up vulnerable version of WinRar. I did not know about the 0-day at the time. Either way, I killed that shit immediately and we re-imaged the machines.
When I let the "malware" run in my sandbox VM in my homelab - note I did not actually download the malware, I just re-ran the base64 encoded powershell LOL. Thats when I noticed the command was hitting the site with WinRar being offered. Then the same script hit another site that was hosting a different powershell script. Which, when curl'd would pull it down locally, kill the existing powershell session and then fire up a Windows Command Prompt to then initiate powershell from the command prompt. Really odd stuff. Once the new powershell session was running it tried disabling powershell logging via registry edit before actually trying to install WinRar to a temp directory.
It all seemed really odd that it was downloading WinRar to a temp directory. I was like "wtf are they going to do with WinRar?"
Until I was able to look at the base64 encoded powershell script (different from the initial). From there I could see the powershell command was actually adding the payload to exploit the 0-day. Then a few days later and I get some CTI from our vendor about a WinRar 0-day and realized what we had witnessed.
The bug itself is an interesting one: Do people still use WinRAR? Serious question. It’s still around and actively developed, since they patched the bug. So there must be some amount of people...
The bug itself is an interesting one:
"The vulnerability is related to the fact that when creating a RAR archive, you can include a file with alternative data streams, the names of which contain relative paths," BI.ZONE said. "These streams can contain arbitrary payload. When unpacking such an archive or opening an attached file directly from the archive, data from the alternative streams is written to arbitrary directories on the disk, which is a directory traversal attack."
I just downloaded a romhack the other day (Mario Kart 64 Amped Up) and they used a rar file to package it. I feel like I haven't seen one in years. But I extracted it on linux.
I just downloaded a romhack the other day (Mario Kart 64 Amped Up) and they used a rar file to package it. I feel like I haven't seen one in years. But I extracted it on linux.
So we don't actually use WinRar in any official capacity at my company. However, I work in InfoSec and noticed we had a couple of endpoints running base64 obfuscated powershell around a week or so ago. Naturally that flagged all kinds of alerts in our EDR and I began an investigation. This is related I swear.
Turns out the endpoitns were running curl against a compromised server, which was serving up vulnerable version of WinRar. I did not know about the 0-day at the time. Either way, I killed that shit immediately and we re-imaged the machines.
When I let the "malware" run in my sandbox VM in my homelab - note I did not actually download the malware, I just re-ran the base64 encoded powershell LOL. Thats when I noticed the command was hitting the site with WinRar being offered. Then the same script hit another site that was hosting a different powershell script. Which, when curl'd would pull it down locally, kill the existing powershell session and then fire up a Windows Command Prompt to then initiate powershell from the command prompt. Really odd stuff. Once the new powershell session was running it tried disabling powershell logging via registry edit before actually trying to install WinRar to a temp directory.
It all seemed really odd that it was downloading WinRar to a temp directory. I was like "wtf are they going to do with WinRar?"
Until I was able to look at the base64 encoded powershell script (different from the initial). From there I could see the powershell command was actually adding the payload to exploit the 0-day. Then a few days later and I get some CTI from our vendor about a WinRar 0-day and realized what we had witnessed.
The bug itself is an interesting one:
Do people still use WinRAR? Serious question. It’s still around and actively developed, since they patched the bug. So there must be some amount of people still paying for it?
Yes, tons and tons of people don't know about 7-Zip and are still using WinRAR.
I think there are also people who know about 7-Zip but just like WinRAR more and use it instead.
I just downloaded a romhack the other day (Mario Kart 64 Amped Up) and they used a rar file to package it. I feel like I haven't seen one in years. But I extracted it on linux.
My laptop came preinstalled with WinRAR, so I just use it. it works perfectly so I've no reason to switch to 7zip