Jump to content

Infected? Undetected Script wscript.exe loading from startup folder


Recommended Posts

This finding was reported just 7 days ago by one other user online, here https://stackoverflow.com/questions/68384585/found-this-script-plus-the-exe-file-in-my-app-data-folder-i-wonder-what-does-th

He suspects it is possibly a keylogger.

Lnk File:

C:\Users\Ty\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ws.lnk

Shortcut points to script+ws.exe:

C:\Users\Ty\AppData\Roaming\WS\ws.exe /E:jscript /b C:\Users\Ty\AppData\Roaming\WS\ws EpmTG6iCDsBeVLWu8agXIy7=9PcM2ftkdFSj4KbhxQ1qrzAn+YoN/3UJR5wv0ZHOl

 

Can someone here determine or explain to me how I can determine the code that is being launched here?

 

 

Edited by Marcos
Malware removed
Link to comment
Share on other sites

Looks like it never got anywhere: Applocker event 8029, thankfully:

C:\Users\Ty\AppData\Roaming\WS\ws was prevented from running due to Config CI policy.

 

Link to comment
Share on other sites

8 hours ago, Tzatz said:

Can someone here determine or explain to me how I can determine the code that is being launched here?

One of the oldest malware methods in existance is to run something from C:\Users\xxxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\ directory. When a .lnk file is dropped there, Windows just refers to whatever the shortcut is pointing to and runs it automatically. The process is identically to what happens when you double mouse click on a desktop icon shortcut, but it is run immediately if located in a Windows startup location.

I monitor anything created in C:\Users\xxxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\ directory with Eset HIPS rules but creation of same is anything but straight forward. For example, there are hidden .ini OS files in that directory that are updated periodically by Windows. I also use another security product that auto blocks .exe, .lnk, etc. from running from this directory.

Edited by itman
Link to comment
Share on other sites

I will also note that it is common for an app to create a folder in C:\Users\xxxx\AppData\Roaming; e.g.  C:\Users\xxxxx\AppData\Roaming\WS\. What is not normal is for an app to drop an executable in this folder.

-EDIT- Finally is creation of the above folder plus creation and use of ws.exe within indicative of malware activity? Appears not according to this write up: https://www.freefixer.com/library/file/ws.exe-306704/ . Ws.exe is one of a number of aliases seen for wscript.exe.

Clever attack I must admit.

Edited by itman
Link to comment
Share on other sites

Also if anyone is wondering what the code following ws.exe that is posted above is doing, per the stackoverflow article:

Quote

The ws.exe program I suspect is just a renamed copy of wscript.exe (as command switches are the same). The ws file is just a JScript with extension removed to make it less obvious (why the shortcut used the Scripting Engine flag /E to force it to treat the ws file as JScript.) You could probably comment out the line new Function(code)(); safely and write the code variable out to a file to see what the decoded script looks like. – user692942 Jul 14 at 20:31

Edited by itman
Link to comment
Share on other sites

18 hours ago, itman said:

One of the oldest malware methods in existance is to run something from C:\Users\xxxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\ directory. When a .lnk file is dropped there, Windows just refers to whatever the shortcut is pointing to and runs it automatically. The process is identically to what happens when you double mouse click on a desktop icon shortcut, but it is run immediately if located in a Windows startup location.

I monitor anything created in C:\Users\xxxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\ directory with Eset HIPS rules but creation of same is anything but straight forward. For example, there are hidden .ini OS files in that directory that are updated periodically by Windows. I also use another security product that auto blocks .exe, .lnk, etc. from running from this directory.

TX I added this to eset HIPS. Nice especially for forensics, I never saw this drop on my pc a week ago. It was just by chance I found it just browsing around, and most wevt logs were since truncated. Immediate detection will be useful for forensics and response + I will know if this was due to a downloaded file or a remote attacker.

I noted that ws.exe is microsofts wscript, there is a pay load in the first string of the ws file, its relatively large,  its 14,780 characters, but obfuscated, so I can't tell what it is trying to execute. I suspect it does something like disables defender & installs a payload. Or if it is a state actor, hardware persistence.

Given its persistence for the other user who deleted those files, I am leery of it infecting my firmware or psp, so if I attempt experimenting running this, I will turn off the internet first.

I was pondering setting it up as an automated batch file and send it to hybrid-analysis.

Edited by Tzatz
Link to comment
Share on other sites

Yes quite clever, Kapersky was the only av software to accurately detect this. https://www.virustotal.com/gui/file/feeb34bc3dcd25baaa5c3d7c012e85411042802ab0ba44100a10731061bb701b/detection

Oh, now since yesterday, two ... check points zone alarm as well.

