KR20120073000A - System for analyzing of botnet detection information and method thereof - Google Patents

Abstract

PURPOSE: A botnet detecting information analysis system and method thereof are provided to execute botnet in-depth analysis by mutually analyzing detected individual information through an integrated analysis engine. CONSTITUTION: A BDS(Botnet Detection System) includes a BDE(Botnet Detection Engine), a BBAE(Botnet Behavior Analyzer Engine), a TAE(Total Analysis Engine), and an HBDE(HyBrid Detection Engine). The BDS determines a botnet group for group data transmitted from a traffic collecting system. The integrated analysis engine outputs the traffic collecting system and the various detecting information of a botnet detecting engine as one botnet detecting information.

Description

System and method for analyzing botnet detection information {SYSTEM FOR ANALYZING OF BOTNET DETECTION INFORMATION AND METHOD THEREOF}

The present invention relates to a system and method for analyzing botnet detection information, and to a method for mutual analysis of individual detection information for in-depth analysis of a botnet.

Bot stands for Robot, which means a personal computer (PC) infected with malicious intentional software. These botnets can be classified according to the protocol used by the botnet. That is, the communication protocol between the bot client constituting the botnet and the command and control (C & C) server may be classified as an IRC botnet in the case of the IRC protocol and an HTTP botnet in the case of the HTTP protocol. At this time, a number of bots are infected by a personal computer and are connected to a network to form a botnet. The botnet thus formed is remotely controlled by a bot master and is used for various malicious activities such as DDoS attacks, personal information collection, phishing, malware distribution, and spam mailing.

As such, attacks through botnets continue to increase, methods are increasingly diversified, and criminalization aims at monetary gains. Unlike the case of causing Internet service failure through DDoS, there are bots that cause personal system failure or illegally acquire personal information, and illegal user information such as ID / password and financial information. Increasingly, cybercrime abuse is becoming more common. In addition, while the existing hacking attacks show the hacker's own ability or compete with the community, the botnet shows the hacker group intensively exploiting and cooperating for the purpose of financial gain.

However, botnets are becoming more sophisticated to detect and circumvent using advanced technologies such as periodic updates, execution compression techniques, coder changes, and command channel encryption. In addition, the source of the botnet is open source, and thousands of variants occur, and the bot code can be easily generated or controlled through the user interface, so people without specialized knowledge or skills can make and use the botnet. This is serious.

Accordingly, the present invention has been made to solve the above-mentioned problems, and provides a system and method for analyzing botnet detection information, which enables in-depth analysis of botnets through mutual analysis between detected individual informations.

A botnet detection system for detecting botnets and analyzing behavior using information received from a traffic collection system according to the present invention, comprising: botnet detection for determining a botnet group with respect to group data transmitted from the traffic collection system An engine and an integrated analysis engine for outputting a variety of detection information of the traffic collection system and the botnet detection engine as a single botnet detection information provides a system for analyzing botnet detection information.

The integrated analysis engine integrates botnet detection information through cross-analysis of DNS analysis information and group-based detection information, and analyzes the detected multi-C & C botnet information, domain-based group information, and domain information to identify the domain used by the botnet. Integrating botnet detection information through cross-analysis of detected pattern detection information and group-based detection information based on traffic pattern of botnet, and integrating malicious behavior information by analyzing exploit behavior or P2P communication behavior It features.

In order to identify the domain of the botnet, C & C IP and domain matching are performed, but a zombie analyzes DNS request query for accessing the C & C server, and if the domain and IP are one-to-many, create a matching table of IP and domain and And analyzing the client similarity between the IP-based group information and the domain-based group information.

The botnet detection engine includes a module for determining a botnet group from the group data transmitted from the traffic collection system, a group matrix management module for managing a matrix for the group data, a module for selecting an analysis target in each group matrix, And a module for analyzing group similarity.

And a hybrid detection engine that detects the configuration and layer of the hybrid botnet by using the detected botnet detection information, P2P group information, and existing botnet group information.

The detection of the hybrid botnet is performed by mutually analyzing the configuration of the centralized group and the P2P group, and analyzing the similarity between the detected centralized group and the P2P group, but the peers existing as P2P peers and the detected botnet information Among them, the composition of the hybrid botnet is determined by analyzing the matching with the C & C IP.

Analyze the botnet group similarity for each peer in the P2P group to see if the peer is detected as a C & C in the botnet group or as a zombie in the botnet group, and thus if the peer is a C & C in a specific botnet group, If it is determined that the peer includes a zombie list of a specific botnet group, the botnet is determined as a proxy, and at this time, the C & C is determined as a master.

In addition, in the analysis method of botnet detection information for detecting botnets and analyzing behavior using information received from the traffic collection system according to the present invention, the botnet group is determined for the group data transmitted from the traffic collection system. And outputting various detection information of the traffic collection system and the botnet detection engine as one botnet detection information.

