Interesting Samples

[itman 1,659]

2 hours ago, 0xDEADBEEF said:

And it bypassed my non-physical testing machine  

Play with malware and sooner or later, you'll get burnt.

[0xDEADBEEF 43]

1 minute ago, itman said:

Play with malware and sooner or later, you'll get burnt.

Trying my best to build isolated environment, including my physical testbed  

[0xDEADBEEF 43]

6 minutes ago, itman said:

This one appears to be hijacking a valid 32 bit .dll, cl3d32.dll, which is located in the SysWOW64 directory. Appears ransomware .exe is 32 bit.

Interesting. I will grant the sample to run for a longer time in the virtual env and see if I can observe that

[itman 1,659]

13 minutes ago, 0xDEADBEEF said:

Interesting. I will grant the sample to run for a longer time in the virtual env and see if I can observe that

Also check your permissions on C:\MSOCache. Your Eset event log indicates that the ransomware was running out of that directory. On my Win 10 build, files within that directory are read only. Also anything in that directory appears to be related to Microsoft software installations e.g. MS Office.

FYI -

Quote

The MSOCache is essentially there to allow you to install additional office components/features. You can delete it using the included Microsoft's cleanup.

Start> All Programs> Accessories> System Tools> Disk Cleanup      

https://www.tenforums.com/performance-maintenance/43220-msocache.html

Edited August 25, 2017 by itman

[itman 1,659]

Also look closely at Eset log. Every file deletion is a different file hash! Almost as if you were subjected to a DDoS ransomware attack? This one is interesting indeed.

Edited August 25, 2017 by itman

[0xDEADBEEF 43]

37 minutes ago, itman said:

Also check your permissions on C:\MSOCache. Your Eset event log indicates that the ransomware was running out of that directory. On my Win 10 build, files within that directory are read only. Also anything in that directory appears to be related to Microsoft software installations e.g. MS Office.

FYI -

https://www.tenforums.com/performance-maintenance/43220-msocache.html

The test machine for that screenshot is a bit special (UAC disabled and admin granted, similar to a typical Cuckoo machine setup). Will check on another machine. 

Usually when I see ESET popping up tens of messages, I know it fails to stop a ransomware (those messages are usually for some ransom notes). This one is, however, a bit more interesting. But I haven't got a time to do any behavioral analysis on it yet.

Edited August 25, 2017 by 0xDEADBEEF

[itman 1,659]

24 minutes ago, 0xDEADBEEF said:

he test machine for that screenshot is a bit special (UAC disabled and admin granted, similar to a typical Cuckoo machine setup). Will check on another machine. 

Well if you give admin privileges to malware, it is the equivalent to giving the keys of the bank to a robber. 

[itman 1,659]

I am also a bit confused by the way you're doing your testing. You should be configured with Win default settings; on Win 10 that would be local admin and UAC set to default; notify when app attempts to change computer settings.

[itman 1,659]

Appears you got nailed by a new variant of Stampado, Philadelphia, or Fantom : https://www.bleepingcomputer.com/forums/t/620794/stampado-ransomware-help-support-locked-scvhostexe/ . It appends the .locked suffix to the encrypted files. The previous version appears to run at startup time via this registry key:

Quote

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Windows Update    %UserProfile%\AppData\Roaming\scvhost.exe

Also notable is not one of the Next Gen/AI solutions at VT are detecting it at this time but most of the major AV's are. Makes me believe this is scripted based; perhaps PowerShell?

Edited August 25, 2017 by itman

[novice 20]

On ‎8‎/‎19‎/‎2017 at 5:16 PM, malkil said:

latest detection 

 

https://www.virustotal.com/#/file/cf9a800c3b009abed68a684aaf2f8cad7793b930fc323a2a2231edd5e8c3747b/detection

ESET detects the item in the "latest detection" as Win32/Agent.ZCK and NOT as "heuristic" ( see most of the detection which are Generic/Heuristic)