Edited by Tzatz
Link to comment
Share on other sites

7 hours ago, Tzatz said:

there is a pay load in the first string of the ws file, its relatively large,  its 14,780 characters, but obfuscated, so I can't tell what it is trying to execute.

Given the size, I suspect this was node_js malware. You can search the web on its use and deployment.

7 hours ago, Tzatz said:

Oh, now since yesterday, two ... check points zone alarm as well.

Eset finally and now also detects it by signature. Since this was only seen on VT yesterday, I guess we can give Eset a "pass" as far as sig. detection goes.

This also gives me a chance to "rant" a bit.

One of the first requests I made in the forum after I started using Eset back in 2014 was in regards to the HIPS lack of filename wildcard support. This was specifically addressed to the desire to create a HIPS write monitoring rule for;

C:\Users\xxxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\*.lnk

Despite repeated assurances by Eset such capability would be provided in a future release, the capability still doesn't exist in current Eset versions.

Edited by itman
Link to comment
Share on other sites

  • Most Valued Members
1 hour ago, Nightowl said:

Just to note , Checkpoint uses Kaspersky engine hence why they both detect it.

Really? Is that a recent thing? Years ago I used zonealarm which is part of checkpoint but I always thought they had their own engine

Link to comment
Share on other sites

4 hours ago, peteyt said:

Years ago I used zonealarm which is part of checkpoint but I always thought they had their own engine

The free version of ZoneAlarm definitely has been using  the Kaspersky engine for a while: https://www.pcmag.com/reviews/check-point-zonealarm-free-antivirus-plus .

The paid consumer and enterprise versions use more Kaspersky components: http://svendsen.me/worried-checkpoints-use-kaspersky-products-heres-disable-remove/

Link to comment
Share on other sites

  • ESET Insiders
On 7/22/2021 at 9:18 AM, itman said:

One of the oldest malware methods in existance is to run something from C:\Users\xxxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\ directory. When a .lnk file is dropped there, Windows just refers to whatever the shortcut is pointing to and runs it automatically. The process is identically to what happens when you double mouse click on a desktop icon shortcut, but it is run immediately if located in a Windows startup location.

I monitor anything created in C:\Users\xxxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\ directory with Eset HIPS rules but creation of same is anything but straight forward. For example, there are hidden .ini OS files in that directory that are updated periodically by Windows. I also use another security product that auto blocks .exe, .lnk, etc. from running from this directory.

For us non IT types, how bad is Eset protection if you feel the need to have to do this? 

Link to comment
Share on other sites

11 minutes ago, NewbyUser said:

For us non IT types, how bad is Eset protection if you feel the need to have to do this? 

As far as I am concerned, Eset should have been flagging creation of .lnk files in Win auto run startup locations eons ago; at least in the consumer product versions. Corps. might be manually creating such references, but I know of no commercial software that does so.

See the problem here is Eset for the most part is a "one solution fits all" product. The only recent concession Eset made originally for the consumer versions was its ransomware protection. And recent postings have questioned its effectiveness against 0-day ransomware.

Link to comment
Share on other sites

Hybrid Analysis is not accurately running the script I created, which is attached. I don't understand. It should also list underneath some variation of the following:

START %TEMP%\ws.exe /E:jscript /b %TEMP%\ws EpmTG6iCDsBeVLWu8agXIy7=9PcM2ftkdFSj4KbhxQ1qrzAn+YoN/3UJR5wv0ZHOl

 

This command seems to work on its own when I run it in windows. I see ws.exe loaded with the commandline above. CrowdStrike is ignoring this.
 

Free-Automated-Malware-Analysis-Service-powered-by-Falcon-Sandbox-Viewing-online-file-analysis-results-for-payload-bat-.png.1e8413997d9ad7bf0e94c0b29d34520a.png

I ran this script in sandboxie and it stated that it attempted to connect to the internet; hybrid analysis does not want to execute the final command which initiates the payload. I had a DOS immediately after uploading it to H.A, my internet went down shortly.

VT analyzes the plain old original ws script, and is smart enough to automatically execute it with wscript.exe, however there seems to be a key or a signature in the .lnk shortcut that is required for the js to execute properly. I tried varying commands recommended on stackexchange but I did not see any output log or data. So I created my own batch script with the payload and ws.exe embedded within it, drops them to the temp folder and then executes the original string in the .lnk
 

C:\Users\Ty\AppData\Roaming\WS\ws.exe /E:jscript /b C:\Users\Ty\AppData\Roaming\WS\ws EpmTG6iCDsBeVLWu8agXIy7=9PcM2ftkdFSj4KbhxQ1qrzAn+YoN/3UJR5wv0ZHOl