The determining of the botnet group may include analyzing similarity between the IP groups and determining whether the botnet is an existing botnet, and the similarity analysis between the IP groups is determined to be similar when the client set similarity analysis between the groups is 80% or more, The determination of the existing botnet is characterized as judging by the existing botnet when more than 50% of the total zombie set similarity analysis and more than 50% of the total C & C set similarity analysis.

Outputting a variety of detection information as a single botnet detection information, judging the novelty of the botnet of the detected information, assigning an ID to a new botnet, or extending or migrating an existing botnet, and URL fastflux for each botnet ) Integrating information, integrating malicious traffic pattern information for each C & C, and analyzing zombie activity and inactivity.

The method may further include detecting a hybrid botnet, and analyzing the botnet group similarity for each peer of the P2P group that detected the hybrid botnet to analyze whether the peer is detected as a C & C of the botnet group or as a zombie of the botnet group. Determining that the botnet is a worker layer if the peer is a C & C of a specific botnet group, and if the peer includes a zombie list of a particular botnet group, determining that botnet as a proxy and then determining the C & C as a master Characterized in that.

As described above, the present invention may provide a system and method for analyzing botnet detection information, which enables in-depth analysis of a botnet through mutual analysis between detected individual informations.

1 is a network diagram according to an embodiment of the present invention.
2 is a module configuration diagram of a TCS according to an embodiment.
3 is a module configuration diagram of a BDS according to an embodiment.
4 is a detailed block diagram of a traffic collection engine of the TCS according to an embodiment.
5 is an operational flowchart of a traffic collection engine.
6 is a detailed block diagram of a group analysis engine of a TCS according to an embodiment.
7 is an operational flowchart of a group analysis engine.
8 and 9 are detailed configuration diagrams of a DNS resolution engine of a TCS according to an embodiment.
10 is an operational flowchart of the DNS resolution engine.
11 is a detailed block diagram of a lightweight detection engine of the TCS according to an embodiment.
12 is a detailed configuration diagram of an information management engine of the TCS according to an embodiment.
13 is a block diagram of a botnet detection engine according to an embodiment.
14 is a block diagram of an integrated analysis engine according to an embodiment.
15 is a diagram for explaining P2P pattern based detection.
16 is a diagram for explaining group behavior based detection.
17 illustrates a hybrid botnet detection method according to an embodiment.
18 is a block diagram of a hybrid detection engine according to an embodiment.
19 is a flow chart of a hybrid detection engine.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. It will be apparent to those skilled in the art that the present invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, It is provided to let you know. Like numbers refer to like elements in the figures.

1 is a diagram illustrating a network configuration according to an embodiment of the present invention. 2 is a module configuration diagram of a TCS according to an embodiment. 3 is a module configuration diagram of a BDS according to an embodiment.

1 to 3, the network configuration according to the present embodiment is a traffic collector sensor system (hereinafter referred to as TCS), botnet detection system (hereinafter referred to as BDS) and control system It is composed of a network that cooperates.

The TCS of this embodiment collects traffic information. BDS detects botnets by traffic information collected from TCS. The botnet control system also manages configuration and status information for the TCS and BDS.

Here, the TCS collects traffic of the corresponding internet service provider network for botnet detection. At this time, the number of TCS may be present in the corresponding Internet service provider network (m) 만큼 number of the number of TCS (n) provided in the corresponding BDS. In addition, the TCS collects Domain Name System (DNS) traffic and traffic information according to a collection policy set by the botnet control and security management system. At this time, the collected traffic information is periodically transmitted to the BDS.

BDS detects botnets based on specific traffic collected from the TCS. There may be m such BDSs in the Internet service provider network. It also detects botnets and analyzes malicious behaviors using collected traffic information. The detected botnet information is sent to the botnet control and security management system.

As shown in FIG. 2, the TCS of the present embodiment is largely classified into a traffic collector engine (TCE), a group analysis engine (GAE), a light botnet detection system (LBDS), and DNS analysis. It is composed of an engine (DAE; DNS Analysis Engine), a sensor collection information management engine (IME), a communication engine (COMM), and a system management engine (SME).

First, the traffic collection engine (TCE) receives the traffic after mirroring the monitoring network. That is, it manages traffic filtering, traffic packet pool management, traffic dump and collection status. IP traffic information is provided to the group analysis engine (GAE), DNS traffic information is provided to the DNS analysis engine (DAE), and low packet information is provided to the lightweight detection engine (LBDS).

The group analysis engine (GAE) processes the collected traffic into group data for each destination. At this time, IP substrate group extraction and P2P group extraction are performed. Then, group data for each destination is provided to an information management engine (IME).

Lightweight botnet detection systems or Lightweight Detection Engines (LBDS) detect pattern-based detection and anomalous DNS for collection traffic. That is, pattern substrate detection, traffic detection pattern generation, pattern application and management are performed. The pattern board detection information and DNS fastflux detection information are provided to the information management engine (IME).

