- Jul 3, 2015
- 8,153
How does the default/deny software that people are using deal with unusual types of executable files, such as the HTA file type that is currently being implanted in images in order to exploit MSHTA.exe?
Really what I am asking is like this:HTA file is HTML application that can be performed, locally, regardless of the browser and It has all of the characteristics of the executable file (in Windows environment), it is a mix between HTML and Visual Basic Script, so, as a executable file, it should be blocked by default/deny system.
Extreme Makeover: Wrap Your Scripts Up in a GUI Interface
Each of the files that generates a task is monitored (ref. Windows internals).Really what I am asking is like this:
Mister User has his favorite default/deny app: NoVirusThanks/Voodooshield/COMODO/SpyShelter/SecureAPlus/ReHIPS/You-Name-It
installed on his system.
How does he know which file types are actually being monitored? We know that .exe and .vs are definitely on the radar, but what do we know about the other ones?
thanks for detailed explanation!Each of the files that generates a task is monitored (ref. Windows internals).
The task is the instance of the execution of a particular program: when you run an executable file, it is created a process in memory that performs the instructions specified by the program. The kernel creates a process in memory by giving it a PID (Process IDentifier). Typically, the PID is sequential and each process has the PID of the previous process incremented by 1 and the first process launched by the system (init) has the PID equal to 1. In fact the kernel creates the init process, and any other process is always created from a request made by an existing process. In this way it is created a process tree with init as base. A parent process can create a child process, but each process is identified by PID.
Default deny apps monitor all of these behaviors.
Assuming you still use Rehips you are covered. It blocks execution of child processes from mshta.How does the default/deny software that people are using deal with unusual types of executable files, such as the HTA file type that is currently being implanted in images in order to exploit MSHTA.exe?
In fact the kernel creates the init process, and any other process is always created from a request made by an existing process. In this way it is created a process tree with init as base. A parent process can create a child process, but each process is identified by PID.
Most Default Deny software use a device driver which registers a kernel-mode callback known as PsSetCreateProcessNotifyRoutine/Ex. This allows them to receive a notification when a new process start-up is occurring, and they can decide whether to allow the process execution in the filtering or block the execution from being successful (resulting in the program not starting up). This is typically the same method used by most AV products these days, also.We know that .exe and .vs are definitely on the radar, but what do we know about the other ones?
Depending on the configuration then yes it should be put into the sandbox, since it will detect the process execution attempt. The exploit doesn't run and perform code execution without a process and a thread within this process to execute it's code; therefore Comodo will intercept the process start-up attempt and if the program is unknown/untrusted (or based on the configuration) will auto-sandbox.If you use Comodo it will sandbox it i guess but don't quote me on that.
Depending on the configuration then yes it should be put into the sandbox, since it will detect the process execution attempt. The exploit doesn't run and perform code execution without a process and a thread within this process to execute it's code; therefore Comodo will intercept the process start-up attempt and if the program is unknown/untrusted (or based on the configuration) will auto-sandbox.
Anything is possible - nothing is perfect and full-proof because it's all engineered by humans and we are prone to make mistakes somewhere down the line. What works well today may not work well tomorrow, and malware is evolving all the time.Is it possible that an executable (theoretically) could drive by inject a Windows process or other common process and execute without being placed in the sandbox, i.e. appearing to be a trusted or non-malicious process? Most top anti-malware and a-v would catch this I assume, but, if not, what about the sandbox?
How does he know which file types are actually being monitored? We know that .exe and .vs are definitely on the radar, but what do we know about the other ones?
Dynamic monitoring and blocking of all potential file types is not practical. Depending upon how it is implemented, it can greatly impact system performance - for example, active *.dll monitoring.
I have no specialized software installed.There are literally hundreds of file types. If a user does not have software on the system - either a host process, virtual machine, or program - that will run a specific file type, then it will not execute and there is nothing to worry about. You get the "This file cannot run on your system..." notification.
For example, if you have an autocad (*.DWG) file on the system, but no autocad software installed only the system, then the autocad file (*.DWG) file cannot execute.
When it comes to monitoring - or more importantly the blocking of file types - each security software is programmed to do so differently. Some monitor the host process while others parse the command line. There are others that treat all executable file types as distinct files in their own right. Finally, there are those that treat the host process as default-allow and thereby treat the executable file as default-allow. For example, some security softs will allow all undetected script files that can be run by wscript.exe or cscript.exe as default -allow since the host process is default -allow.
It is important to block *.exe, *.js, *.vbs, *.wsf, *.ocx, *.cmd, *.bat, *.reg, *.ps1, *.dll, etc, etc file types by policy. In other words, the most commonly abused file types. Malc0ders stick to file types that will run on the vast majority of systems.
Dynamic monitoring and blocking of all potential file types is not practical. Depending upon how it is implemented, it can greatly impact system performance - for example, active *.dll monitoring.
I have no specialized software installed.
I created rules for:
powershell
powershell ISE
cmd
wscript
cscript
mshta
python (I discovered that it is bundled with Libre Office)
are there any others that you would recommend?
Thanks @Wave for the brilliant explanation .. I missed your linked thread, I'm going to read it.Avast, AVG, Kaspersky, Zemana, Malwarebytes, Qihoo, etc (and most likely pretty much all the popular Anti-Executable software)... They all use this kernel-mode callback for monitoring process start-ups. I posted a thread on using this kernel-mode callback previously: Developing your own Anti-Exe (C - Device Driver Development)
As well as the "priority" right ?Out of curiosity, when antimalware tries to terminate a malicious process, it obtains an output value, called "exit status", that is a numeric value of a byte. This is typically used to determine if the task was done correctly or not
Quite complex.As well as the "priority" right ?
When I used to develop government rootkits for Russia I used to mark the processes being protected by the rootkit as critical via RtlSetProcessIsCritical and laugh at the reactions from the live webcam when UK government officials terminated the processes and got landed with a BSOD crash.Out of curiosity, when antimalware tries to terminate a malicious process, it obtains an output value, called "exit status", that is a numeric value of a byte. This is typically used to determine if the task was done correctly or not, and we use the convention to consider successful completion a process that gets an exit status equal to 0, while we consider terminated with an error a process that returns an exit status different from 0.
At its termination, a process always returns a value to the parent process, that can ignore it or not, but that should be expected, via the call to the library function wait(). Otherwise, the child process does not have the confirmation that the parent has assigned its return value, and therefore the kernel does not destroy it (it does not removes from the memory the data structure to which it refers), but is limited to considering it as a zombie.
In addition, a process that ends may have created some child malicious process. These processes are adopted by init and in this case, the antimalware fails to properly terminate the malware process and it is possible that the termination of a process causes the core dump.