That means this is signature based and sure enough , the signature was created on Aug19, 2017 ,detection database version 15941, basically after the OP mentioned in this thread.

hxxp://www.virusradar.com/en/Win32_Agent.ZCK/description

Most of the detections on VT were "generic, 80%-100% confidence" or "heuristic"

This is quite disappointing.

 

Edited August 26, 2017 by John Alex

[itman 1,659]

3 hours ago, John Alex said:

ESET detects the item in the "latest detection" as Win32/Agent.ZCK and NOT as "heuristic" ( see most of the detection which are Generic/Heuristic)

That means this is signature based and sure enough , the signature was created on Aug19, 2017 ,detection database version 15941, basically after the OP mentioned in this thread.

hxxp://www.virusradar.com/en/Win32_Agent.ZCK/description

Most of the detections on VT were "generic, 80%-100% confidence" or "heuristic"

This is quite disappointing.

 

Marcos previously explained how Eset detects.

If Eset's internal heuristic analysis detects an issue, the file is uploaded via LiveGrid for more detailed analysis. If cloud based LiveGrid heuristic analysis detects an issue, the file will be added to Eset's internal blacklist. That is as long as there isn't a Livegrid "hiccup" as noted previously in this thread. As such, none of the public malware scan sites that use Eset will show any detection other than by signature since they only employ the Eset AV realtime engine and not LiveGrid nor the Eset internal blacklist detection.

The question I have is if malware can disable your Internet connection so that LiveGrid communication is not possible, will Eset's internal heuristics detection auto blacklist the file? I believe this is not the case based on Eset's statements that LiveGrid enabling is required for effective ransomware protection for example.

Edited August 26, 2017 by itman

[peteyt 393]

2 hours ago, itman said:

Marcos previously explained how Eset detects.

If Eset's internal heuristic analysis detects an issue, the file is uploaded via LiveGrid for more detailed analysis. If cloud based LiveGrid heuristic analysis detects an issue, the file will be added to Eset's internal blacklist. That is as long as there isn't a Livegrid "hiccup" as noted previously in this thread. As such, none of the public malware scan sites that use Eset will show any detection other than by signature since they only employ the Eset AV realtime engine and not LiveGrid nor the Eset internal blacklist detection.

The question I have is if malware can disable your Internet connection so that LiveGrid communication is not possible, will Eset's internal heuristics detection auto blacklist the file? I believe this is not the case based on Eset's statements that LiveGrid enabling is required for effective ransomware protection for example.

So from what i gather if a file is detected as possibly suspicious livegrid will upload those files and eventually a signature will be updated?

[itman 1,659]

@0xDEADBEEF, here's another one that Eset detected earlier this month using the same Win32/Filecoder.NMK signature:

SHA256: 1c0ffdaddec1eca9a9a5ef5192151dbce8ccd8e31a84c51d70f5a5c64f07a363

This again leads me to believe your current sample was delivered via some type of obfuscated script.

 

[novice 20]

15 hours ago, itman said:

If Eset's internal heuristic analysis detects an issue, the file is uploaded via LiveGrid for more detailed analysis. If cloud based LiveGrid heuristic analysis detects an issue

Why do you think there is a difference between  internal heuristic analysis and LiveGrid heuristic analysis ???

If there is a heuristic algorithm, I do not see a reason to be different.

[Marcos 5,070]

Not sure what you mean by "LiveGrid heuristics". As for internal analysis, samples are run on replicators and we use various systems, including machine learning to asses if a sample is malicious or innocuous.

[novice 20]

3 hours ago, Marcos said:

machine learning

What exactly is "machine learning" , other than 

 

[Marcos 5,070]

2 hours ago, John Alex said:

What exactly is "machine learning"

https://www.welivesecurity.com/2017/06/20/machine-learning-eset-road-augur/

[novice 20]

Thanks for the informative post

[itman 1,659]