The DNS Analysis Engine (DAE) performs abnormal DNS traffic analysis, URL-based group analysis, and fastflux detection. That is, DNS board group extraction, DNS fast flux detection, and DNS traffic analysis. The abnormal DNS detection information and the fast flux detection information are provided to the information management engine (IME).

The information management engine (IME, ie, sensor collection information management engine) processes group data, pattern detection information, and DNS fastflux detection information to be transmitted to the detection system. That is, the detection information is managed and the detection information and the group information are stored.

The system management engine (SME) manages a policy used for each engine, and generates a status log of the system. That is, it manages policy management, policy database operation, system management and status database.

The communication engine COMM communicates with an external system such as transmitting the processed information from the sensor system to the detection system. That is, the detection information of the information management engine (IME) is transmitted, and the state information of the system management engine (SME) is transmitted to the outside.

Next, the communication interface of the BDS transmits and receives various settings and status information with the control system. BDS receives group behavior information and lightweight detection information about botnet from TCS, detects botnet, conducts behavior analysis and saves in DB. It analyzes the botnet's expansion / migration in the comprehensive analysis module, analyzes the activity / inactivity of zombies, and generates the final botnet report by analyzing the botnet risk. This report is sent to the control system as the final detection information of the botnet. At the same time, for detection of hybrid botnets, the Hybrid Bonte Detection Engine (HBDE) generates botnet reports by detecting hybrid botnets in P2P groups and existing botnet groups through cross-analysis with lightweight detection information. Analysis of hybrid botnets can be performed through individual control of the administrator.

Such a BDS (ie, botnet detection system) includes a botnet detection engine (BDE), a botnet behavior analysis engine (BBAE), and an integrated analysis engine (TAE) as shown in FIG. ), And a hybrid detection engine (HBDE). It also includes the aforementioned information management engine (IME) and system management engine (SME).

First, the botnet detection engine (BDE) detects multiple C & C botnet configurations through similarity analysis between groups based on information grouped in the TCS (ie, sensor system). That is, group similarity analysis, multiple C & C similarity analysis, and botnet group detection. At this time, the multi-C & C botnet group information is provided to the botnet behavior analysis engine.

The botnet behavior analysis engine (BBAE) analyzes the botnet's behavior and the role of each server based on the traffic information of the detected botnet. That is, attack behavior analysis, C & C role analysis, and behavior event trigger analysis. It provides multi-C & C botnet behavior information to the integrated analysis engine (TAE).

The Integrated Analysis Engine (TAE) detects the botnet's domains by analyzing the botnet's active / deactivated zombies and the botnet's risk, and by analyzing multi-C & C botnet information and DNS-based group information. In other words, cross-detection analysis, botnet expansion and migration analysis, zombie activity and inactivity analysis, and botnet risk analysis. The botnet analysis information is then provided to an information management engine (IME).

The hybrid detection engine (HBDE) detects the configuration and layer of the hybrid botnet based on the detected botnet information and P2P group information. In other words, P2P network based detection, centralized based detection, detection information cross analysis and hybrid layer role analysis. BDS's Information Management Engine (IME) manages identity management, botnet report management, and a management database.

Hereinafter, with reference to the drawings will be described in detail the features and operation of the above-described detailed module of the TCS and BDS.

4 is a detailed configuration diagram of a traffic collection engine of the TCS according to an embodiment, and FIG. 5 is a flowchart illustrating an operation of the traffic collection engine.

4 and 5, a traffic collection engine (hereinafter referred to as TCE) manages a traffic packet pool, manages a collection state, and performs traffic filtering and traffic dump. The traffic collection engine (TCE) uses a packet capture tool to collect the traffic data of the network according to the collection policy. The traffic collection state is managed by a system management engine (SME). The traffic collection target by the traffic collection engine may be IPv4 based traffic according to general DNS traffic, traffic collection target IP set in the policy, and other IPs specified in the collection policy. The traffic here is filtered for group analysis and DNS analysis, but provides all low packets to the lightweight detection engine (LBDS) for pattern-based detection. And, according to the collection policy, traffic information corresponding to time and capacity can be dumped in the form of pcap for the IP designated by the administrator.

First, traffic collection filters and sends the traffic required for each detection engine in the TCS. The main engines receiving traffic are traffic dump engines, lightweight detection engines, abnormal DNS detection engines, and group behavior detection engines.

First, because it is not efficient to send all input traffic to each detection engine, it filters and transmits the traffic required by each detection engine.

The exception to this is that the traffic dump engine must send unfiltered traffic to the engine by the administrator to collect traffic for a particular target. The whitelist and blacklist are then filtered to send the appropriate traffic for each detection engine.

