Default/Deny and unusual file types?

shmu26

Level 85
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
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?
 

tim one

Level 21
Verified
Honorary Member
Top Poster
Malware Hunter
Jul 31, 2014
1,086
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
 
Last edited:

shmu26

Level 85
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,153
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
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?
 

tim one

Level 21
Verified
Honorary Member
Top Poster
Malware Hunter
Jul 31, 2014
1,086
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?
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.
 

shmu26

Level 85
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,153
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.
thanks for detailed explanation!
 

SHvFl

Level 35
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Nov 19, 2014
2,346
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?
Assuming you still use Rehips you are covered. It blocks execution of child processes from mshta.
If you use Comodo it will sandbox it i guess but don't quote me on that.
 

AtlBo

Level 28
Verified
Top Poster
Content Creator
Well-known
Dec 29, 2014
1,711
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.

Good information, thanks. Curious if this was true of init in XP and Vista. I assume it's true in 7 although I haven't paid that much attention. Think I have seen it in Process Explorer.
 
W

Wave

We know that .exe and .vs are definitely on the radar, but what do we know about the other ones?
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.

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 this, make sure to remember what @tim one said because there is some great information in his post :)

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.
 

AtlBo

Level 28
Verified
Top Poster
Content Creator
Well-known
Dec 29, 2014
1,711
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.

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 part of or an actual trusted or non-malicious process? Most top anti-malware and a-v would catch this I assume, but, if not, what about the sandbox?
 
W

Wave

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?
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.

As for most top Anti-Malware and Anti-Virus products catching an exploit attack like this, I wouldn't be surprised if they failed actually - most AV vendors seem to still be struggling with integrating protection against unauthorised device drivers from being installed on the system, or don't even include basic anti-injection protection to prevent an unknown, untrusted program from injecting into a web browser like Chrome. With the exception of a few vendors of course, which take dynamic protection seriously (e.g. Emsisoft, Kaspersky, G-Data).

Moving back onto the topic a bit better, if your browser becomes exploited by malicious code being executed from a malicious URL and the exploit leads down to code execution coming from the browser itself (e.g. you visit a malicious webpage -> your browser becomes exploited and now malicious code is being executed on your host system from the browser itself) then it can just perform shell-code execution to inject code into a trusted, non-malicious process. That being said, unless the security product is protecting against injection attacks, then since the browser had become compromised by the malicious webpage to execute the shell-code (to inject into the trusted process already running on the system), no additional process is required since there was no new program download to be executed, therefore the security software wouldn't even become aware of the code execution.

Now speaking about Comodo Sandbox specifically, if the web browser isn't running under the sandbox and neither is the target running program to be injected into, well since there is no new program start-up, Comodo Sandbox wouldn't do anything I think. Since now code execution is coming from a non-sand-boxed trusted program, and there was no new program start-up for Comodo to put into the sandbox in it's own.

Of course such exploits may be very rare in themselves, it doesn't mean such attacks are impossible. ;)

Believe it or not, old techniques used for injection such as the RtlCreateUserThread function (present in ntdll.dll) isn't even monitored properly in some AV products, let alone the more stealth injection techniques (such as manual mapping via LdrLoadDll - which is the loader function called low in Windows when a new DLL becomes loaded, or even direct code injection without requiring a DLL).

Speaking about more dangerous malware which may utilise device drivers, some AV products won't care less if an unknown program which is not white-listed (even if it has NEVER been seen before at all, ever), attempts to install a device driver... And of course once malware has an active kernel-mode component, say good-bye to any running protection you have, because it'll be KO'd and wiped off the system. :D

Honestly these days I just advise people to watch closely on what websites they visit and what they download and run, because even I am starting to lose hope in most AV products these days - some vendors are still focusing mainly on static detection methods even though they know that it is getting more and more obsolete, but people still pay for the products so the vendor stays rich anyway.
 
Last edited by a moderator:
5

509322

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?

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.
 

AtlBo

Level 28
Verified
Top Poster
Content Creator
Well-known
Dec 29, 2014
1,711
Thanks for the answer Wave. This is the one thing that I am concerned about the most for now. Who knows, maybe they'll be injecting systems with malware using a hand held radio in 2 years from now. I do believe the business side of security software will come up with some answers, but I guess we will have to come up with some denaro too.

I think I have seen this type of attack with the injection in videos. These are lightning fast if it's what I was watching. Can't remember the exploit. Hard to believe the exploits that are getting out like 2 days after a patch like with the Edge browser last week at that white hat event. It's crazy. Oh, and cracking VMWare without any direct access to the computer. Wow. I mean for now I guess it's run your browser in the sandbox and just give up trying to beat anyone with designs of manually gaining remote access/control of your PC. Probably not going to take more than a few hours or at most a few days I guess.

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.

Great comment. Maybe we will see a condensing of the types of executables that will run on a PC someday? Maybe that will part of some sort of a solution...and resource cheap and reliable memory mitigation.
 

tim one

Level 21
Verified
Honorary Member
Top Poster
Malware Hunter
Jul 31, 2014
1,086
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.
 

shmu26

Level 85
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,153
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?
 

tim one

Level 21
Verified
Honorary Member
Top Poster
Malware Hunter
Jul 31, 2014
1,086

shmu26

Level 85
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,153
It sounds like most of you are saying that it's not necessary to fuss over which file types are being blocked by your favorite default/deny app, because the mechanism that is employed is file-type-agnostic.
 

tim one

Level 21
Verified
Honorary Member
Top Poster
Malware Hunter
Jul 31, 2014
1,086
As well as the "priority" right ?
Quite complex.
Every execution path of a process is a thread. A process consists of at least one thread that coincides with the process itself. As to processes, a thread can create another one. For each thread relative to a process are not created all the data structures needed for the creation of a process, for which a thread is much more “lightweight” (in the sense that it occupies less memory) of a process, since all threads related to a process use the same data structures that characterize the process of which they are a part.
 
W

Wave

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.
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. :D

This never really happened but that API does exist, but sometimes we need some humour :p
 

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top