<\/div>\n\n\n\n
VI.<\/mark> Which are the common actions<\/mark> performed by malware?<\/p>\n\n\n\n\n
\n
- creating a copy<\/strong> of the original file – allows the malware to ensure persistence<\/li>
- hiding<\/strong> a file – ensures the malicious file is less likely to be noticed by the user<\/li>
- injecting code<\/strong> into another process – allows execution of code in the context of a process that is known to be clean (usually belonging to the OS)<\/li>
- creating startup registry key <\/strong>– to ensure persistence after system restart<\/li>
- disabling some critical OS functionalities<\/strong> (e.g., updates) or terminating critical processes<\/strong> – to keep the OS vulnerable<\/li><\/ul>\n\n\n\n
E.g. 2, backdoor trojan<\/span>: it usually connects to a malicious command and control server, from which it waits further instructions and can execute other payloads.<\/code><\/p>\n<\/div>\n\n\n\n\n
<\/p>\n\n\n\n
E.g. 1, ransomware<\/span> actions:<\/code><\/p>\n\n\n\n1.<\/span><\/strong> drop a copy of itself on the disk
2.<\/span><\/strong> launch a copy of itself
3.<\/span><\/strong> delete backup (shadow) files
4.<\/span><\/strong> inject code into another process
5.<\/span><\/strong> enumerate and encrypt files
6.<\/span><\/strong> display message to the user to demand ransom for the encrypted data<\/code><\/p>\n<\/div>\n<\/div>\n\n\n\nThere are 3 actions, very common in malware, that are especially encountered in installers<\/strong> & uninstallers<\/strong> ( => risk of False Positives): writing executable files in the System \/ Windows \/ Temporary folders<\/span>, executing the created files<\/span> and registering an executable to run at start-up<\/span> => there’s a need to distinguish between ordinary executable files and installers\/uninstallers. Legit installers are usually generated by common software installation packages, and can be identified by scanning the file for certain signatures<\/strong>.<\/p>\n\n\n\n<\/div>\n\n\n\n
VII.<\/mark> How to smartly evaluate<\/mark> the intercepted actions?<\/p>\n\n\n\nA generic approach is using a scoring engine<\/em><\/span><\/strong>, which contains heuristics able to detect samples that use various new combinations of malicious actions. A set of predefined features are extracted (from the executable file or based on the actions of the analyzed process). Each feature has an associated score<\/span><\/strong>, that is used to compute a general score for the sample. If that score exceeds a predefined threshold<\/span>, the sample is either categorized as a certain type of malware or as clean.<\/p>\n\n\n\nWhen thinking of complex malware scoring mechanisms, one may believe that the solution can be implemented using artificial intelligence<\/span> (AI<\/strong><\/span>). An AI algorithm performs well enough in face recognition, for example, because human faces do not change their definitory characteristics over time. But malware evolves at a rapid pace<\/span>, to use the latest features provided by operating systems and programming languages, as well as to exploit the latest unpatched<\/span> ( zero-day<\/span><\/strong> ) vulnerabilities<\/span>. Therefore, the scoring engine must be easy to understand and maintain, precise, predictable to changes, and needs to be updated very quickly<\/span>. This is NOT easily achieved with an AI algorithm, where the training is time consuming and the results cannot be anticipated, not to mention the constantly required re<\/strong>-training. Also, adding a new heuristic may damage the entire scoring mechanism. Furthermore, an appropriate training set for dynamic malware detection is almost impossible to find<\/span>.<\/p>\n\n\n\nIn practice<\/span>, adapting the scoring engine to a new threat should require writing a couple of heuristics and calibrating the scores and weights only for them. More exactly, when another malware technique appears in the wild, a security researcher needs to test the security solution against samples or proof of concepts<\/span> (POCs) that exhibit the new behavior. He \/ She may also manually<\/span> capture the behavior of the processes by simply using a tool like Process Monitor<\/a><\/span><\/em><\/strong>. If the current detection model does not identify the new malicious technique, it’s a clear sign that the current model must be extended.<\/p>\n\n\n\nIn a broader perspective, such a solution should be integrated in a modern security application, together with other components such as URL blocking, firewall, classic AV signatures, etc.<\/p>\n\n\n\n
<\/div>\n\n\n\n
VIII.<\/mark> Now, which are the smart tricks<\/mark> used to stay under the radar?<\/p>\n\n\n\n- solutions that use dependency graphs<\/span> constructed from API \/ system calls, may be evaded by replacing a call sequence with its semantic equivalent and\/or inserting redundant calls<\/li>
- instead of executing all the malicious actions in a single process, distribute<\/span><\/strong> the payload to multiple, distinct processes, to be executed over a long period of time. <\/span>Because behavior-based detection cannot identify a process based on a single action (due to the risk of False Positives), multiple individual processes, each performing a smaller set of actions, may go unnoticed<\/span>.
Injecting<\/span> the payload in multiple processes also makes cleanup difficult: if only one affected process is terminated, the malware is capable of re-instantiating itself from another injected process.
The distinct malicious processes (that make up an attack) may communicate<\/span> using traditional inter-process communication, supported by the OS, or through purposely implemented mechanisms.<\/li><\/ul>\n\n\n\n- Windows<\/strong> OS<\/strong> problems that make exploitation easier<\/span>:
- it does not keep a strict relation between child processes and parent processes => managing related processes for detection is more difficult, requiring OS specific knowledge<\/li>
- it allows code to be injected in a trivial way and does not provide a synchronous notification when injections occur => detecting all code injection methods is also considerably hard<\/li><\/ul><\/li><\/ul>\n\n\n\n
<\/div>\n\n\n\n
IX.<\/mark> How do we combat<\/mark> multi-process<\/mark> malware, though?<\/p>\n\n\n\n- represent the actions performed by each process as feature vectors, then correlate them with the actions performed by the child processes. Disadvantages: difficult to implement, does not consider code injection when correlating processes.<\/li>
- divide the processes into categories: group creators<\/em> (they create other processes, not necessarily related to them), group inheritors<\/em> and unmonitored processes<\/em>. By assigning a category \/ role to each process<\/span>, the groups of processes are much easier to identify and manage. The category of a process can be identified based on features like: the file path, the digital signature or a hash computed for the executable file. <\/li>
- as installers can be used as a spreading mechanism<\/span>, when an installation starts, the solution should create a process lineage tree<\/span><\/em><\/strong>, in which the root is the initial installer application. When the root or a descendant creates a new process, it should be added to the lineage tree as a child of the process that created it. This way, we can observe better the deepness and the exact activity of that installation, as it happens.<\/li><\/ul>\n\n\n\n
<\/div>\n\n\n\n
X.<\/mark> How about the advanced cyberattacks & cyberweapons <\/mark>