In other words, first, the traffic to be dumped is filtered. In the case of dump target traffic, preprocessing of the traffic dump engine is performed. If it is not a white list, it is determined whether it is a black list. If it is not blacklist, it determines whether to collect all IP targets, and if necessary, preprocess the group behavior detection engine. In the case of a black list, traffic is classified to perform preprocessing of the lightweight detection engine in the case of low traffic, preprocessing of the abnormal DNS detection engine in the case of DNS traffic, and preprocessing of the group behavior detection engine in the case of grouping traffic.

6 is a detailed block diagram of a group analysis engine of a TCS according to an embodiment, and FIG. 7 is a flowchart illustrating an operation of a group analysis engine.

6 and 7, the GAE performs traffic packet pool management, traffic filtering, grouping IP filtering, IP classification of traffic, and single server group data generation. That is, the group analysis engine (GAE) extracts group information based on the communication behavior from the collected traffic to a specific IP. At this time, the grouping target may be limited to the IP specified in the grouping policy, or may be targeted to the entire traffic. The group configuration generates information by collecting a group when there are n or more clients in the group configured in a unit time. Grouping information is made over a specific time interval.

In the Group Analysis Engine (GAE), group information can be collected from the entire traffic, or it can be targeted to a specific designated IP. When collecting the whole object, group information is generated only for traffic excluding the white list. When collecting for a specific designated IP, group information is collected and grouped for the IP set in the policy except the white list. Group minimum conditions are collected with a group minimum condition per unit time as specified in the group collection policy.

That is, the group behavior detection engine preprocessing is first performed on the grouped traffic. At this time, it is determined whether the corresponding list is a black list. According to the result of determination, the botnet group is stored in the group engine storage after classifying the data for each section of the tree, or the botnet group is stored in the group engine storage according to the group minimum condition.

8 and 9 are detailed configuration diagrams of a DNS analysis engine of the TCS according to an embodiment, and FIG. 10 is a flowchart illustrating an operation of the DNS analysis engine.

8 to 10, the DNS analysis engine (DAE) analyzes DNS request traffic in network traffic to detect abnormal traffic behavior and extracts DNS-based detection information that can be used to detect botnets. to be. In this engine, we take over DNS-related traffic from the traffic collection engine, extract suspicious domains except whitelists, collect group information for specific domains, and fastflux the extracted suspicious domains. (fastflux) detection.

  In addition, by taking over a specific zombie group list from the administrator, the zombie list can be extracted from the domain (Domain) that the common DNS query request to show the suspected domain to the administrator. Detection information generated by the DNS Analysis Engine (DAE) can be delivered to the detection system and used as input information for comprehensive analysis.

The DNS analysis engine (DAE) receives DNS traffic information from the traffic collection engine (TCE) and analyzes the status of DNS traffic. DNS traffic is used to extract suspicious URL lists, DNS-based group extraction, and DNS fast flux detection. This is then provided to an information management engine (IME).

The DNS Analysis Engine (DAE) is an engine that processes information about DNS loops in the collection traffic. It consists of a DNS group extraction module and a fastflux detection module. It analyzes DNS traffic, extracts URLs requested from the network (excluding well-known domains), lists them as suspicious URLs, and stores them. Clients that query a suspicious url are grouped by url. In addition, the suspect URL (url) analyzes whether or not fastflux (fastflux) in the fastflux detection module.

Here, the fastflux detection module extracts the suspicious UEL list as shown in FIG. 9, analyzes the result of the first query using a Dig, that is, a DNS parsing tool, and schedules the schedule again. After the TTL, Digg analyzes the results of the second query. At this time, if the class B or more or the IP is changed, it is determined as a fast flux UEL. That is, the fast flux detection module detects the fast flux in an active monitoring manner for the URLs in the suspected URL list. It operates the detection engine as much as system resources allow with the list of domains to be detected and performs the initial DNS lookup query directly on the input domain to analyze the IP information of section A. do. At this time, if there are three or less IPs for the response information, it is unlikely that it is a fastflux, and thus the detection process is terminated for the corresponding domain.

When there are a plurality of response IPs as a result of the response, after a time to live (ttl) of response information, a DNS lookup query is requested for the domain again, and the IP of section A and the previous IP are requested. Analyze the change in and. At this time, if the TTI is long, the detection time is long, and it is unlikely that it is a fastflux. Therefore, if the TTL exceeds 300, the detection process is terminated for the corresponding domain. However, when the TTL is 300 or less, if the IP of class B or more is changed by 50% or more according to the additional query result, it is determined as fastflux.

The DNS analysis engine (DAE) operates by receiving traffic related to DNS from the traffic import engine (TCE).

