What on earth has happened to viable HIPS software availability?

Discussion in 'other anti-malware software' started by Smiggy, Mar 10, 2017.

  1. blacknight

    blacknight Registered Member

    Joined:
    Sep 25, 2007
    Posts:
    3,342
    Location:
    Europe, UE citizen
    System Safety Monitor, probably the best, had the same fate, Drive Sentry, a kind of middle solution, too.
     
  2. guest

    guest Guest

    If an standalone HIPS developer want to survive, its main sales must be with corporate markets, and since on corporate markets, admins won't waste time configuring an HIPS and rather use SRPs ; there is no way an HIPS can survive. Comodo is an exception because their main incomes are certifications. And if MS decide one day to introduce WD APT in home users versions of Win10, things will be worse for those devs.
     
  3. illumination

    illumination Guest

    In some cases such as CIS Hips is mostly redundant. With CIS in Proactive Configuration, Hips is not necessary, as the Auto sandbox "containment system" does most of the heavy lifting.

    I'm an old Hips user myself, and from memory, I remember clean installing a system, placing my usual software's and then my Security, training my security, and all was good until that first application update/upgrade came through. Many times while trying to be fast enough to nail the notifications of blocks while doing so, broke installers, and damaged applications. hips are just not practical, and very much so hamper productivity with much wasted time keeping it configured through system and application changes.
     
  4. clubhouse1

    clubhouse1 Registered Member

    Joined:
    Sep 26, 2013
    Posts:
    1,124
    Location:
    UK

    :D:thumb:
     
  5. bellgamin

    bellgamin Registered Member

    Joined:
    Aug 1, 2002
    Posts:
    8,099
    Location:
    Hawaii
    SSM still works great on my everlasting XP-based 1997 computer. (My laptop runs Win10 -- the OS from the Black Lagoon.)
     
  6. act8192

    act8192 Registered Member

    Joined:
    Nov 9, 2006
    Posts:
    1,789
    Same here on XP in a 2005 computer. It's rare to have to do anything once it's setup. Just infrequent MBAE or SeaMonkey updates need permissions. Locked up otherwise.
     
  7. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    It's very simple, if you want to monitor app behavior, you need HIPS, end of story. People who trust blindly in AV don't need HIPS. I don't know why people keep rambling on, we all know that the home-user market is very small. But in the corporate market it's all about HIPS (Next-gen AV), that says enough, you need behavior monitoring for best protection.
     
  8. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Depends on how you define HIPS. Is Appguard a HIPS. By the old definition no, but it sure does the same job.
     
  9. guest

    guest Guest

    HIPS as a broad category include any intrusion system, so technically it is an HIPS; but HIPS as we use to know (the monitor everything thingy) , AG isn't. AG by definition is an SRP.
     
  10. mWave

    mWave Guest

    If a developer is capable of patching the kernel via hooking the SSDT (System Service Dispatch Table) then I am sure they are capable of working with kernel-mode callbacks (kernel-patching alternative which Microsoft introduced when they blocked off patching of the Windows Kernel via PatchGuard/Kernel Patch Protection) and user-mode hooking (e.g. run-time byte patching, IAT hooking).

    Of course kernel-mode hooking was more reliable in terms of security but they can still hook the NTAPI from user-mode (as well as functions exported from modules like kernel32.dll, user32.dll which can't even be done from within kernel-mode itself), it'll only be bypassed via unhooking/system calls. Then again, most BB/HIPS components in existing AV solutions today use this method without a problem, so anyone can do it to make an independent one... Then again, the security isn't really too big of a deal even today because what samples have you seen use direct system calls or unhook APIs? None probably, it does happen but rarely

    For example, instead of hooking NtLoadDriver from within kernel-mode (change pointer address for that function entry in the SSDT to the pointer address of your own callback function) you hook it from user-mode via maybe a run-time patch (so place 0xE9 at the function address and then +1 from the start of the function you place the address to your callback, or for x64 processes you use the RAX register -> copy the bytes of the function to the trampoline prior to any modifications so you can allow the API call without having to unhook and then hook again).

    -----------
    Alternatively, you can work with the hyper-visor and then you can freely patch the kernel regardless of PatchGuard on x64 systems. Using the hyper-visor like this would be system-wide virtualization, or you can do it for select programs to be virtualized... But yes, this one would probably take a lot of time and money especially because it is much more advanced.
    -----------

    Anyway PatchGuard is actually good, regardless of the limitations it brings to security IMO. Because on x64 if you try to hook the SSDT it'll trigger BugCheck crash, which makes things so much harder for rootkit developers. ;) It most likely helped A LOT with bringing down the rates of zero-day rootkit attacks. ofc it didn't make it in-existent but kernel-mode rootkits aren't really prevalent anymore IMO at least
    ---------

    Kaspersky use the hyper-visor, then again they are rich and can probably invest in implementing anything they want lol :D
     
  11. guest

    guest Guest

    @mWave : i was lost at the 2nd line :p (just kidding) great explanation ;)
     
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,591
    Location:
    U.S.A.
    It also depends on how the HIPS is used.

    If it is run in Interactive mode, it will alert for all practical purposes on any process activity. That is process startup/suspense/termination, process memory modification, process hooking, file add/change/delete, and registry modification. Obviously, this method is only tolerable if training mode has been enabled initially so that rules are created for all existing system and application processes. Even then, interactive mode alerts are intolerable for most users. So some HIPS employ installer or Windows Update modes that can be switched to when those activities are being performed.

    Most current HIPS today are hybrids in that they employ a number of predefined rules to protect critical files, processes, and registry areas. These reduce the number of alerts while at the same time offer "pretty good" but not bullet proof protection. This is acceptable overall since the hybrids are usually part of an integrated AV solution offering signature, heuristic/behavior analysis plus network firewall, IDS, and botnet protection.

    Anti-execs on the other hand concentrate for the most part on process execution. That is "whitelisting" along with privilege restrictions.
     
  13. mWave

    mWave Guest

    Thanks :)
     
  14. mWave

    mWave Guest

    I will explain what I said in my previous post in a bit more detail for anyone interested:

    As most software developers know, there is a big world deep within the Windows API (Win32 API). This API is very commonly used by most software manually (for custom functionality), but it's not a requirement to develop software. When a GUI Window is shown or for every control on the form, that's all thanks to the Win32 API (but that specifically links back to the GDI functions exported by modules such as user32.dll and kernel32.dll, etc). If you view the modules within a process of a normal application, you should find these DLLs (but not always). Even a command window prompt application (for a console application) is based on the Win32 API, since it's needed for the actual window to be created and then displayed. Then you have non-GDI related functions which are used for many things relating to process execution (starting a program via ShellExecuteA/W or CreateProcessA/W, I/O related functions for creating/deleting/writing to files on the disk (CreateFile, DeleteFile, WriteFile, etc) , registry related functions for creating/deleting/modifying registry keys and their entries (RegCreateKeyEx, RegDeleteKeyEx, RegDeleteKeyValue, etc), and so on). More often than not, normal developers will use the Win32 API for this stuff, but they will never question what really goes on beneath their level of development within the OS itself - although they will usually easily learn how the Win32 API works thanks to documentation provided by Microsoft themselves via MSDN or other websites from third-parties. But have you ever wondered what really happens? If so, I will try to explain it for you.

    There is a Dynamic Link Library within Windows which you will find loaded within every single user-mode process called ntdll.dll (NT is from the Windows NT Kernel name - pretty simple naming but it does make sense). You can find this module under systemdrive:\Windows\System32\ntdll.dll. The reason this DLL is loaded within every single process is because it's responsible for communicating with the Windows Kernel itself, without it there would be no switch-over to the kernel where the real functions for specific Win32 API functions exist (and ntdll.dll is the very first module loaded within every process, too). NTDLL.DLL is essentially a system call wrapper for Native API functions (you might be wondering what the Native API even is, don't worry, I'll get to that in a second); a system call used to be executed via an interrupt instruction (int 0x2e) on older versions of Windows (like Windows 2000) however on newer versions of Windows it's performed via an instruction called sysenter. System calls are responsible for pushing over control to the kernel, basically a method of transition from user-mode -> kernel-mode.

    The Native API (NTAPI) is a set of functions deeply embedded within the Windows Kernel, they are exported by ntoskrnl.exe. By "export", I mean they can be accessed and used by other software and the addresses of them can easily be obtained, however some NTAPI functions are not exported by ntoskrnl.exe and therefore you would need to manually find the address (in this case that would only be for kernel-mode only functions, which would be the ones that cannot be called from user-mode). The Native API are essentially the functions which are put together to produce the functionality for the Win32 API functions to exist (specific ones); for example, if we take the function TerminateProcess which is exported by kernel32.dll (which most developers who are familiar with the Win32 API will know of, for termination of a process), that is an example of a function which is built up of the NTAPI... When you call TerminateProcess, it doesn't just land at the function and end there - it will land at the function TerminateProcess, but it's execution flow will be passed over to NtTerminateProcess which is exported by ntdll.dll once it's done it's work. Once NtTerminateProcess (exported by ntdll.dll) has been called, since ntdll.dll is essentially a system-call wrapper, it will use it's system call abilities to push the execution over to the kernel (and this is where the real function versions exist).

    When execution has been pushed to kernel-mode (e.g. via an interrupt like int 0x2e or sysenter), the address of these functions will be obtained from the SSDT (System Service Descriptor Table (also known as the System Service Dispatch Table)), and this table is exported by ntoskrnl.exe (which is why I said the Native API functions were exported by it earlier, only the ones present in this table are exported). There are hundreds of functions within this exported table, however each function has a pointer address assigned to it which represents a space in memory containing code (a function, should I say). To carry on my example, once NtTerminateProcess has been pushed over to the kernel for execution thanks to the system call from ntdll.dll, the pointer address of the calling function will be obtained and then the code execution will shift over to the function at the address in the SSDT... Once execution has arrived at the function for the calling function at that pointer address in memory, it'll continue to shift execution to different functions which are eventually kernel-only functions (which are all brought together for the function to work). It's like building a house, where you have many different components all put together for the house to be stable and have working elements within it - same concept here, where many different functions are put together to produce functionality, but the developer doesn't need to worry about the functions responsible for this, he just needs to know about the original container function which can be used to put it all together for him/her.

    Now you might be wondering, "Okay mWave, thanks for that info I guess? What does this even have to do with HIPS?", well we'll get to that question being answered now. It has everything to do with HIPS (alternatively Behavior Blocking, or any sort of dynamic monitoring), because there needs to be a way to monitor the activity on-going on the system.

    Back in the day, the old BB/HIPS systems would have used kernel-mode patching techniques to provide the monitoring functionality they did (and "kernel-mode patching" is basically modifications to the Windows Kernel - there are many different methods of patching the kernel, not just hooking of the SSDT). However, SSDT was the most common and the most appropriate at the time - the way it worked was the security software would install a device driver on the system which would then access the SSDT to obtain the pointer address at the entries of the functions which were going to be hooked (and this information would be backed up), and then the pointer address at those functions in the table would be changed to a new pointer address which pointed to a custom-written function located within the device driver of the security software. This would mean a few things:
    - Since it was patching of the kernel and changing the pointer address in the exported table of ntoskrnl.exe, whenever the targeted function/s were called by any piece of software on the system, after transition shifted over to the kernel for the calling function to execute properly, it wouldn't land at the pointer address which was originally set by the OS - it would land at the custom address which means the security software's code would become executed PRIOR to the calling function actually being carried out, which allowed the security software to log the API call and check the parameters/perform filtering to decide if the user should be alerted to provide a response or if the action should be automatically blocked and what-not (and once the security software was happy, it would allow the execution flow to return to the original pointer address without first restoring it and then re-hooking it, which is what a trampoline is for in a hook).
    - Every single piece of code which ended up relying on the exported SSDT would be affected - not just user-mode programs but kernel-mode code within device drivers, too. Therefore, if NtTerminateProcess had been hooked via kernel-mode patching of the SSDT, then calling NtTerminateProcess from kernel-mode would end up pointing to the hook callback address, too.
    - If the device driver containing the function which was set as the callback address for the pointer address in the SSDT hook was unloaded, then once any code tried to call a function which had been hooked (but when the hook had not been restored prior to unloading the device driver), then the system would crash (BSOD), because it would be trying to access memory which no longer existed for usage.

    SSDT hooking was pretty useful for a number of things back in the day (and still is for 32-bit systems on newer version of Windows), but if a problem occurred which could not be handled then it would result in a system-wide crash (BSOD). It could accomplish dynamic monitoring of running software, and had other perks such as uses for self-protection mechanisms for the security software (processes, registry and files on disk - specific functions like NtOpenProcess would be hooked and upon the filtering if the target was a process running but owned by the security software then the callback function would return STATUS_ACCESS_DENIED instead of returning back to the original pointer address in memory, preventing the calling function from being successful in it's actions).

    Now as many know, Microsoft introduced new mechanisms in Windows Vista (x64 versions of Windows only) known as PatchGuard (PG) - this comes along with Kernel-Patch Protection (KPP). PG is responsible for a number of things, but one example would be preventing the loading of unsigned device drivers (this was most likely done for several reasons, two I can think of would be to boost the usage of code signing authenticity which probably landed more money into the arms of Microsoft by digital signature publishers, and to prevent the usage of rogue device drivers which would have helped lower the risk of kernel-mode rootkits (unless the malware author was willing to spend out of his pocket to obtain a digital signature, but on Windows 10 past one of the patch updates from the past, it's a much more trickier process as you would require an Extended Validation digital signature which requires genuine company registration and the such, and these documents must be provided and validated by the digital signature providing vendor). Microsoft are aware that the introduction of PatchGuard (which comes packaged with KPP) would prevent specific software from functioning correctly, security software at the top of list, therefore they brought in some new alternative features which security vendors could resort to using, which would be kernel-mode callbacks.

    Kernel-mode callbacks is similar to SSDT hooking, except you never actually perform a modification to the Windows NT Kernel which keeps things stable and keeps Microsoft much happier (they were not pleased with people performing modifications to internal structures within their OS which contributed to the PG introduction also). The way it works is you would register a callback for a supported activity and then you would receive a notification (sometimes both a pre and post notification, pre representing prior to the calling action finishing and post representing once the calling action has been completed and successfully passed through). There are kernel-mode callbacks available for tons of things which can be useful for intercepting process execution (PsSetCreateProcessNotifyRoutine and the more up-to-date copy PsSetCreateProcessNotifyRoutineEx), images loading in memory (PsSetLoadImageNotifyRoutine), handle creation/duplication attempts (ObRegisterCallbacks - useful for process protection and the primary method used by AV software these days), registry changes (CmRegisterCallback and CmRegisterCallbackEx), I/O operations (FltRegisterFilter), there are more available of course. Bear in mind, these are actually documented by Microsoft over at MSDN and there are widely available samples provided by them over on there too, so unless you are trying to do something with a high risk and which is undocumented (which can stop working at any time via a patch update or new major version of Windows) then using kernel-mode callbacks as an alternative has it's big perks and is much easier to work with anyway; kernel-mode patching was never officially supported by Microsoft and therefore was never documented by them, it caused lots of confusion for some and was heavily abused by rootkits especially which would subvert the Windows Kernel to take complete control - in some cases it would have been easier to just reinstall Windows, or format first which would be even more secure, because attempting to remove the infection would result in a BSOD crash over and over again if done incorrectly, and Safe Mode can be compromised too).

    The problem for most is that kernel-mode callbacks is not a permanent solution for everything, but then again it was never meant to solve everything, it's not the same as patching the kernel... But similar depending on what you are trying to do. Regardless, you can still work with user-mode patching methods which if implemented properly and securely can work just as well (and speaking of security risks, there are usually 2 big main ones which would be direct system calls and unhooking attempts, both of these are not commonly found in samples in the wild... Sure, there are many resources to learn and most people who do this sort of work have great experience with the topics of kernel-mode development and API hooking, but then again a lot of people with experience with this sort of thing back in the day either hid under a rock for the past few years or moved to helping the good side instead of rootkit development because I barely find any samples these days at least which do this sort of thing, none even... Most prevalent in the wild would be attacks like ransomware, which have an end-goal of producing money at the cost of the user).

    There are many different approaches which you can take when it comes to user-mode patching, two of the most common would be run-time byte patching at the addresses of functions in memory, and IAT (Import Address Table) hooking. I will try to explain both of these methods in a way for everyone to understand.

    Run-time byte patching:
    1. You must find the address of the function you wish to hook.
    2. You must change the protection of the memory at that address so you can write to memory there (thanks to memory protection) (although you must always remember to re-protect the memory after setting your hook for good security and code practice).
    3. You must allocate some memory and then copy the bytes from the original function to the trampoline, this allows you to call the original function from within the callback function should you wish to allow the code execution flow to proceed. A trampoline is much better because if you are unhooking the function, then allowing it to pass through and then re-hooking the function, you can easily experience a crash if the same function is called multiple times at the same time.
    4. Now you have removed the memory protection you can write to the memory at that address (make sure it's changed to PAGE_EXECUTE_READWRITE) and setup your trampoline, so you can place your custom instructions at the start of the function. On x86 you can simply jump to the callback address, but on x64 it is a bit more complicated because there are some changes relating to data types and the such... On 32-bit processes for hooking you can simply place 0xE9 at the start of the function (0xE9 is the byte-representation of the op-code JMP instruction in ASM), and then after placing 0xE9 you can place the address of your callback function. However, on x64 since it's a bit different usually using JMP <addr> doesn't work well, so you can work with an 64-bit register known as RAX (64-bit version of EAX)... The way it works is at the start of the function you will insert the instructions MOV RAX, <addr> and then you will follow it off with JMP RAX.
    5. Re-protect the memory once you're done modifying the instructions at the target address in memory.
    6. Now you're done with the hooking!

    IAT (Import Address Table) hooking:
    This is a bit different to run-time byte patching. You see, every process has something called the Import Address Table, it's essentially a look-up table for functions and this was implemented to prevent programs having to always statically link libraries (static linking increases file size and is not the best for everyone). The Import Address Table has entries for the functions which are dynamically linked (not statically linked), and each entry will point to an address just like the SSDT does in kernel-mode. It basically works the same way that the SSDT has, but for user-mode... When the function is called it will be looked up in the IAT automatically and then the address will be obtained for that caller function, and then execution flow will shift over at the address which was present in the IAT and set for that target function. Therefore, to hook the IAT you basically just replace the address with your own (but remember to back up the original address so you can restore it afterwards).
    -----

    In the callback function (the function where you placed it's address as the callback in the hook, meaning when the hooked function is called the execution flow will be intercepted and end up at your custom function) you can use the trampoline to pass the function back to it's original execution flow, however you can alternatively block the function call by not returning the trampoline (e.g. for NTAPI function hooking you can return 0xC0000022 if it's supported which represents STATUS_ACCESS_DENIED).

    Bear in mind, hooking the NTAPI over the Win32 API is clever depending on what you're trying to do because as we know from the theory earlier, it'll end up at the NTAPI equivalent anyway (assuming there is one).

    You do not actually need to do API hooking yourself or even study it's internals, especially if you are a rich company like some of the security vendors who have products on the market... Microsoft actually seem to support user-mode patching methods (I guess anything is better to them than people patching the kernel, haha!), and they provide an API hooking library called MS Detours. The term "detour" is pretty much the same as hooking, so don't get mixed up and confused with them both... "Detouring" is the professional name for it though. In my books they are the same at least. In fact, MS Detours will even re-hook the function if it gets unhooked without permission I believe also, but I'd have to check up on that so don't quote me on that just yet. MS Detours is free for 32-bit process detouring, but the 64-bit version costs money... There are many other API hooking libraries (some fully open-source), an example of other API hooking libraries would be EasyHook or Deviare (never used them myself, but they do seem quite neat).

    Most security software which provide dynamic monitoring of unknown programs will already use user-mode patching techniques to accomplish this, it allows compatibility with both x86 and x64 systems. Some security software will still use kernel-mode patching on the x86 system versions of their software only though.

    Now I am going to mention a bunch of behavior's which can be monitored and what function's can be hooked/the kernel-mode callback which can be used to accomplish that functionality:
    - Device driver load attempts (CreateServiceA/W, StartServiceA/W, NtLoadDriver, NtSetSystemInformation).
    - Process creation or termination or suspension (NtCreateUserProcess (hook that function and it'll be triggered for all process execution on Windows Vista or above, for Windows 2000 or Windows XP you need to hook RtlCreateUserProcess instead), NtTerminateProcess and NtSuspendProcess) - there is also PsSetCreateProcessNotifyRoutine/Ex (can be used to intercept process creation & termination from kernel-mode which is more secure), ObRegisterCallbacks (protect processes against termination, suspension and injection).
    - Process manipulation (like injection): (RtlCreateUserThread (NTAPI equivalent for CreateRemoteThread), NtCreateThreadEx, NtGetThreadContext/NtSetThreadContext, NtAllocateVirtualMemory, NtWriteVirtualMemory, NtQueueUserAPC) (NtSetInformationProcess, NtSetInformationThread (unrelated to memory manipulation).
    - Registry changes (NtCreateKey, NtDeleteKey, NtSetValueKey, NtDeleteValueKey, NtFlushKey, etc), there is also CmRegisterCallback/Ex for kernel-mode callback.
    - I/O changes (NtCreateFile, NtDeleteFile, NtWriteFile, NtSetInformationFile), there is also FltRegisterFilter which is useful for protecting files on disk from modification and you can monitor for real-time via file system mini-filter driver.

    Other functions which may be interesting:
    - NtSetInformationProcess/RtlSetProcessIsCritical (the second one can make a force BSOD if the target process is terminated, the first function can do the same thing too by modifying the BreakOnTermination flag).
    - RtlAdjustPrivilege (used to enable privileges like debugging rights (SeDebugPrivilege)).
    - CreateProcessAsUser (if it's a SYSTEM process -> prevent new process start-ups under NT Authority without permission).
    - MoveFileEx (not really necessary to monitor usage as you can monitor registry changes to accomplish the same thing).
    - NtRaiseHardError (prevent force BSOD from user-mode apps).
    - Feel free to target screen-locking functions too for ransomware screen locks...

    You can use hooks on functions above or the kernel-mode callbacks above to do many things already such as:
    - Protect system processes (which are not already protected processes like csrss.exe on Windows versions below Windows :cool:.
    - Protect system directories (e.g. Windows folder).
    - Protect the Windows Hosts file (e.g. against unauthorized modifications).
    - Protect against DLL/stealth code injection (including Dynamic Forking or if you prefer calling it RunPE/Process Hollowing).
    - Protect against new service creations (can be done for device driver installation) or driver load attempts (rootkits tend to use NtLoadDriver/NtSetSystemInformation as opposed to the service manager functions).
    - Protect against new auto-run modifications.
    - Protect against system hijacking (Task Manager, registry tools disabling or setting changes for Windows Defender, Windows Firewall or User Account Control).
    - Protect against browser modifications (e.g. IE, Firefox, Chrome, Edge).
    - Protect against new process start-ups where the process is infringing on genuine Windows processes (e.g fake explorer.exe or winlogon.exe).
    - Protect against modifications to the Master Boot Record.
    - Protect against suspicious file modifications (e.g. ransomware signs).
    - Make a dynamic identification to auto-block the payload of the new DoubleAgent which hit the news hard and went viral lately, that's an incredibly easy patch to do.
    - Virtual patch existing exploits for UAC and the such.
    ... You can do so much more.

    There is always the hyper-visor which I did briefly mention earlier in my previous post, and using this can allow you to perform kernel-mode patch techniques like MSR hooks. However this is much more advanced, so this technology is quite precious IMO. Some vendors do use it, like Kaspersky and Comodo... Kaspersky used it really nicely IMO, and Comodo sandbox probably relies on it I guess.

    So as we can see, vendors can implement dynamic monitoring for BB/HIPS or dynamic heuristics whenever they want if they put in the time, regardless of PatchGuard, while supporting x64 systems too. The security risks are actually not too great because system-calls/unhooking is not prevalent in the wild yet at least, and if they have the money and time to spare then the hyper-visor usage would be the way to go.

    The Windows 2k source code was leaked back in 2004, you can go find it and read through to learn a bit more (I doubt MS will sue you for browsing for educational purposes), and ReactOS documentation can teach you quite a bit too (very similar to Windows, even has support for Windows apps from older versions too), WINE source code as well.

    ---------------------------------------
    @guest I think my work here is done now LOL :D, 2 hrs later of writing straight without moving... Happy Easter!? :p
     
  15. guest

    guest Guest

    @mWave this post just killed my brain...then i was thinking, i'm lucky (in some way ) not to be a coder :D
     
  16. guest

    guest Guest

    Indeed, i was a heavy user of Emsisoft OA and comodo, used them with customized "paranoid" mode. Because iIMO there is no point of using a soft without its most secure level.

    Yes , clean installation > install drivers and favorite soft , all offline) > install HPS > use learning mode > while done use paranoid mode.

    Exact

    with Appguard or anti-exe/application Control, i have the same result as a HIPS in paranoid mode , without the hassle of perpetual prompts. All benefits to me.
     
  17. B-boy/StyLe/

    B-boy/StyLe/ Registered Member

    Joined:
    Sep 19, 2012
    Posts:
    496
    Location:
    Bulgaria
    In my opinion the paranoid mode is too sensitive. It will bombard you with a lot of pop-ups (even after the training mode) and the protection level will not be much higher than the customized Safe Mode and it is not worthing to be used. The Safe Mode is more than enough and give a good balance of protection and usability.

    Ok but the anti-exe software will default deny all applications except the allowed ones. This lockdown provide a very solid protection but can be a pain to use especially if you install/update/test often new programs. I am not saying the ani-exe are bad. They are very cool but don't fit my needs.

    And what if some malware use the name/description/sign/path of a whitelisted software?

    I prefer HIPS so I can run whatever I want and still can track the changes and can decide to allow or block them. When I install a program and I am sure it is safe then I can choose the installer mode for that program and I will not receive any future prompts during the installation process. If I am not sure if it is trustworthy then I will use the Safe Mode to track the changes. Yeah, HIPS is not bullet-proof as well and it rely on my decisions and I always can make a mistake and that's where the sandbox come into play. So the prompts can be reduced a lot while using the HIPS as well thanks to the Auto-sandbox, cloud etc.
     
  18. guest

    guest Guest

    Indeed, one must be prepared and know what he is doing when using this mode.

    SRPs like Appguard (my favorite) or anti-exe preferred usage is in static systems; you don't use them if you install lot of softs every day.

    For classic anti-exe like NVT ERP, the malware won't have the same ckecksum (hash), so it execution will be blocked or generate an alert depending the setting.
    In Appguard, the malware must be in System Space to run, which is impossible unless it was there before Appguard was installed. Malware doesn't show up in System Space by magic, they have to be "imported" (internet, external devices, etc..) so since Appguard block everything in "User Space" (opposed to "System Space") so the malware can't run. Simple and very effective.

    That is the difference between SRP/anti-exe user and HIPS user. In my case , if i'm not 100% sure, i just don't install it. There is no such thing than i unknown file allowed to run in my system.
     
  19. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Exactly my point. Some HIPS give way too many alerts about senseless things. I would probably scrap almost half of the things mentioned in the Matousec article, scroll to "Potentially Dangerous Actions and Techniques".

    http://www.matousec.com/info/articles/features-of-modern-security-suites-part-2.php

    Exactly, this is something that you can't do with tools like AG, some people still don't get it.
     
  20. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Very interesting post! If I was a developer I would certainly buy your book, because everything in your post is described very clearly. And yes I agree that M$ made the right decision to implement PatchGuard. I also agree that HIPS/BB should still be able to offer strong protection on Win 64 bit systems. But about hyper-visors, I believe that no one is currently using it, or am I wrong?
     
  21. mWave

    mWave Guest

    Thank you :)

    A book from me would be great I agree hahah, if only I had a test on all of this back when I was doing my GCSEs last year... Maybe then I would actually pass an exam for once in my life... :p

    Yeah, some vendors can do a lot more than they are already doing for both architecture versions of their software, but I don't want to call any vendors out and ruin their day, especially since it's Easter. Microsoft do provide MS Detours, and most popular AV companies (the ones which are lacking especially) can easily afford the paid version for x64 process support, and from there on the only thing needed is some research on Windows Internals and malware analysis and some good IPC (Inter-process Communication - to show the GUI alerts and receive the response to allow/block for specific behavior monitoring functionality). Literally, if you have access to the paid version of MS Detours you are pretty much capable of developing a very promising dynamic heuristics system at ease because all you will need to focus on is the research, to actually hook the functions it's just a matter of calling a few functions and passing in parameters and then it'll do everything for you in the background (I would have done the same but I wanted to actually learn it myself, plus I never had the money for the paid version of MS Detours, and now I would rather just make my own hooking functions than use someone else's library).

    About the hyper-visor, I know for a fact that Kaspersky use it although it might just be for the internet security version and Comodo use virtualization too. However they use the hyper-visor for a number of things most likely, one of the things they definitely use it for is their Safe Browser program (to prevent screen capture affecting it), you can read more about that here on their official website: https://support.kaspersky.co.uk/12137

    If a third-party security product loses functionality if your processor does not support virtualization then that's a clear-view sign of them using virtualization (e.g. hyper-visor), and the user may have to manually enable it via the BIOS. Virtual Machines will typically require this too of course (such as VMWare). The hyper-visor is pretty strong against exploitation, but of course nothing is full-proof, since we have seen a few Gues-Host escapes in the past (but it's rare).

    If you can work the hyper-visor (it's easier said than done) then you won't have to worry about PatchGuard for a lot of things, you'll be able to set MSR/IDT hooks or even hook system calls. The only problem is that it will require extensive research and testing and it might take some time to develop on, because it won't be magically supported on all hardware (for example, you would need to change things or even entirely re-code it for that specific hardware). Intel invented technology under the title VT-x and this is built into Intel processors (most of them, especially the ones built these days, most people who have a system with an Intel processor will have a copy of the processor with it built-in), whereas AMD have their own virtualization built-in technology under the title SVM (AMD SVM). Therefore, you cannot just write some code to work the hyper-visor for an Intel-processor based system and expect it to work on a system with an AMD processor, it simply won't work like that due to the differences. Although, the Intel/AMD documentation will come in handy a lot when doing tasks like working the hyper-visor and of course there are open-source projects like VirtualBox which anyone can freely explore to learn a bit more about virtualization technology and actually utilizing it. Bear in mind that you will have to dig deeper than user-mode (ring 3) code, you'll need to use device drivers since that will give you the ability to access the hardware the same way that your Operating System can.

    That being said, it will depend on the OS version as well... You might get it all working for Intel based systems on Windows 10 (x64) but not for Windows 8.1 (x64), so it really does need to be tested properly and effectively by people who know what they are doing before anything is released with the virtualization uses.

    I hope this cleared some things up and answered your questions! :)
     
  22. guest

    guest Guest

    You like monitor stuff , good for you, i liked too before, but now i prefer block the source; so i don't need to waste my time to allow/deny the children.
    2 opinions to care of a system, 2 different mechanisms.
     
  23. B-boy/StyLe/

    B-boy/StyLe/ Registered Member

    Joined:
    Sep 19, 2012
    Posts:
    496
    Location:
    Bulgaria
    A user should be prepared when using all modes of HIPS. This is not a program for everyone.

    I agree. However I still have some SRP policies applied along with the HIPS just in case. CryptoPrevent added some of them but unfortunately he is using the %userprofile%\appdata\local\temp variables for the temp folder and I moved it to another drive to extend the lifespan of my SSD so I needed to add some personal rules to cover that issue. But sometimes I need to disable the rules like %temp%\*\*.exe, %temp%\7z*\*.exe, etc to be able to update Firefox and this is very annoying but a price I can afford for the extra security. :)

    Thanks for the clarification.

    Excuse me but there is no way to be sure if a file is fully trustworthy or not even if the VT results are 100% clean and the file is downloaded from a trustworthy site (the site can be compromised to host malware). That's why I like the auto-sandbox (and the motto of Sandboxie - Trust no program). I don't even need to use Vbox or Shadow Defender when I have an sandbox along with a HIPS. :)
    But yeah, It took me a lot of time to configure the HIPS for my personal needs so this can be a little frustrating for the average users. I know users who are using both programs (methods) and don't see nothing wrong with that as long it's not an overkill but yeah either the two programs are good choice for protecting the system. :)
     
  24. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    I haven't got any problems with you preferring one or the other, but if you keep saying stuff like: "I can do the same with AG", then you clearly don't get it. But seems like you do actually understand it, but sometimes you give the wrong impression.

    Exactly, that's why I joined this forum, to look for ways not to be depended of AV's that can easily be bypassed, even nowadays. The only solution is HIPS, but of course not all HIPS are user friendly. I was especially impressed with System Safety Monitor and Neoava Guard.
     
  25. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Another great post, and I didn't even know that tools like KIS and Comodo were already using hypervisors. This is a pretty big deal because this gives the option to basically run on top of the OS, and ensures you will always have more privileges than malware, pretty cool! But seems like they are only using it for the safe browsing and sandboxing features, which should be good enough. In theory it should also give an option to inspect the OS for rootkits that may have been able to bypass PatchGuard.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.