The best article in series in my opinion is: https://www.welivesecurity.com/2017/04/18/pr-reality-collide-truth-machine-learning-cybersecurity/ which I refer to as the Next Gen GI-GO article.

[0xDEADBEEF 43]

On 8/26/2017 at 1:26 PM, itman said:

@0xDEADBEEF, here's another one that Eset detected earlier this month using the same Win32/Filecoder.NMK signature:

SHA256: 1c0ffdaddec1eca9a9a5ef5192151dbce8ccd8e31a84c51d70f5a5c64f07a363

This again leads me to believe your current sample was delivered via some type of obfuscated script.

 

I've been offline for a while to debug that sample in my testing env, because my cuckoo failed to capture its behaviors. And later I realized it is crashing most of the processes (including cuckoo's agent) when doing manual check, indeed an interesting one. Looking forward to seeing that cuckoo will gradually move from R3 hooks to more reliable ones

Edited August 28, 2017 by 0xDEADBEEF

[itman 1,659]

11 hours ago, 0xDEADBEEF said:

I've been offline for a while to debug that sample in my testing env, because my cuckoo failed to capture its behaviors. And later I realized it is crashing most of the processes (including cuckoo's agent) when doing manual check, indeed an interesting one. Looking forward to seeing that cuckoo will gradually move from R3 hooks to more reliable ones

Since you let the malware run with admin privileges, it literally could have done anything.

One example if employed by the malware is PsExec which needs to run at admin level. With PsExec, credentials can be modified and malware privilege escalated to System level. At that point, the malware can do anything.

The important thing to note about PsExec is it is a valid Microsoft code signed utility process. As such it will not be detected by any AV as malware.

Edited August 28, 2017 by itman

[0xDEADBEEF 43]

On 8/28/2017 at 7:57 AM, itman said:

Since you let the malware run with admin privileges, it literally could have done anything.

One example if employed by the malware is PsExec which needs to run at admin level. With PsExec, credentials can be modified and malware privilege escalated to System level. At that point, the malware can do anything.

The important thing to note about PsExec is it is a valid Microsoft code signed utility process. As such it will not be detected by any AV as malware.

Yep, continue improving my auto exec and submission system while tightening the control.. I also added some yara rules to scan the samples as a reference.

Recently I didn't find any missed samples. Good job ESET

[0xDEADBEEF 43]

SHA256: 67589ebe860dee5fcd8927d62c7085a23ddaca517657e6bc9e76225df2097544

SHA256: ef9d512a9fb0c93bfda9d6427690c0880f500968798411f85b825c085df1de3b

It is detected as potentially unwanted on VT. However, it seems the Chinese version of ESET doesn't flag FlyStudio Packed detection even with PUA on. Since FlyStudio Packed-type malware is very popular in China,  this is considered a miss

I've seen many Chinese-born FlyStudio malware. I am not sure if ESET will add a secondary detection on those malware even with this PUA detection. If ESET doesn't, then Chinese version ESET might miss many samples.

Edited September 1, 2017 by 0xDEADBEEF

[0xDEADBEEF 43]

SHA256: a06af1ebeff4795126cbe2765954bbe177b7a34ba11e84631b347e79ef23f6f0

[itman 1,659]

On ‎8‎/‎31‎/‎2017 at 11:36 PM, 0xDEADBEEF said:

SHA256: a06af1ebeff4795126cbe2765954bbe177b7a34ba11e84631b347e79ef23f6f0

I must say it took a very long time for the AV's to create a sig for this. I checked yesterday and still no one was detecting it by sig..

Per VT:

Quote

History

Relevant dates related to the file being studied.

Creation Time 2017-08-27 19:37:22

First Submission 2017-09-02 03:12:09

Last Submission 2017-09-02 03:12:09

Last Analysis 2017-09-02 03:12:09

Debug Artifacts 2017-08-27 23:37:22

 

Edited September 2, 2017 by itman