Jump to content

MalwareTips


BALTAGY

Recommended Posts

  • ESET Insiders

Hi,

I want to know why ESET don't join forums like MalwareTips to detect new viruses/Ransomwares more faster ?

An example:
https://www.virustotal.com/#/file/05bfd83bb0d4e7d27bbfc2c057b2b692612de808cc4bca73d9e0ae1d9d479623/detection

I know it's a new Ransomware but it could be detected by now ?

Another Example:
https://www.virustotal.com/#/file/3203dc5ea66e86755254214b7b1ca8cb38271978e3ac2bdda35bce973ed0146c/detection

And Merry Christmas everyone

Edited by BALTAGY
Link to comment
Share on other sites

1 hour ago, BALTAGY said:

An example:
https://www.virustotal.com/#/file/05bfd83bb0d4e7d27bbfc2c057b2b692612de808cc4bca73d9e0ae1d9d479623/detection

I know it's a new Ransomware but it could be detected by now ?

This one is GrandCrab ransomware. Suspect the javascript payload is heavily obfuscated. Such has been the "Achilles heel" for AV's for some time.

If you look at the Behavior section on the detection at VT, it is running PowerShell. One reason among many I have a HIPS rule to monitor all PowerShell execution. 

Link to comment
Share on other sites

  • ESET Insiders
1 hour ago, itman said:

This one is GrandCrab ransomware. Suspect the javascript payload is heavily obfuscated. Such has been the "Achilles heel" for AV's for some time.

If you look at the Behavior section on the detection at VT, it is running PowerShell. One reason among many I have a HIPS rule to monitor all PowerShell execution. 

Can you share how you created this rule ? NVM i made it, since i don't use PowerShell i made a rule to ask if any app want to run it

Edited by BALTAGY
Link to comment
Share on other sites

Malwaretips offer a Malware Hub section where users spent time testing security products.

As far as I'm aware one of the rules there is to submit missed samples to the antivirus provider you are testing.

Of course one has to wait for someone to actually test ESET.

Link to comment
Share on other sites

  • ESET Insiders
7 hours ago, Azure Phoenix said:

Malwaretips offer a Malware Hub section where users spent time testing security products.

As far as I'm aware one of the rules there is to submit missed samples to the antivirus provider you are testing.

Of course one has to wait for someone to actually test ESET.

Users testing products there is not much like before, i used to see many products being tested and any users could download the samples

Edited by BALTAGY
Link to comment
Share on other sites

14 hours ago, BALTAGY said:

NVM i made it, since i don't use PowerShell i made a rule to ask if any app want to run it

Let me begin with it is almost impossible to stop malicious use of PowerShell by a determined attacker. One might think that creating a HIPS ask rule to monitor the startup of C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe and C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe will detect all PowerShell execution. It won't.

Past examples of malicious use of PowerShell include to name few:

1. The attacker downloading the old version of PowerShell, ver. 2.0, used in Win 7 and running it. This version for example, will run fine on Win 10 as long as .Net 2.0 or 3.5 is installed.

2. Downloading the current ver. of PowerShell to any directory, possibly renamed but not necessary to do so, and running it from that location.

3. Executing .Net subassemblies associated with PowerShell via C#, C, etc. program means.

The only way to completely stop PowerShell execution would be to employ a security product that can block execution by hash value and then create ask/block rules for hash values associated with every known version of PowerShell. Also, setting PowerShell to Constrained Language mode or using AppContainer which does the same.

Eset has a few knowledgebase articles on PowerShell and other script use mitigations:

1. Firewall rules: https://support.eset.com/kb6132/

2. HIPS rules: https://support.eset.com/kb6119/

These will prevent the most prevalent malicious use of PowerShell. They will not prevent all malicious use of PowerShell.

Edited by itman
Link to comment
Share on other sites

Downloaded the first sample with very few detections on VT and ESET picked it up as JS/TrojanDropper.Agent.NQS and the second link shows that ESET already detects it. Don't forget that ESET Advanced Memory Scanner would likely detect it as soon as it decloaked in memory.

Link to comment
Share on other sites

40 minutes ago, Tornado said:

Downloaded the first sample with very few detections on VT and ESET picked it up as JS/TrojanDropper.Agent.NQS and the second link shows that ESET already detects it. Don't forget that ESET Advanced Memory Scanner would likely detect it as soon as it decloaked in memory.

Kudos to you for testing it. I suspected the same originally since not all of Eset's protection mechanisms are fully functional on VT. But again, one is not fully sure of detection without a test.

-EDIT- Also appears that a variant detection for this was added 5 hours ago via signature update 18609: https://www.virusradar.com/update/info/18609 .

Edited by itman
Link to comment
Share on other sites

  • ESET Insiders

What i mean from the topic is joining these kind of forums will help detect new viruses more faster

Example of today:

https://www.virustotal.com/#/file/73c7e1dfffcadf2f8b40d26d91a4c2534dad108b2e26cc1cc476d086756631c3/detection

I know it can be detected via other module and maybe not

Link to comment
Share on other sites

As far as the GrandCrab 5.0.4 ransomware, what was submitted to Hybrid-Analysis was a binary file, 05bfd83bb0d4e7d27bbfc2c057b2b692612de808cc4bca73d9e0ae1d9d479623.js.bin. This leads me to believe the original source of the ransomware was a MS Office Word .doc file employing this for example: https://cloudblogs.microsoft.com/microsoftsecure/2016/06/14/wheres-the-macro-malware-author-are-now-using-ole-embedding-to-deliver-malicious-files/ . So blocking all script child process startup including PowerShell from MS Office executables would have prevented the ransomware from running. Also do note the Microsoft recommended mitigation to block OLE automation in MS Office. 

Edited by itman
Link to comment
Share on other sites

Proofpoint published an article titled, LCG Kit: Sophisticated builder for Malicious Microsoft Office Documents, which highlights two main points:

1. MS Office malware attacks are becoming increasingly sophisticated.

2. These attacks are now being sold on the dark web as kits enabled those without advanced programming skills to create advanced malware attacks that difficult to detect.
 

Quote

Overview

Proofpoint researchers discovered “LCG Kit,” a weaponized document builder service, in March 2018.  Since we began tracking LCG Kit, we have observed it using the Microsoft Equation Editor CVE-2017-11882 [1] exploit in various forms. More recently, its authors have integrated a VB Script exploit, CVE-2018-8174 [2], which has been used used in limited email campaigns. Finally, at the end of November, LCG Kit added the ability to use Microsoft Word macros instead of exploits to load the shellcode responsible for installing malware payloads.

LCG Kit is somewhat unusual in that the code is highly obfuscated using polymorphic shellcode and a Linear Congruential Generator (LCG) -- an algorithm to generate a sequence of pseudorandom numbers -- to encrypt the final stage of the code, including the payload locations. We named LCG Kit due to this unique feature.

Due to the widespread appearance of malicious attachments created with LCG Kit in a number of email campaigns,, we presume that it may be for sale on underground forums. LCG Kit appears to be popular with small crimeware groups for spreading Remote Access Trojans (RATs) and stealers including Loki Bot, FormBook, Agent Tesla, Remcos, AZORult, Revcode RAT, Quasar RAT and more in campaigns that typically involve thousands of malicious email messages. Colleagues at Cisco Talos described one such campaign in October [4].

History

Proofpoint first observed documents that appeared to be built using this kit in the middle of March 2018, delivering Loki Bot.

The kit appears to have several possible target documents :

  • RTF documents
  • Microsoft Word/Excel 2007+ documents (often read-only or protected) with OLE objects containing the Equation Editor code
  • PDF documents with JavaScript loading an embedded RTF document containing the exploit
  • Microsoft Word/Excel 2007+ documents with embedded remote RTF objects containing the exploit

https://www.proofpoint.com/us/threat-insight/post/lcg-kit-sophisticated-builder-malicious-microsoft-office-documents

It is therefore imperative that organizations employ mitigations to defeat the above attack methods. I posted previously about OLE mitigations. JavaScript should be disabled via in-product Adobe Reader setting, RTF objects should likewise be blocked via MS Office in-product settings. Etc,, etc.

 

Edited by itman
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...