My script uses:

START %TEMP%\ws.exe /E:jscript /b %TEMP%\ws EpmTG6iCDsBeVLWu8agXIy7=9PcM2ftkdFSj4KbhxQ1qrzAn+YoN/3UJR5wv0ZHOl

What works on my computer does not execute on Hybrid Analysis:

Command.thumb.png.94a4e8c628ebe4e0ebd0077d6da8ee05.png

Any idea how I can get Hybrid Analysis  to actually execute this malware for analysis?

payload.zip

Edited by Tzatz
Link to comment
Share on other sites

Ok got it working by simply pointing the batch to windows 7's internal wscript.exe instead, here are the results:

https://analyze.intezer.com/analyses/6a7b919d-7f40-4019-9e6b-7f6bc7c5be89

It connects to a command and control center at hxxp://api.backend-chat.com/connect likely to grab a prepared payload of sorts, likely mimikatz or meterpeter, to further exploit the machine, perhaps based on the machines characteristics. It may query the machine possibly for anti-virtualization. The target url has no malicious data associated with it suggesting this could be a very targeted and or fresh attack, the C&C is probably quite new.

Here are a few things it does:

  1. Command and Scripting Interpreter :: Unix Shell
  2. Hide Artifacts :: NTFS File Attributes
  3. Query Registry
  4. System Information Discovery

here are the results, click TTPs, IOC's, and Behavior: (References to certutil or"Ingress Tool Transfer" are just my addition in order to create a script that worked on these machines)

https://analyze.intezer.com/analyses/6a7b919d-7f40-4019-9e6b-7f6bc7c5be89

 

Edited by Tzatz
Link to comment
Share on other sites

Obviously, something ran on the device that created the WS directory in C:\Users\xxxx\AppData\Roaming\ and dropped ws.exe there. This something also created the .lnk entry in C:\Users\xxxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\ for persistence to run ws.exe at system startup time.

Forensic analysis would have to be performed to trace back system events that took place just prior to the above creation activities to determine the source of these activities.

-EDIT- Also a review of the original stackoverflow posting:

Quote

I recently found a WS folder with in my app data folder, containing a "ws.exe" file, with a script file in the same folder, also there is shortcut added to my startup folder with below command. I've deleted the entire WS folder plus the start up shortcut but it will come back to my computer in my next reboot. Can anyone help me to analyze this script and let me know what does it do?

Notice what I underlined. There is other malware on this device that is causing the initial attack malware to be recreated at system startup time. I suspect this other malware is related to the remote connection you discovered which recreates the initial attack malware. This other malware could also be a rootkit, or other malicious driver, or a Windows service.

-EDIT- Reviewing this: https://analyze.intezer.com/analyses/6a7b919d-7f40-4019-9e6b-7f6bc7c5be89 , I believe the source of the malware is WMI based; a consumer event or command script. This is why it keeps reappearing after manual deletion of WS directory in C:\Users\xxxx\AppData\Roaming\  and the .lnk file in C:\Users\xxxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\ . You might want to use SysInternals Autoruns and see if anything shows after selecting the WMI tab.

I will also again note that if .lnk file creation was being monitored in the Win auto run startup locations, this would also assist in determining the source of the file creation activity.

Edited by itman
Link to comment
Share on other sites

I also strongly recommend you run an Eset scan. It by default will scan WMI and registry areas for malware entries. No guaranty it will find this bugger, but it's a start.

The next step would be to run WMILister that can be downloaded here: https://www.xednaps.com/2018/05/06/wmilister/ . This utility was developed by Eset's @JamesR

Link to comment
Share on other sites

Here's another interesting development. Eset, Kaspersky, and now Ikarus detect this keylogger at VT, but Checkpoint no longer does. Makes me wonder "if there is more to this than meets the eye."

Edited by itman
Link to comment
Share on other sites

  • ESET Insiders
2 hours ago, itman said:

Here's another interesting development. Eset, Kaspersky, and now Ikarus detect this keylogger at VT, but Checkpoint no longer does. Makes me wonder "if there is more to this than meets the eye."

MS is also detecting it now as TrojanDownloader:Win32/Nemucod!ml

Link to comment
Share on other sites

  • Most Valued Members

  

14 hours ago, itman said:

Here's another interesting development. Eset, Kaspersky, and now Ikarus detect this keylogger at VT, but Checkpoint no longer does. Makes me wonder "if there is more to this than meets the eye."

 

Happened with me a while before , I sent the file again and Checkpoint came back , I did it now again , it seems not , but should be detecting it as they are using Kaspersky AV engine

Should be detected as same name as Kaspersky naming.

Edited by Nightowl
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...