DNS traffic analysis is performed through DNS detection engine preprocessing and stored in DNS detection engine storage. In this case, the traffic status information includes Top N request domains, Top N query Src.ip, total number of request domains (deduplication), and total number of domain requests (duplicate removal). In addition, DNS traffic is analyzed to determine whether it is a white list, and the list of domains is stored in the fastflux detection domain waiting queue. At this time, in the case of a white list, it is dropped. In the case of a non-white list, the domain substrate group is extracted and then it is determined as a black list. If it is a blacklist, it is stored in the DNS detection engine store as a known botnet group. It also determines if it is suspect DNS traffic if it is not blacklisted. Drop suspicious DNS traffic and store suspicious botnet groups in the DNS detection engine repository. Next, the first Dig query is made on the list of domains in the Fastflux detection domain wait queue. In this case, if it is suspected that it is a fast flux (Fastflux) is not dropped, in the case of a fast flux (Fastflux) it performs a second Digg query. At this time, when the first TIG query result TTL is 500 or less and three or more IP, the second Dig query is performed. Secondary Dig queries are performed after the TTL. After the second Dig query, it drops if it is not suspected of being Fastflux, and if it is Fastflux, it stores it in the DNS detection engine repository. At this time, the changed IP is performed in the case of B class unit of 50% or more.

That is, as described above, the DNS analysis engine DAE operates by receiving traffic related to DNS from the traffic collection engine TCE as an input. Basically, traffic status information is managed as statistical information as below. It manages Top N of request domains, client IP Top N with many DNS query requests, the total number of requested domains deduplicated and the total number of domain queries requested deduplicated.

In addition, the DNS analysis engine (DAE) statistics the status of DNS traffic and extracts group information for each domain. At this time, according to the domain management policy, the group is not extracted in the case of the white list, but the domain-based group is extracted in the case of the suspect domain (Domain) that is not the white list.

When extracting a domain-based group, first check whether it is a blacklist, and if it is a blacklist, extract the group information regardless of the group creation conditions, and if not, schedule it according to the minimum group policy. Configure groups only for the domains requested by the client. At the same time as the grouping, fastflux proceeds independently, so it can proceed in parallel as long as system resources allow.

11 is a detailed block diagram of a lightweight detection engine of the TCS according to an embodiment.

Referring to FIG. 11, the lightweight detection engine LBDE generates a traffic detection pattern from the traffic dump information of the traffic collection engine TCE, applies and manages the pattern through its applicable detection rule, Pattern based detection is performed by applying detection rules.

The main function of the LLBDE is to detect a communication object of a corresponding communication packet by inputting a known botnet communication pattern. Pattern matching detects botnet C & C IPs and zombie IPs with known botnet communication patterns. The pattern may generate a rule file based on traffic dump information of a specific IP transmitted from the collection function, or may be input through a separate UI. The lightweight detection engine (LBDE) generates a rule file based on specific traffic dump information (pacp). The state DB of the system management engine (SME) is accessed by the traffic collection module (TC), the traffic information management module (TIM), and the management communication module (COMM) to record a log of work.

The main modules of the LLBDE include a pattern detection module, a pattern generation module, a pattern application module, and a rule management module.

The pattern detection module detects botnet C & Cs and zombies based on rule information describing botnet traffic signatures as unfiltered network traffic inputs.

The pattern generation module may input network traffic information, such as pcap, to generate a signature for a specific traffic pattern by an administrator, create a rule file, and apply it to a lightweight detection engine (LBDE).

The rule management module provides management of rule files that are currently applied. The rule management module adds, changes, deletes, and applies rule files. The rule management module is configured based on the administrator's input through the UI. The rule file can receive input from outside and can be input directly by the administrator. Or it could be a series of files containing rules. In addition, rule files can be provided from an external system such as a host-based malicious bot analysis system for botnet detection.

The rule application method of the pattern detection module (engine) is as follows.

In the pattern detection module, dynamic input may be difficult because rule input requires specific preprocessing. Due to the pattern detection module and the system characteristics, the detection module may be updated without stopping and may not be possible. When the dynamic application is possible, the input rule may be updated and applied. If it is not applied dynamically, it can be applied as follows.

  First, several pattern detection engines run on the system. Each detection engine receives input traffic according to its assigned area and performs pattern detection. The input traffic is divided and distributed by the number of pattern detection modules currently operating by the preprocessing function of the pattern detection engine. At this time, each pattern detection module has its own IP.

If an update situation occurs and the pattern detection module needs to be temporarily interrupted, it needs to be divided and restarted to prevent the detection by the interruption of the pattern detection module. Depending on the network bandwidth and system performance, the single pattern detection module can handle the maximum, and some interruption is updated, and the traffic being handled by the updating pattern detection module is transmitted to the module that has not yet been updated. Therefore, the incoming traffic is processed by the remaining part of the pattern detection module without any processing being omitted, and the remaining pattern detection module is updated.

  Once the update is complete, run the updated module again, redirect all traffic the rest of the modules were to to the updated module, and then pause and update the unupdated module. After the update is completed, the rule information of all modules has been updated, so traffic should be classified and processed by IP as before.

12 is a detailed configuration diagram of an information management engine of the TCS according to an embodiment.

