July 2, 2014 at 16:15The magic formula or how to see the threat
Every system works according to a unique algorithm, without an algorithm it is not a system. Flexible, rigid, linear, branching, deterministic, stochastic - it does not matter. It is important that in order to achieve the best result, the system is subject to certain rules. We are often asked about the algorithms of our product, in particular: how are competitors better able to calculate future threats? For obvious reasons, all-all the details of this magic formula cannot be revealed, but you can slightly open the door of our technological kitchen and find out something.
In the general case, we use the deductive method, that is, we go from the general to the particular. In our case, it could look something like this: all the malicious programs do this -> this file also does this -> therefore, the file is a malware. But in practice, not everything is so simple and smooth.
First of all, it is impossible to single out specific actions that unambiguously indicate the harmfulness of an object. A classic example with access to MBR - you can’t consider everything that pulls this command as a malware, there are many other peaceful uses for it. The same applies to all other actions. After all, in the original all the teams were created to do some useful things.
In other words, the task of “separating the grains from the chaff” is inappropriate here. Another thing is to estimate the proportions and composition of the grains and the chaff, evaluate the same parameters in the neighboring barn, analyze the results and even then make an informed decision about setting a comma in the phrase "you can not miss the cure." To do this, we use technology with the simple name SR (Security Rating) - a sort of branchy, self-learning system of scales that helps to better understand the true nature of an object in the process of its formal assessment and emulation .
The analysis takes into account the composition and density of events generated by the object and its external attributes (name, size, location, compression, etc.). Based on a set of rules, each of the parameters receives an individual hazard rating (0-100%). The first set of rules (and there are more than 500 of them now) was the result of a “manual” study of more than 80 thousand unique malware of various families. Now, the rules are developed mostly automatically, and expert analysts only "twist" self-learning algorithms.
For convenience of testing and maintenance, the rules are divided into groups (for example, “Internet”, “Passwords”, “Registry”, etc.) and if the object “inherits” its behavior in one or more of them, appropriate sanctions are taken.
Examples of simple rules:
Rule "Downloading the driver through the low-level API ntdll.dll"
API function: Downloading the driver (NtLoadDriver)
Argument 1: *
Argument 2: *
Argument 3..N: *
Rating: single operation - 40% , 2-3 operations - 50% , > 3 operations - 60%
Maliciousness: None
Rule “Analysis of the kernel machine code (removing hooks)”
API function: Create / open a file (CreateFile)
Argument 1: Contains the entry “ntoskrnl.exe”
Argument 2: *
Argument 3..N: *
Assessment: single operation - 100% , 2-3 operations -100% ,> 3 transactions - 100%
Maliciousness: Yes
The final rating of the property is the sum of all private ratings after checking the entire rules database. In other words, this is a typical neural network that collects signals from a variety of sensors, analyzes their qualitative and quantitative characteristics, explores communications and issues a verdict. Approximately in this form, SR took to the shift in 2007. (patent US7530106 ). As you guessed, we immediately combed the technology to feed, educate and pump.
Problem Number One was that the analyzed file could generate a huge number of minor events that could not affect the final verdict on its harmfulness. For example, a Delphi application generates up to 500 of these events at startup. They will be identical for any application written in this language and at the same time do not carry any useful information about the real intentions of the file. This “noise” not only consumed computer resources, but also made analysis difficult.
To filter out such noise, we made a filter. Moreover, unlike usual rules, a Boolean sign is enough here. Thus, the rule is greatly simplified and, accordingly, its work is accelerated. As a result, the rules contain only the API name of the function and the mask for its arguments.
For example:
SysAllocString (*, - NULL -, - NULL-)
Here, if the first argument of the function has any value, and the rest are absent, then the event will be considered insignificant.
To automatically generate filtering rules for minor events, we used three methods.
The first is the Drosophila method. We are preparing an application of the “Hello World” type using the development environment X, we will use its most popular libraries whenever possible. We feed the compiled application to the emulator, and write down all the events generated by the Drosophila in the column “insignificant”.
The second is the “Packed Drosophila Method”. Similar to the first, except that we are interested in the behavioral events of the packer / tread. To do this, we process the dummy in Assembler in turn with all sorts of packers and protectors, feed the emulator and ... well, then you guessed it.
The third method is statistical. We analyze the behavior of a large number of legitimate and malicious files, and highlight the API calls that are often found in the behavior of both. This method complements the first two and is effective if it is not possible to create a "Drosophila". A typical example of functions identified in this way are functions for working with the GUI and allocating memory.
But it was one of the smallest challenges. More interesting.
The first version of SR worked on a particular protected computer almost in isolation. We did not have a global picture, we did not understand what rules, how often and how accurately they worked, and could not quickly change their ratings. The result - big unused opportunities to increase efficiency :) Then, we developed in full swingKSN cloud and we already screwed the Astraea expert system to it to analyze the gigantic volume of signals from protected computers and issue reasonable conclusions about the epidemiological situation in the world.
In 2009, to everyone's joy, the next version of SR (SR2, US8640245 ) merged with KSN and Astraea.
A bigdata with a good expert add-on is the “materiel” of success formula in our area!
In fact, we got leverage for (i) “shooting” ineffective and “dead” rules, (ii) temporarily disabling or testing the rules, (iii) almost real-time correction of rule ratings using coefficients. At the same time, the size of the coefficient base was ridiculous kilobytes and its updating, even in those years, practically did not load the Internet channel.
Astraea has also expanded the statistical base for calculating ratings: not only signals from various emulators, but also many other sensors that also reported to KSN took part in this process. In addition, the product could receive an already known verdict from the cloud and make a decision without completing the emulation process (and in some cases without launching it at all). And another nice plus - we can, with a high degree of certainty, extract from the stream for manual research unknown "animals" who did not score the rating threshold but behaved very suspiciously.
It is important that Astraea makes the correction of rules automatically - it remains for the person to regularly evaluate the effectiveness of the mathematical model used and optimize it (patent application US20140096184 ).
The presence of the global bigdata immediately rolled our lip to new ideas for solving old problems. First of all - falsifications . In principle, we have been tweaking this topic from the very first day of implementing SR in products. But in 2011. rolled out several new features at once to minimize false positives.
There are many operations that are performed by legitimate software with completely peaceful purposes. For example, installers delete files in the System32 folder. Auto-adjusting the rating of this operation will lead to its unreasonable degradation and we will begin to skip real malware. A compromise solution is required here so that the wolves are well fed and the sheep are safe. And then we decided to divide the rating calculation mechanism into 3 parts.
Firstly, the calculation described above: the more dangerous the behavior and the more common, the higher the rating. Secondly, a kind of whitelist is a rule that cancels or corrects the actions of ordinary rules applicable to specific situations or files. Thirdly, the rules for detecting legitimate applications that reduce the hazard rating when characteristic behavior is detected and can even form a security rating.
Example:
Rule "Create an autorun key"
API function: Registry: setting the parameter value (RegSetValueEx)
Argument 1: Contains the entry "\ Registry \ Machine \ Software \ Classes \ * \ shellex \ ContextMenuHandlers \ Notepad ++"
Argument 2: *
Argument 3 .. N: *
Rating: single operation - 1% , 2-3 operations - 1% ,> 3 operations - 1%.
Maliciousness: No.
Here you can clearly see that the registry key is jerking, but this is just Notepad ++ throwing its library. The rule argument removes the fall, while the basic rule remains unchanged and other attempts to change the key will work as expected.
And in 2011, we introduced another useful feature. As mentioned above, in SR, the rules worked autonomously from each other, and thus we could not study complex dependencies such as “uploading a file” - “saving a file to disk” - “writing to autorun”. After all, if you trace this dependence, you can give a rating much more than the sum of the ratings of individual events. Or less :) And then we decided to implement event correlation in SR2 for a more accurate detection of unknown malware.
We did this in two ways. First, they created bit masks that highlight groups of rules or individual rules by OR and AND. The basic description is a bit index for classifying behavior. Initially, this was invented for clustering malware by the peculiarities of their behavior, but a similar approach can be used to refine the rating score - use masks to implement a function of the type (RULE76 or RULE151) and (RULE270 or RULE540). The advantage of such masks is compactness and speed, the disadvantage is low flexibility.
Secondly, they made special scripts that conduct global analysis after calculating SR (patent US8607349) Scripts can be run alternately, either independently or by triggering a rule. Each of them has access to the database of accumulated statistics of previously worked out rules and rule groups. As a result, we have the opportunity (i) to use complex logic - conditions, calculations, loops, calling routines; (ii) make the most of neural networks; (iii) to form with the script not only a refinement to the SR rating, but also new knowledge that will be applied by subsequent scripts.
For example, the first script, based on an analysis of a dozen rules, concludes "the application is trying to get the passwords of other programs." The second script similarly concludes "the application is transmitting something to the Internet." The third script draws a conclusion like “if the application shows interest in passwords and transfers something to the Internet, THEN + 100% rating”.
In addition, scripts can be “attached” to any rule; in total, the rule becomes a kind of “trigger” for some algorithm.
Example script:
In this example, the script evaluates the file creation operation. We check the fact of creating the file in the root of the disk, and for this we immediately charge 20% SR. Further, depending on the file extension, we accrue an additional rating with the “+” or “-” sign.
The given example demonstrates the main plus of the scripts - the possibility of a complex differentiated assessment of function arguments with setting an individual SR rating according to the results of various checks. Moreover, some checks can increase the rating, some - lower, which allows you to make complex checks and complex analysis aimed at additional suppression of falsifications.
As a bonus, the author’s hand drawing of the technology described above. As is, almost on a napkin:
And now a little about the future.
The lineup is coming soonpersonal products of 2015. In general, we thought, weighed and decided to completely abandon the local SR and completely transfer the rating calculation to the cloud. This approach has many advantages at once. The quality of the analysis will not suffer, but the consumption of resources of the protected computer will decrease by an order of magnitude - all calculations will occur in our infrastructure. At the same time, the delay in delivering the verdict will be ... mneee ... but practically nothing will be: only a special software can notice these fractions of a millisecond.
Well, so briefly about our magic formula, only 10 thousand characters. And this is really only a “slightly ajar door”: in fact, acquaintance with a detailed description of the technology will take several days and a lot of refinement.
By the way, you can clarify right now, in the comments below.
In the general case, we use the deductive method, that is, we go from the general to the particular. In our case, it could look something like this: all the malicious programs do this -> this file also does this -> therefore, the file is a malware. But in practice, not everything is so simple and smooth.
First of all, it is impossible to single out specific actions that unambiguously indicate the harmfulness of an object. A classic example with access to MBR - you can’t consider everything that pulls this command as a malware, there are many other peaceful uses for it. The same applies to all other actions. After all, in the original all the teams were created to do some useful things.
In other words, the task of “separating the grains from the chaff” is inappropriate here. Another thing is to estimate the proportions and composition of the grains and the chaff, evaluate the same parameters in the neighboring barn, analyze the results and even then make an informed decision about setting a comma in the phrase "you can not miss the cure." To do this, we use technology with the simple name SR (Security Rating) - a sort of branchy, self-learning system of scales that helps to better understand the true nature of an object in the process of its formal assessment and emulation .
The analysis takes into account the composition and density of events generated by the object and its external attributes (name, size, location, compression, etc.). Based on a set of rules, each of the parameters receives an individual hazard rating (0-100%). The first set of rules (and there are more than 500 of them now) was the result of a “manual” study of more than 80 thousand unique malware of various families. Now, the rules are developed mostly automatically, and expert analysts only "twist" self-learning algorithms.
For convenience of testing and maintenance, the rules are divided into groups (for example, “Internet”, “Passwords”, “Registry”, etc.) and if the object “inherits” its behavior in one or more of them, appropriate sanctions are taken.
Examples of simple rules:
Rule "Downloading the driver through the low-level API ntdll.dll"
API function: Downloading the driver (NtLoadDriver)
Argument 1: *
Argument 2: *
Argument 3..N: *
Rating: single operation - 40% , 2-3 operations - 50% , > 3 operations - 60%
Maliciousness: None
Rule “Analysis of the kernel machine code (removing hooks)”
API function: Create / open a file (CreateFile)
Argument 1: Contains the entry “ntoskrnl.exe”
Argument 2: *
Argument 3..N: *
Assessment: single operation - 100% , 2-3 operations -100% ,> 3 transactions - 100%
Maliciousness: Yes
The final rating of the property is the sum of all private ratings after checking the entire rules database. In other words, this is a typical neural network that collects signals from a variety of sensors, analyzes their qualitative and quantitative characteristics, explores communications and issues a verdict. Approximately in this form, SR took to the shift in 2007. (patent US7530106 ). As you guessed, we immediately combed the technology to feed, educate and pump.
Problem Number One was that the analyzed file could generate a huge number of minor events that could not affect the final verdict on its harmfulness. For example, a Delphi application generates up to 500 of these events at startup. They will be identical for any application written in this language and at the same time do not carry any useful information about the real intentions of the file. This “noise” not only consumed computer resources, but also made analysis difficult.
To filter out such noise, we made a filter. Moreover, unlike usual rules, a Boolean sign is enough here. Thus, the rule is greatly simplified and, accordingly, its work is accelerated. As a result, the rules contain only the API name of the function and the mask for its arguments.
For example:
SysAllocString (*, - NULL -, - NULL-)
Here, if the first argument of the function has any value, and the rest are absent, then the event will be considered insignificant.
To automatically generate filtering rules for minor events, we used three methods.
The first is the Drosophila method. We are preparing an application of the “Hello World” type using the development environment X, we will use its most popular libraries whenever possible. We feed the compiled application to the emulator, and write down all the events generated by the Drosophila in the column “insignificant”.
The second is the “Packed Drosophila Method”. Similar to the first, except that we are interested in the behavioral events of the packer / tread. To do this, we process the dummy in Assembler in turn with all sorts of packers and protectors, feed the emulator and ... well, then you guessed it.
The third method is statistical. We analyze the behavior of a large number of legitimate and malicious files, and highlight the API calls that are often found in the behavior of both. This method complements the first two and is effective if it is not possible to create a "Drosophila". A typical example of functions identified in this way are functions for working with the GUI and allocating memory.
But it was one of the smallest challenges. More interesting.
The first version of SR worked on a particular protected computer almost in isolation. We did not have a global picture, we did not understand what rules, how often and how accurately they worked, and could not quickly change their ratings. The result - big unused opportunities to increase efficiency :) Then, we developed in full swingKSN cloud and we already screwed the Astraea expert system to it to analyze the gigantic volume of signals from protected computers and issue reasonable conclusions about the epidemiological situation in the world.
In 2009, to everyone's joy, the next version of SR (SR2, US8640245 ) merged with KSN and Astraea.
A bigdata with a good expert add-on is the “materiel” of success formula in our area!
In fact, we got leverage for (i) “shooting” ineffective and “dead” rules, (ii) temporarily disabling or testing the rules, (iii) almost real-time correction of rule ratings using coefficients. At the same time, the size of the coefficient base was ridiculous kilobytes and its updating, even in those years, practically did not load the Internet channel.
Astraea has also expanded the statistical base for calculating ratings: not only signals from various emulators, but also many other sensors that also reported to KSN took part in this process. In addition, the product could receive an already known verdict from the cloud and make a decision without completing the emulation process (and in some cases without launching it at all). And another nice plus - we can, with a high degree of certainty, extract from the stream for manual research unknown "animals" who did not score the rating threshold but behaved very suspiciously.
It is important that Astraea makes the correction of rules automatically - it remains for the person to regularly evaluate the effectiveness of the mathematical model used and optimize it (patent application US20140096184 ).
The presence of the global bigdata immediately rolled our lip to new ideas for solving old problems. First of all - falsifications . In principle, we have been tweaking this topic from the very first day of implementing SR in products. But in 2011. rolled out several new features at once to minimize false positives.
There are many operations that are performed by legitimate software with completely peaceful purposes. For example, installers delete files in the System32 folder. Auto-adjusting the rating of this operation will lead to its unreasonable degradation and we will begin to skip real malware. A compromise solution is required here so that the wolves are well fed and the sheep are safe. And then we decided to divide the rating calculation mechanism into 3 parts.
Firstly, the calculation described above: the more dangerous the behavior and the more common, the higher the rating. Secondly, a kind of whitelist is a rule that cancels or corrects the actions of ordinary rules applicable to specific situations or files. Thirdly, the rules for detecting legitimate applications that reduce the hazard rating when characteristic behavior is detected and can even form a security rating.
Example:
Rule "Create an autorun key"
API function: Registry: setting the parameter value (RegSetValueEx)
Argument 1: Contains the entry "\ Registry \ Machine \ Software \ Classes \ * \ shellex \ ContextMenuHandlers \ Notepad ++"
Argument 2: *
Argument 3 .. N: *
Rating: single operation - 1% , 2-3 operations - 1% ,> 3 operations - 1%.
Maliciousness: No.
Here you can clearly see that the registry key is jerking, but this is just Notepad ++ throwing its library. The rule argument removes the fall, while the basic rule remains unchanged and other attempts to change the key will work as expected.
And in 2011, we introduced another useful feature. As mentioned above, in SR, the rules worked autonomously from each other, and thus we could not study complex dependencies such as “uploading a file” - “saving a file to disk” - “writing to autorun”. After all, if you trace this dependence, you can give a rating much more than the sum of the ratings of individual events. Or less :) And then we decided to implement event correlation in SR2 for a more accurate detection of unknown malware.
We did this in two ways. First, they created bit masks that highlight groups of rules or individual rules by OR and AND. The basic description is a bit index for classifying behavior. Initially, this was invented for clustering malware by the peculiarities of their behavior, but a similar approach can be used to refine the rating score - use masks to implement a function of the type (RULE76 or RULE151) and (RULE270 or RULE540). The advantage of such masks is compactness and speed, the disadvantage is low flexibility.
Secondly, they made special scripts that conduct global analysis after calculating SR (patent US8607349) Scripts can be run alternately, either independently or by triggering a rule. Each of them has access to the database of accumulated statistics of previously worked out rules and rule groups. As a result, we have the opportunity (i) to use complex logic - conditions, calculations, loops, calling routines; (ii) make the most of neural networks; (iii) to form with the script not only a refinement to the SR rating, but also new knowledge that will be applied by subsequent scripts.
For example, the first script, based on an analysis of a dozen rules, concludes "the application is trying to get the passwords of other programs." The second script similarly concludes "the application is transmitting something to the Internet." The third script draws a conclusion like “if the application shows interest in passwords and transfers something to the Internet, THEN + 100% rating”.
In addition, scripts can be “attached” to any rule; in total, the rule becomes a kind of “trigger” for some algorithm.
Example script:
Var
S : string;
begin
if copy(ExtractFilePath(APIArg[1]), 2, 100)=':\' then begin
AddSR(20);
s := LowerCase(ExtractFileExt(APIArg[1]));
if S = '.exe' then AddSR(40);
if S = '.com' then AddSR(50);
if S = '.pif' then AddSR(60);
if S = '.zip' then AddSR(-20);
end;
end.
In this example, the script evaluates the file creation operation. We check the fact of creating the file in the root of the disk, and for this we immediately charge 20% SR. Further, depending on the file extension, we accrue an additional rating with the “+” or “-” sign.
The given example demonstrates the main plus of the scripts - the possibility of a complex differentiated assessment of function arguments with setting an individual SR rating according to the results of various checks. Moreover, some checks can increase the rating, some - lower, which allows you to make complex checks and complex analysis aimed at additional suppression of falsifications.
As a bonus, the author’s hand drawing of the technology described above. As is, almost on a napkin:
And now a little about the future.
The lineup is coming soonpersonal products of 2015. In general, we thought, weighed and decided to completely abandon the local SR and completely transfer the rating calculation to the cloud. This approach has many advantages at once. The quality of the analysis will not suffer, but the consumption of resources of the protected computer will decrease by an order of magnitude - all calculations will occur in our infrastructure. At the same time, the delay in delivering the verdict will be ... mneee ... but practically nothing will be: only a special software can notice these fractions of a millisecond.
Well, so briefly about our magic formula, only 10 thousand characters. And this is really only a “slightly ajar door”: in fact, acquaintance with a detailed description of the technology will take several days and a lot of refinement.
By the way, you can clarify right now, in the comments below.