Mar 6, 2018 07:02 AM
(This post was last modified: Mar 6, 2018 07:03 AM by CyberStrike.)
Disclaimers: I am not an expert on either AV solutions for both end-user as well as enterprise solutions, but have picked up a little bit.
How AV works in general:
Software has is categorized in one of the following lists :
BlackListing - blocked
WhiteListing - allowed to run
Malware is generally detected using one of the following:
Signature Based - Signature based detections uses specific header/strings/file size or patterns (packer used/byte sequence ..etc) within a file to check if it is good or bad. These signatures are often found from malware samples. Of course there can be false positives here.
Disadvantage: If you test enough you can find the signature and slightly change it, also compiling with a different compiler can change the signature.
Behavior Based - here the AV will try to determine the behavior of the software to see if it matches known techniques used by security tools or malware. This is where often we may see a “trojan.gen” it is matching a heuristic pattern found in other malware.
Disadvantage: The software has to be analyzed within a sandbox and often encrypted/compressed of self modifying code is not analyzed during this. (Due to this you often have encrypted payloads being flagged)
Something else to note is that your AV requires a lot of resources and cannot analyze a program indefinitely, so if malicious actions are carried out afterwards So also while sandboxes try to be hidden from malware often malware can scan for them and sleep until after the evaluation is complete.
(Note is that generally AV products do not do anything about exploitation, but Mcafee Enterprise solution does)
Not All AV's are the same:
Often we will find on VT (VirusTotal) the engines are more gears for heuristics and have beta signatures so it's not quite like your home AV solution. Also false positives are more common.
In Memory Detections:
Below are common detection techniques pretty much consider them as “Tells” as well as tools to detect such odd behavior
• Memory Detection
◇ Process
▪ Parent Process
▪ Process Name
▪ Process Signer
▪ Valid Signature - code signing some MS products are not scanned since false positives will break an entire network
▪ Command Line Agrs
▪ Current working directory- Temp files are often flagged
◇ Thread
▪ Thread ID
▪ Start Address
▪ Start Address Module
▪ Priority
◇ Memory Properties
▪ Base Address
▪ Type of Memory
▪ State of Memory
▪ Size
▪ File
▪ Initial Permissions (not in process hacker)
▪ Permissions
Tools for Detections:
Process Hacker
LOKI
YARA (used by some AV's)
Get-InjectedThread
Something to note here, "odd" things should not translate to “Intent” of an application being malicious. AV solutions generally give a free pass to system critical as well as other security tools, because if a critical system file is flagged and it is a false positive that's going to be a lot of angry customers. We have our tools and we have an idea of what we are looking for but what exactly?
• Detection
◇ Thread Start Address - No module associated with the start address. Look for DLL that is not mapped in the current process mapped files. Programs call functions which are run under the program or a function in the DLL as a memory mapped DLL.
◇ Memory Permissions - RWX permissions common pattern or AllocateProtect and Protect Pairs, for example starting in RW then adding the X flag is a common indictator in offensive tools.
◇ Memory Content - Headers of a PE not associated with files on disk or the strings with that file. EG MZ This program cannot be run in DOS mode.
• Memory Detection Applications
◇ Point IN TIme Analysis - non persistent software deployed once. runs through current processes and threads, investigates content and properites reports signs of malicious activity allows human to make determination.. some false positives are OK
◇ RealTIme Detection/prevention - Less false positives are OK it can break the network or machine. Persistent software; Even Driven Investigates content and properties correlating multiple signs. From there is can do nothing or send an alert or terminate the action. Some AV and other solutions use these techniques
Now one should note that memory detection applications especially the ones preventing if they have a false positive remember those angry customers well they will be back. So now that we have a rough idea as to what exactly that we are dealing with how do we avoid it?
First let me ask when you start up chrome or firefox are you downloading a portable version and running it each time from a temporary directory? No that'd be crazy so stageless files on disk for the initial payload would help it would better blend in and appear more natural. As we know nowadays IR (Incident Response) always should and will dump the memory, so consider encrypting that memory. Remember that each payload has it's own heuristics :
Evasion:
Before going to in memory first let us look at common methods for AV evasion :
• Polymorphism/Metamorphism - new signature on each run
• Encryption
• Sanbox Detection
• Process Injection
• Applocker Bypasses
Shellcoder loaders, are perhaps not commonly used but you can use python/c/powershell and more to load shellcode into memory during execution of your program or script. Using ShellForge we can quickly take C source code, perhaps our dropper with a sleep function have it in assembly and have that shell code injected as part of a larger staged payload. The dropped file maybe a powershell script which will use an applocker bypass and inject our payload into an existing process.
Detection is done by detecting anomalies and are not a indicator of intent: So not doing the things that we are going to be detected is important
• Thread Start Address
◇ EXE/DLL OK
◇ Process Hollowing: stick to architecture
◇ Avoid Hijacking Existing Remote Threads
• Do not start a new thread with an abitrary pointer.
◇ Instead hijack existing threads use SetThreadContext/LoadLibrary/CreateRemoteThread.. For LoadLibrary you will have to drop to disk.
• Memory Permissions:
◇ Avoid RWX instead map a DLL and over write the memory
• Memory Content:
◇ Don't look like a DLL unless expected
◇ Obfuscate or remove strings that can be used in IR
◇ avoid stagers
▪ Harder to notice the attacker by the content in the memory
Append NOP to start of payload
• Process Injection
◇ Allocate memory in remote process
◇ copy program to remote process
◇ Create thread to run program
• Process Hollowing
◇ Allocate memory in remote process
◇ Copy program to remote process
◇ Hijack existing thread to run program
A word on OPSEC:
After your payload is somewhat not quite ready to head out to the target say before you have used your code signing certificate we have to see what can be found if that file is captured.
Against your payload run (consider saving it as a bin here)
strings -e {s,S,b,l,B,L} payload.exe
strings payload.exe
hexdump -C payload.exe
In Metasploit using post modules such as “payload_inject” “reflective_dll_inject" and executing a new payload.
ProcessHollowing is fine for same architecture.
(Refrences and most will be posted @ 8000 character limit)
Let's discuss a bit the future of AV, in recent tests with using signature based detection researchers studying worm variants detected 323 features and were able to identify 5 more variants that were previously unknown. Using only 20 of the features they had a success rate of greater than 90%. AntiVirus researchers have also started to analyze OPCODE, assembly language instructions which interact with the CPU, as of right now researchers dealing with obfuscated malware are just over 85% successful, using this technique for detection.
(The Effects of Traditional Anti-Virus Labels on Malware Detection Using Dynamic Runtime Opcodes)
References:
https://en.wikipedia.org/wiki/Antivirus_software
https://en.wikipedia.org/wiki/Static_program_analysis
https://en.wikipedia.org/wiki/Dynamic_program_analysis
https://en.wikipedia.org/wiki/Heuristic_analysis
https://www.symantec.com/connect/article...-reference
The Antivirus Hacker’s Handbook
AntiVirus FIrewall Evasion Techniques Evolution Of Download Deploy Shellcode
WhitePaper: Bypassing Antivirus with a Sharp Syringe
Outsmarted: Why Malware Works in the face of Antivirus Software
The Effects of Traditional Anti-Virus Labels on Malware Detection Using Dynamic Runtime Opcodes
How AV works in general:
Software has is categorized in one of the following lists :
BlackListing - blocked
WhiteListing - allowed to run
Malware is generally detected using one of the following:
Signature Based - Signature based detections uses specific header/strings/file size or patterns (packer used/byte sequence ..etc) within a file to check if it is good or bad. These signatures are often found from malware samples. Of course there can be false positives here.
Disadvantage: If you test enough you can find the signature and slightly change it, also compiling with a different compiler can change the signature.
Behavior Based - here the AV will try to determine the behavior of the software to see if it matches known techniques used by security tools or malware. This is where often we may see a “trojan.gen” it is matching a heuristic pattern found in other malware.
Disadvantage: The software has to be analyzed within a sandbox and often encrypted/compressed of self modifying code is not analyzed during this. (Due to this you often have encrypted payloads being flagged)
Something else to note is that your AV requires a lot of resources and cannot analyze a program indefinitely, so if malicious actions are carried out afterwards So also while sandboxes try to be hidden from malware often malware can scan for them and sleep until after the evaluation is complete.
(Note is that generally AV products do not do anything about exploitation, but Mcafee Enterprise solution does)
Not All AV's are the same:
Often we will find on VT (VirusTotal) the engines are more gears for heuristics and have beta signatures so it's not quite like your home AV solution. Also false positives are more common.
In Memory Detections:
Below are common detection techniques pretty much consider them as “Tells” as well as tools to detect such odd behavior
• Memory Detection
◇ Process
▪ Parent Process
▪ Process Name
▪ Process Signer
▪ Valid Signature - code signing some MS products are not scanned since false positives will break an entire network
▪ Command Line Agrs
▪ Current working directory- Temp files are often flagged
◇ Thread
▪ Thread ID
▪ Start Address
▪ Start Address Module
▪ Priority
◇ Memory Properties
▪ Base Address
▪ Type of Memory
▪ State of Memory
▪ Size
▪ File
▪ Initial Permissions (not in process hacker)
▪ Permissions
Tools for Detections:
Process Hacker
LOKI
YARA (used by some AV's)
Get-InjectedThread
Something to note here, "odd" things should not translate to “Intent” of an application being malicious. AV solutions generally give a free pass to system critical as well as other security tools, because if a critical system file is flagged and it is a false positive that's going to be a lot of angry customers. We have our tools and we have an idea of what we are looking for but what exactly?
• Detection
◇ Thread Start Address - No module associated with the start address. Look for DLL that is not mapped in the current process mapped files. Programs call functions which are run under the program or a function in the DLL as a memory mapped DLL.
◇ Memory Permissions - RWX permissions common pattern or AllocateProtect and Protect Pairs, for example starting in RW then adding the X flag is a common indictator in offensive tools.
◇ Memory Content - Headers of a PE not associated with files on disk or the strings with that file. EG MZ This program cannot be run in DOS mode.
• Memory Detection Applications
◇ Point IN TIme Analysis - non persistent software deployed once. runs through current processes and threads, investigates content and properites reports signs of malicious activity allows human to make determination.. some false positives are OK
◇ RealTIme Detection/prevention - Less false positives are OK it can break the network or machine. Persistent software; Even Driven Investigates content and properties correlating multiple signs. From there is can do nothing or send an alert or terminate the action. Some AV and other solutions use these techniques
Now one should note that memory detection applications especially the ones preventing if they have a false positive remember those angry customers well they will be back. So now that we have a rough idea as to what exactly that we are dealing with how do we avoid it?
First let me ask when you start up chrome or firefox are you downloading a portable version and running it each time from a temporary directory? No that'd be crazy so stageless files on disk for the initial payload would help it would better blend in and appear more natural. As we know nowadays IR (Incident Response) always should and will dump the memory, so consider encrypting that memory. Remember that each payload has it's own heuristics :
Evasion:
Before going to in memory first let us look at common methods for AV evasion :
• Polymorphism/Metamorphism - new signature on each run
• Encryption
• Sanbox Detection
• Process Injection
• Applocker Bypasses
Shellcoder loaders, are perhaps not commonly used but you can use python/c/powershell and more to load shellcode into memory during execution of your program or script. Using ShellForge we can quickly take C source code, perhaps our dropper with a sleep function have it in assembly and have that shell code injected as part of a larger staged payload. The dropped file maybe a powershell script which will use an applocker bypass and inject our payload into an existing process.
Detection is done by detecting anomalies and are not a indicator of intent: So not doing the things that we are going to be detected is important
• Thread Start Address
◇ EXE/DLL OK
◇ Process Hollowing: stick to architecture
◇ Avoid Hijacking Existing Remote Threads
• Do not start a new thread with an abitrary pointer.
◇ Instead hijack existing threads use SetThreadContext/LoadLibrary/CreateRemoteThread.. For LoadLibrary you will have to drop to disk.
• Memory Permissions:
◇ Avoid RWX instead map a DLL and over write the memory
• Memory Content:
◇ Don't look like a DLL unless expected
◇ Obfuscate or remove strings that can be used in IR
◇ avoid stagers
▪ Harder to notice the attacker by the content in the memory
Append NOP to start of payload
• Process Injection
◇ Allocate memory in remote process
◇ copy program to remote process
◇ Create thread to run program
• Process Hollowing
◇ Allocate memory in remote process
◇ Copy program to remote process
◇ Hijack existing thread to run program
A word on OPSEC:
After your payload is somewhat not quite ready to head out to the target say before you have used your code signing certificate we have to see what can be found if that file is captured.
Against your payload run (consider saving it as a bin here)
strings -e {s,S,b,l,B,L} payload.exe
strings payload.exe
hexdump -C payload.exe
In Metasploit using post modules such as “payload_inject” “reflective_dll_inject" and executing a new payload.
ProcessHollowing is fine for same architecture.
(Refrences and most will be posted @ 8000 character limit)
Let's discuss a bit the future of AV, in recent tests with using signature based detection researchers studying worm variants detected 323 features and were able to identify 5 more variants that were previously unknown. Using only 20 of the features they had a success rate of greater than 90%. AntiVirus researchers have also started to analyze OPCODE, assembly language instructions which interact with the CPU, as of right now researchers dealing with obfuscated malware are just over 85% successful, using this technique for detection.
(The Effects of Traditional Anti-Virus Labels on Malware Detection Using Dynamic Runtime Opcodes)
References:
https://en.wikipedia.org/wiki/Antivirus_software
https://en.wikipedia.org/wiki/Static_program_analysis
https://en.wikipedia.org/wiki/Dynamic_program_analysis
https://en.wikipedia.org/wiki/Heuristic_analysis
https://www.symantec.com/connect/article...-reference
The Antivirus Hacker’s Handbook
AntiVirus FIrewall Evasion Techniques Evolution Of Download Deploy Shellcode
WhitePaper: Bypassing Antivirus with a Sharp Syringe
Outsmarted: Why Malware Works in the face of Antivirus Software
The Effects of Traditional Anti-Virus Labels on Malware Detection Using Dynamic Runtime Opcodes