Referring to FIG. 12, the information management engine (IME) stores group information from the botnet partial group information of the group analysis engine (GAE), and stores UALs, ie, fast flux information and UEL group information of the DNS analysis engine (DAE). DNS analysis information is stored, and lightweight detection information is stored using pattern detection rule information of the LDS. Then, the transmission information is generated based on the information, and the information is transmitted through the communication management module.

The information management engine (IME) may include a configuration management module, a state database, a management command channel role database, and a peer database.

An information management engine (IME), that is, a policy management module, is a module having overall configuration management and control functions of a sensor system and interacts with all modules. The configuration management module of the policy management module manages the state DB, and the management command channel updates and manages the rule DB and the peer DB. At this time, the information of the rule DB and the peer DB is received and applied by the management communication module COMM. In addition, the state DB accesses the traffic collection module TC, the traffic information management module TIM, and the management communication module COMM, and records a log of the work.

Next, the features and operations of the detailed modules of the BDS will be described.

In recent years, botnets do not have one server to control the botnet, but several have increased their survivability. Of course, not only do we increase the number of servers, but we also use several defenses. Most of the recent botnets operate for a long time for financial gain rather than one-offs, so many C & Cs are operated for survival and flexible command control system.

Botnet detection performs botnet group behavior based detection. Botnets are characterized by multiple zombie systems receiving commands from attackers and executing commands. This feature can be seen as a feature in network behavior. For example, many zombie systems query a particular url or connect to a specific server. While this is a normal network behavior, it's no wonder that accessing unknown IPs or URLs is suspicious. This suspicious group behavior is detected in the network to create a group for the behavior, and the similar groups are identified based on the client among the created groups. This may be evidence that certain groups will be connected to several servers, similar to botnets. Uncommon groups may appear, and multiple group information can be analyzed to detect the overall configuration of the botnet.

In addition, there is a lot of traffic similar to botnet group behavior in large network that is difficult to predict. In other words, there are messenger services, financial services, web page access and subsequent redirects, and multiple servers all the time.

Therefore, it is difficult to find group behavior that can be judged by botnets, and there is a high probability of false positives. Therefore, a method for minimizing this is necessary. For this purpose, it is effective to whitelist well-known URLs, and to whitelist the authentication server and the connection behavior where the redirect occurs.

13 is a block diagram of a botnet detection engine according to an embodiment.

As shown in FIG. 13, the botnet detection engine BDE determines the botnet group for the group data transmitted from the sensor system, i.e., the TCS. To do this, we analyze the similarity between IP groups using group information with a limited number of group elements. At this time, 80% or more of the client group similarity analysis between groups is based on. Then, it is determined whether the existing botnet through the multi-C & C botnet group. For this, the existing botnet detection information is used, and based on 50% or more of the total zombie set similarity analysis and 50% or more of the whole C & C set similarity analysis. At this time, in case of new botnet, ID is assigned and registered. In addition, existing botnets are updated, extended / migrated, and active / inactive.

The botnet detection engine (BDE) includes a module for determining a botnet group, a module for managing a group matrix, a module for selecting an analysis target, a module for analyzing group similarity, and a configuration event trigger module. The following describes these.

A module for determining a botnet group for group data sent from a sensor system, wherein the transmitted group data creates / updates a matrix for the group. The update and deletion of the group matrix are performed according to the group management algorithm. If there is no update for the entire 50% or more clients in the group, the deletion is performed according to the stepwise management.

The Botnet Detection Engine (BDE) manages a matrix of group data. That is, the matrix is updated and a new group is created for the existing group. At this time, the update deletes the group matrix when there is no activity of the client for a predetermined time according to the group matrix management algorithm. In addition, after the group matrix is updated, when the specific connection pattern exceeds the number of times of the threshold or more for each group matrix, the corresponding group is determined as the analysis target group. Then, the client similarity between each group group is analyzed for the group group to be analyzed, and when the similarity is 80% or more, the similarity analysis is performed on the detailed client list for the specific connection pattern that is represented. In addition, if the client similarity for a particular connection pattern is 80% or more, the two groups are determined to be the same botnet. Of course, the analysis results of each module are aggregated and transmitted to the log manager, and the analysis results are generated and sent to the event trigger by generating a trigger message to be used in a later policy.

14 is a block diagram of an integrated analysis engine according to an exemplary embodiment.

As shown in FIG. 14, the integrated analysis engine (TAE) generates one botnet detection information by integrating the detection information of the sensor and the detection system.

To do this, we use sensor collection information and information management engine (IME) botnet detection information to analyze cross-detection analysis and risk analysis, and analyze URL-based group and IP-based group similarity. At this time, the new botnet is given a new botnet ID according to the existing detection botnet or the new botnet, and the extension and migration analysis is performed for the existing botnet. Integrate URL fastflux information by botnet through fastflux information about URLs. Integrate malicious traffic pattern information by C & C through C & C detection pattern information. Analyze active and / or inactive zombie with active zombie analysis compared to traditional detection botnets. This generates final botnet information and detects the botnet through it.

