McAfee did a good job in intercepting most ransomwares. It prevented them from encrypting the files although ransomware processes were running.
However, it failed against MBR-encrypting RWs like petya.
[Britec09] Fight Back Against Ransomware (McAfee Ransomware Interceptor Review)
- Thread starter Evjl's Rain
- Start date
It is advised to take all reviews with a grain of salt. In extreme cases some reviews use dramatization for entertainment purposes.
McAfee did a good job in intercepting most ransomwares. It prevented them from encrypting the files although ransomware processes were running.
However, it failed against MBR-encrypting RWs like petya.
I read some comments in their support community
1/ They said "The tool currently supports only exe / scr / com files" and someone said it was ineffective against js ransomwares
2/ Bugs
3/ False postives with chrome and firefox
1/ They said "The tool currently supports only exe / scr / com files" and someone said it was ineffective against js ransomwares
2/ Bugs
3/ False postives with chrome and firefox
Hello Before i had Bitdefender about 4 years ago i had McAfee Total Protection for 2 years and was very satisfied with it ,it removed a lot of trojans for me,so i am not surpriced if they have succes with ransomware too
Actually I knew that the real ransomware is an exe. Js is just to download the real ransomware
true but most AVs tend to allow the child processes if the parent process doesn't do harm. I don't the exact mechanism but many AVs have missed this kind of ransomwares
- May 14, 2016
- 1,597
You have not read all my analysis of scripts
- script files can be .js, jse, .vbs, .vbe, .wsf
- Some script-based files download obfuscated files and deobfuscate them as dll and run them by rundll, file name, entry point, parameter, etc (see the last locky versions, from months)
- Other script-based files don't need to download files, because the content is hard coded in variables, and then put on real files (or fileless / loaded in some memory process)
Last edited:
You have not read all my analysis of scripts
- script files can be .js, jse, .vbs, .vbe, .wsf
- Some script download obfuscated files and deobfuscate them as dll and run them (see the last locky versions, from monthes)
- Other scripts doesn't need to download files, because the content is hard coded in variables, and then put on files (or fileless : loaded in some memory process)
Ok ( i knew about vbs actually) but the script is not the real ransomware right ? I don't get the point three sorry
- May 14, 2016
- 1,597
You are right
How point 3 of your post works ?
Because actually from point 3 it seems the ransomware is the js
- May 14, 2016
- 1,597
Some scripts (that are like text in files), are obfuscated to make them hard to be understood, and have some vars with the obfuscated content of future files (often encoded strings).
When the script is run, it deobfusctates itself and also the content data that will be used to create real files (payload, etc). At some point, it run the file(s).
The "fileless":
An example of what I have seen (the malware part is fileless):
A script-based file with several vars that are encoded strings (in several parts).
=> one var is the encoded content of a dll :
=> once decoded, the script saves the file with a false extension : .vbs.bin
=> the script registers this dll
=> it then creates an object based on this dll : ActiveX object
=> then the script is able to call Windows API using this object.
=> one var is the encoded content of a dll :
=> once decoded, the script saves the file with a false extension : .vbs.bin
=> the script registers this dll
=> it then creates an object based on this dll : ActiveX object
=> then the script is able to call Windows API using this object.
=> allocates memory
=> copy there the loader part once decoded (the "RunPE shellcode") :
=> allocates memory
=> copy there the parts of the malware to be injected once decoded (hard-coded on an array of encoded strings),
=> CallWindowProcW : the loader is called and it injects the malware on the host process (svchost.exe or msbuild.exe if .NET available)
=> copy there the loader part once decoded (the "RunPE shellcode") :
=> allocates memory
=> copy there the parts of the malware to be injected once decoded (hard-coded on an array of encoded strings),
=> CallWindowProcW : the loader is called and it injects the malware on the host process (svchost.exe or msbuild.exe if .NET available)
Last edited:
Wow thank you I really appreciate
- May 14, 2016
- 1,597
An example here
3-2) Constant objects :
'=-=-=-=-= CONSTO =-=-=-=
Several Base64 encoded (very long) Strings are used.
We will see later that :
'=-=-=-=-= CONSTO =-=-=-=
dcom_data = .....
loader_data = .....
dim file_data(10)
file_data (0) = ....
file_data (1) = ....
...
file_data (9) = ....
file_size = 35328
loader_data = .....
dim file_data(10)
file_data (0) = ....
file_data (1) = ....
...
file_data (9) = ....
file_size = 35328
Several Base64 encoded (very long) Strings are used.
We will see later that :
dcom_data => dll content (used to allow API calls)
loader_data => encoded loader data used
file_data => array of encoded strings : malware parts
loader_data => encoded loader data used
file_data => array of encoded strings : malware parts
loader_data and file_data will be decoded and used for injection
Last edited:
- Apr 13, 2013
- 3,224
As DardiM has nicely pointed out a major mechanism of action for recent ransomware has been the dropping and forced running of a payload dll. So it's not so much that this product is ineffective against JScript based ransomware, but against ALL ransomware that operate in this way, including exe files.
When doing ransomware testing it is really important to choose the ransomware run in the test by mechanism and not by name as otherwise the results will be questionable.
When doing ransomware testing it is really important to choose the ransomware run in the test by mechanism and not by name as otherwise the results will be questionable.
- Aug 22, 2013
- 886
There was a time when only linux (all unix versions included) users needed to be educated about the os they uses, now new threats like these are forcing poor windows users to know their OS deeply than ever before.
Similar threads