As mentioned earlier, the integrated analysis engine (TAE) combines various detection information from sensors and detection systems to form a single botnet detection information. As a variety of detection information, the overall botnet information is composed by considering the overall DNS and pattern detection information together with the overall information on the behavior and configuration of the botnet.

In this case, it integrates botnet detection information through cross analysis of DNS analysis information and group-based detection information. DNS analysis information includes domain-based group information and fastflux detection information for a suspect domain.

By analyzing the multi-C & C botnet information detected through the group analysis engine, domain-based group information and domain information together, the domain used by the botnet can be known. The analysis can be done in several ways. Ultimately, in order to know the domain of the botnet, we need to find a match between the C & C IP and the domain. Depending on the type of domain, the following method can be used.

That is, in a general case, a zombie analyzes a DNS request query for accessing a corresponding C & C server. Zombie detects the domain of C & C by looking at the domain query that connects to C & C. In addition, when the domain and the IP are one-to-many, a matching table of the IP and the domain is created for a sufficient time and the mutual analysis is performed. In this case, when the IP and the domain are 1: N or N: 1, the IP: Domain table accumulated for a sufficient time is analyzed to detect the 1: N or N: 1 matching configuration of the IP and the domain.

The client similarity between the IP-based group information and the domain-based group information is analyzed. In the case of botnets using fastflux, groups are not created by IP-based group information and simple IP: Domain table. Therefore, botnets are analyzed by analyzing similarity between domain-based group information and IP-based botnet groups. Detect the used fastflux domain.

The integrated analysis engine (TAE) integrates botnet detection information through cross-analysis of pattern detection information and group-based detection information. That is, the pattern-based detection information is detected based on the traffic pattern of the botnet, and additionally detects malicious behavior information of the botnet. Basically, botnets use spam or removable storage media to spread themselves, but they exchange information with each other through P2P communication, and attack vulnerable computers to make zombies themselves through vulnerability attacks. Thus, by analyzing these exploit behaviors or P2P communication behaviors on a pattern-based basis, it is possible to integrate information about malicious behaviors of botnet zombies.

That is, it determines whether a domain and fastflux used for botnet access. It can detect the presence of malicious behavior for the spread of botnet zombies according to exploits detected in the pattern detection engine.

FIG. 15 is a diagram for describing P2P pattern based detection, and FIG. 16 is a diagram for explaining group behavior based detection.

In the case of the P2P pattern-based detection group and the group-based detection engine, pattern-based detection is performed for known seeds. That is, it discovers a peer. The P2P groups are grouped based on the seed. Of course, at this time, there is no directionality. In the case of botnet group detection based on group behavior, group detection is performed for known blacklists. Botnet group detection by group detection is enabled, and general unit group detection is possible.

17 is a diagram illustrating a hybrid botnet detection method according to an embodiment.

Hybrid botnet detection is performed in a hybrid botnet analysis engine, that is, a hybrid botnet detection engine. At this time, the botnet group similarity for each peer of the centralized P2P group is analyzed first. In other words, it is analyzed whether peers are detected as C & C of botnet group or peers as zombies of botnet group. Subsequently, integration according to the similarity analysis is performed. That is, when the peer is analyzed as a C & C of a specific botnet group, the peer determines that the botnet is a work layer. In addition, if the peer includes a zombie list of a specific botnet group as a part, the botnet is determined as a proxy, and the C & C is determined as a master. The detected information can be expressed in various ways. At this time, a proxy layer (P2P layer) is added from the existing botnet information. In this case, it is assumed that all proxy lists are connected to each other by P2P. And, there can be several masters. Also, not all proxies have a zombie list. In other words, a proxy may have a list of zombies, but may just act as a peer.

18 is a block diagram of a hybrid detection engine according to an embodiment, and FIG. 19 is a flowchart of the hybrid detection engine.

As shown in FIG. 18, the hybrid detection engine analyzes detection information using centralized P2P based detection information and analyzes the role of the hybrid layer. The hybrid layer includes a P2P group, that is, an intermediate proxy group, a group having a P2P peer as a server, that is, a server having a lower worker group and a P2P peer as a client, that is, a higher master group.

Hybrid botnets consist of an upper master, an intermediate P2P, and a lower zombie. The upper master may be variable and undetectable in the communication, and the intermediate P2P group may act as a server to receive centralized actions by lower zombies as a proxy group. Hybrid botnet detection is accomplished by cross-analyzing the composition of centralized and peer-to-peer groups. The centralized group uses information organized by the group analysis engine, and the P2P group gradually performs P2P communication based on the list of peers detected by the pattern-based engine or known P2P peers. Detect spreading P2P configuration by detecting spreading Peer Discovery traffic patterns. The similarity analysis is performed between the centralized group and the P2P group, and it is analyzed whether the peers existing as P2P peers and the botnet information are matched with the C & C IP. If more than a certain percentage of the detected peer-to-peer peers are part of the C & C of the detected botnets and the zombies of the detected botnets, this can be determined as the configuration of the hybrid botnet.

That is, the P2P layer is basically a proxy layer. The set that connects members of the P2P layer as a server becomes a worker layer. The set of servers that members of the P2P layer connect as clients is the master layer.

The detection of hybrid botnet is performed when the same P2P pattern among zombies of centralized botnet is detected between peers of each other, when the node detected as C & C server has P2P communication or is a member of P2P group. It can be determined.

That is, centralized group loading of existing botnet detection information and P2P group loading collected from sensors are performed. First, we analyze how many centralized servers (C & Cs) are members of the P2P group. At this time, regardless of the type of botnet, all botnets are covered by C & C. It analyzes whether the centralized client (zombie) is a member of the P2P group, and in this case, the zombie of the entire botnet.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments. Therefore, it will be apparent to those skilled in the art that the present invention may be variously modified and modified without departing from the spirit of the appended claims.

Claims (11)

In the analysis system of botnet detection information for detecting botnets and analyzing behavior using information received from the traffic collection system,
A botnet detection engine that determines a botnet group for the group data transmitted from the traffic collection system, and an integrated analysis engine that outputs various detection information of the traffic collection system and the botnet detection engine as one botnet detection information. A system for analyzing botnet detection information. The method according to claim 1,
The integrated analysis engine,
Integrate botnet detection information through cross-analysis of DNS analysis information and group-based detection information, and analyze the detected multi-C & C botnet information, domain-based group information, and domain information to identify domains used by botnets,
Integrates botnet detection information through cross-analysis of pattern detection information and group-based detection information based on botnet traffic patterns, and integrates malicious behavior information by analyzing exploit behavior or P2P communication behavior. Botnet detection information analysis system. The method according to claim 2,
In order to identify the domain of the botnet, C & C IP and domain matching are performed, but the zombie analyzes DNS request query for accessing the C & C server, and if the domain and IP are one-to-many, create a matching table of IP and domain and And analyzing the client similarity between the IP-based group information and the domain-based group information. The method according to claim 1,
The botnet detection engine includes a module for determining a botnet group from the group data transmitted from the traffic collection system, a group matrix management module for managing a matrix for the group data, a module for selecting an analysis target in each group matrix, A system for analyzing botnet detection information comprising a module for analyzing group similarity. The method according to claim 1, 2 or 4,
And a hybrid detection engine configured to detect a configuration and a layer of the hybrid botnet using the detected botnet detection information, P2P group information, and existing botnet group information. The method according to claim 5,
The detection of the hybrid botnet is carried out by mutually analyzing the configuration of the centralized group and the P2P group,
Analyze the similarity between the detected centralized group and the P2P group, and determine the composition of the hybrid botnet by analyzing the match between the peers existing as P2P peers and the C & C IP among the detected botnet information. Analysis system of detection information. The method according to claim 5,
Analyze the botnet group similarity for each peer in the P2P group to see if the peer is detected as a C & C in the botnet group or as a zombie in the botnet group, and thus if the peer is a C & C in a specific botnet group, And determining that the botnet is a proxy when the peer includes a zombie list of a specific botnet group, and then determining the C & C as the master. In the method of analyzing the botnet detection information that detects the botnet and analyzes the behavior using the information received from the traffic collection system,
Determining a botnet group for the group data transmitted from the traffic collection system; And
And outputting various detection information of the traffic collection system and the botnet detection engine as one botnet detection information. The method of claim 8, wherein determining the botnet group comprises:
Analyzing the similarity between the IP groups; And
Determining whether it is an existing botnet,
The similarity analysis between the IP groups is judged to be similar when the client set similarity analysis between groups is 80% or more, and the existing botnet is judged when it is 50% or more of the whole zombie set similarity analysis and when it is 50% or more of the whole C & C set similarity analysis. A method for analyzing botnet detection information, characterized in that it is determined as a botnet. The method of claim 8, wherein the outputting of the various detection information as one botnet detection information comprises:
Determining an identity of the botnet of the detected information and assigning an ID to the new botnet, or extending or migrating an existing botnet;
Integrating botnet-specific URL fastflux information;
Integrating malicious traffic pattern information for each C &C; And
And analyzing zombies active and inactive. The method according to claim 8,
Detecting the hybrid botnet further;
Analyzing the botnet group similarity for each peer of the P2P group detecting the hybrid botnet to analyze whether the peer is detected as a C & C of the botnet group or as a zombie of the botnet group, and the peer is a C & C of a specific botnet group. Determining the botnet as a worker layer, and when the peer includes a zombie list of a specific botnet group, determining the botnet as a proxy and determining a C & C as a master at this time. .

Images