An iot device c2 communication detection method based on supply chain network trust link modeling

Abstract

This invention discloses a method for detecting C2 communication between IoT devices based on supply chain network trust link modeling. The method includes: capturing IoT device network traffic, extracting supply chain communication paths, and identifying supply chain network links; constructing a supply chain network link graph with trust weights and calculating edge trust weights; defining a trust transfer model, obtaining the trust value of each supply chain link based on the model, and establishing a supply chain trust baseline; detecting unknown communication, calculating the multi-dimensional deviation of unknown communication based on the supply chain trust baseline; and calculating the posterior probability that the unknown communication is C2 communication using a Bayesian network based on the multi-dimensional deviation, and determining it as C2 communication if the deviation exceeds a threshold. This invention, through supply chain trust link modeling and multi-dimensional deviation analysis combined with Bayesian network inference, accurately identifies communication between IoT devices and malicious C2 servers, reduces false positives and false negatives, does not rely on simulation environments, has strong interpretability, and is suitable for IoT device supply chain security assessment.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, and in particular relates to a method for detecting C2 communication of IoT devices based on supply chain network trust link modeling. Background Technology

[0002] With the rapid development of IoT technology, IoT devices are now widely used in critical infrastructure fields such as smart homes, industrial control, intelligent transportation, and healthcare. However, the supply chain security of IoT device firmware is becoming increasingly prominent. Attackers are using methods such as implanting backdoors, tampering with upgrade packages, and hijacking configuration downloads to enable the firmware to communicate with malicious C2 servers, thereby remotely controlling devices, stealing sensitive data, and launching large-scale attacks.

[0003] Existing methods for C2 communication detection of IoT devices mainly fall into the following categories: The first category is C2 communication detection methods based on static feature matching. This method identifies C2 communication by pre-defining static features of C2 communication, such as fixed heartbeat intervals, unknown IP addresses, non-standard communication ports, and abnormal packet sizes, through feature matching of network traffic. However, this method has significant limitations: attackers can easily forge normal heartbeat intervals (e.g., randomized heartbeat times), use known IP addresses (e.g., using domain fronting techniques to hide the real C2 server), use standard ports (e.g., HTTPS port 443), and obfuscate traffic with legitimate TLS certificates. This results in high false positive and false negative rates, making it difficult to cope with increasingly complex attack methods.

[0004] The second category is C2 communication detection methods based on machine learning. This method collects samples of normal network traffic and C2 communication traffic, trains machine learning models such as random forests, support vector machines, and neural networks, and automatically identifies C2 communication. However, this method relies on a large amount of labeled data, and in practical applications, C2 communication samples are scarce, making model training difficult. Furthermore, the interpretability of the machine learning models is poor, making it difficult to explain to users why a particular communication was identified as C2 communication.

[0005] The third category: Sandbox-based dynamic C2 communication detection methods. This method runs suspicious programs or firmware in an isolated sandbox environment, monitors their network behavior, and identifies abnormal communications. However, this method assumes that the firmware can run successfully in the sandbox environment. In reality, many firmware programs cannot start normally in a sandbox environment due to their reliance on specific hardware such as Hi3521D, IMX6ULL chips, encryption chips such as HSM, closed-source drivers, signature verification, etc., thus limiting the applicability of this method.

[0006] The fourth category: C2 communication detection methods based on network traffic analysis. This method identifies abnormal communication by analyzing statistical characteristics of network traffic, such as traffic patterns, communication duration, and packet size distribution. However, this method does not consider the supply chain characteristics of IoT devices. The firmware of IoT devices typically establishes normal supply chain communications with OEM servers, cloud platforms, and third-party APIs. These normal communications may be misidentified as C2 communications. At the same time, attackers can forge traffic characteristics similar to normal supply chain communications to bypass detection.

[0007] In summary, the existing technology has the following core problems: First, static feature matching methods are easily bypassed by attackers, resulting in high false positive and false negative rates. Second: Machine learning-based methods rely on large amounts of labeled data, resulting in poor model interpretability. Third: The sandbox-based approach assumes that the firmware can be successfully simulated, but in reality, a large number of firmware programs cannot run in a sandbox environment. Fourth: Network traffic analysis-based methods do not consider the supply chain characteristics of IoT devices, making it difficult to distinguish between normal supply chain communication and malicious C2 communication. Therefore, there is a need for an IoT device C2 communication detection method that can overcome the above-mentioned defects and is based on supply chain network trust link modeling. Summary of the Invention

[0008] To address the aforementioned technical problems, this invention proposes an IoT device C2 communication detection method based on supply chain network trust link modeling, thereby resolving the issues present in the prior art.

[0009] To achieve the above objectives, this invention provides a method for detecting C2 communication of IoT devices based on supply chain network trust link modeling, comprising: Capture network traffic from IoT devices; Based on the network traffic, extract the normal supply chain communication path of IoT devices and identify supply chain network links; Based on the supply chain network links, construct a supply chain network link graph with trust weights, and calculate the trust weight for each edge; Based on the supply chain network link diagram and the trust weight, a trust transfer model is defined; based on the trust transfer model, the trust value of each supply chain link is obtained, and a supply chain trust baseline is established based on the trust value; Detect unknown communications of the IoT devices and calculate the multi-dimensional deviation of the unknown communications based on the supply chain trust baseline; Based on the multi-dimensional deviation, a Bayesian network is used to calculate the posterior probability that the unknown communication is C2 communication; if the posterior probability exceeds a threshold, the unknown communication is determined to be C2 communication.

[0010] Optionally, the supply chain network link includes at least one of the following: the configuration download link between the IoT device and the OEM manufacturer's server, the firmware upgrade link with the cloud platform, and the data synchronization link with a third-party API; Identifying the supply chain network links includes: parsing the network traffic, extracting the communication IP address, domain name, port, and protocol, identifying the entity to which the server belongs through DNS resolution, WHOIS query, and IP geolocation, and analyzing the purpose of the communication.

[0011] Optionally, the calculation of the trust weight includes: obtaining the positive trust evidence score and the negative malicious behavior score, subtracting the difference between the positive trust evidence score multiplied by 0.6 and the negative malicious behavior score multiplied by 0.4, as the comprehensive trust weight, and assigning a weight between -1 and 1 to each edge.

[0012] Optionally, the positive trust evidence includes at least one of OEM verification status, cloud platform authentication status, TLS certificate validity, and communication encryption strength; The reverse malicious behavior characteristics include at least one of the following: time sequence abnormality characteristics, behavior pattern abnormality characteristics, traffic characteristic abnormality characteristics, and network topology abnormality characteristics.

[0013] Optionally, the trust transfer model calculates the trust value based on the link trust weight and the distance attenuation factor. The distance attenuation factor is calculated based on the distance of the link, and the calculation formula is: distance attenuation factor = e^(-λ×distance); where λ is the attenuation coefficient; the establishment of the supply chain trust baseline includes: calculating the trust value of each supply chain link, establishing the statistical distribution of the trust value, and using the mean of the trust value as the supply chain trust baseline.

[0014] Optionally, the multi-dimensional deviation includes trust path deviation; the calculation of the trust path deviation includes: If the IP address or domain name of the unknown communication is not in the normal supply chain communication path, then the trust path deviation = 1 - (trust weight of similar IP address or domain name × similarity coefficient); If the IP address or domain name of the unknown communication is in the normal supply chain communication path, but the communication characteristics deviate from the normal characteristics, then the trust path deviation degree = (1 - link trust weight) × characteristic deviation coefficient.

[0015] Optionally, the multi-dimensional deviation also includes traffic anomaly, behavior pattern deviation, timing anomaly, and network topology anomaly; the traffic anomaly is calculated by comparing the traffic characteristics of unknown communication with the normal supply chain traffic baseline, the behavior pattern deviation is calculated by comparing the behavior pattern of unknown communication with the normal supply chain communication pattern, the timing anomaly is calculated by detecting the timing characteristics of unknown communication, and the network topology anomaly is calculated by detecting the network topology characteristics of unknown communication.

[0016] Optionally, the Bayesian network uses whether it is C2 communication as the root node, trust path deviation, traffic anomaly, behavior pattern deviation, time sequence anomaly, and network topology anomaly as intermediate nodes, and observable features as leaf nodes.

[0017] Optionally, it also includes analyzing the temporal evolution of the unknown communication: tracking changes in trust in the communication of the IoT devices over time, identifying scenarios of trust decay or trust enhancement, and marking trust inflection points.

[0018] Optionally, the system may also generate a detection report, which includes: a supply chain network link diagram with labeled trust weights, a trust path deviation score, the posterior probability and its confidence interval, a time-series trust evolution curve, and the trust level of the supply chain network link.

[0019] Compared with the prior art, the present invention has the following advantages and technical effects: This invention constructs a trust link in the supply chain network, establishes a trust baseline for the supply chain, and calculates the deviation degree of the trust path for unknown communications. It can accurately identify C2 communications that deviate from the normal supply chain trust path, while avoiding misjudging normal supply chain communications as C2 communications.

[0020] This invention implements supply chain network trust link modeling, constructs a network link graph with trust weights, quantifies the credibility of each link, and establishes a supply chain trust baseline; it implements trust path deviation calculation, calculating the degree to which communication deviates from the normal supply chain trust path; it implements C2 communication probability inference based on Bayesian networks, outputs the probability and confidence interval of C2 communication, provides probabilistic C2 communication judgment, and improves the interpretability of detection; it implements temporal trust evolution analysis, tracks the change of trust in device communication over time, identifies scenarios of trust decay or trust enhancement, and can identify dynamically changing C2 communication.

[0021] This invention can run successfully in a sandbox environment without relying on firmware. Even if the firmware cannot be fully simulated, C2 communication can still be detected by analyzing the network traffic of the device, thus improving the applicability of the method.

[0022] This invention analyzes multiple dimensions, including trust path deviation, traffic anomaly, behavioral pattern deviation, Bayesian network, and temporal trust evolution curve, to clearly explain to users why a certain communication was judged as C2 communication, thereby improving the interpretability and credibility of the detection results.

[0023] This invention is applicable to firmware supply chain security assessment of various IoT devices such as charging pile TCUs, network cameras, smart door locks, and industrial PLCs. It can help security testing companies, equipment manufacturers, cloud platform operators, etc., identify C2 communication risks in firmware and improve the supply chain security level of IoT devices. Attached Figure Description

[0024] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a method according to an embodiment of the present invention. Detailed Implementation

[0025] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0026] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0027] Example 1 like Figure 1 As shown, this embodiment provides a method for detecting C2 communication of IoT devices based on supply chain network trust link modeling, including: S01: Connect to the IoT device under test and capture network traffic; Access the IoT device under test in a secure and isolated network environment to capture its network communication behavior in real time.

[0028] The construction of the device access environment includes: configuring the device IP address, subnet mask, gateway, and DNS server of the test network; ensuring the security and controllability of the access environment through VLAN segmentation, network isolation, and other technologies; capturing traffic using network bypass mirroring, man-in-the-middle proxy, or traffic probe technologies; deploying protocol simulation servers, including RTSP servers, ONVIF servers, MQTT Brokers, and HTTP servers, to simulate the communication peer of the device to trigger normal communication behavior; and capturing the device's real-time network traffic using network traffic capture tools (such as tcpdump, Wireshark, and eBPF).

[0029] The captured communication behaviors include: complete data packets of network traffic (TCP / UDP / ICMP, etc.), DNS query and response records, TLS handshake process and certificate information, communication timestamps and timing information, data packet size and payload analysis, protocol type and application layer identification, and communication peer (IP address / domain name / port).

[0030] This invention can run successfully in a sandbox environment without relying on firmware. Even if the firmware cannot be fully simulated, C2 communication can still be detected by analyzing the network traffic of the device, thus improving the applicability of the method.

[0031] S02: Based on the captured network traffic, extract the normal supply chain communication path of the device and identify the supply chain network links; The supply chain network links include at least one of the following: configuration download link between the device and the OEM manufacturer's server, firmware upgrade link with the cloud platform, and data synchronization link with third-party APIs.

[0032] The identification of the supply chain network links includes: parsing network traffic to extract the IP address, domain name, port, and protocol of the communication; identifying the entity to which the server belongs (such as OEM manufacturer, cloud platform, or third-party API) through DNS resolution, WHOIS query, and IP geolocation; analyzing the purpose of the communication to identify configuration download links (such as downloading configuration files from the OEM server when the device starts up), firmware upgrade links (such as downloading upgrade packages from the cloud platform via OTA upgrade), and data synchronization links (such as the device reporting device status to a third-party API).

[0033] S03: Construct a supply chain network link diagram with trust weights; The nodes in the supply chain network link diagram include devices, NVRs, cloud platforms, OEM servers, and third-party APIs. Edges represent network connections, and each edge contains trust attributes, including positive trust evidence and negative malicious behavior characteristics.

[0034] The positive trust evidence includes: OEM Verification Status: Verify whether the domain name is using the OEM's official domain name by querying the OEM's official server list (e.g., ...). Use .oem.com to determine if the server has been verified by the OEM. Cloud platform authentication status: By querying the official documentation of the cloud platform and verifying whether the IP address belongs to the IP range of public cloud platforms such as Alibaba Cloud, AWS, and Azure, it can be determined whether the server has been authenticated by the cloud platform. TLS certificate validity: parse the TLS handshake process of communication, extract certificate information, and verify whether the certificate issuer is a trusted CA, whether the certificate is valid, and whether the certificate public key matches the domain name; Communication encryption strength: Evaluate the encryption suite (such as AES-256-GCM, AES-128-CBC) and key length (such as RSA-2048, RSA-4096) used in the communication to determine the encryption strength as high / medium / low.

[0035] The reverse malicious behavior characteristics include: (1) Temporal anomaly characteristics: A sudden new communication: Communication from this IP / domain was observed for the first time; Sudden change in communication frequency: A surge in the number of communications in a short period of time (e.g., from 1-2 times per hour to 100+ times per hour); Abnormal timing of communication: communication suddenly starting late at night (e.g., 2:00-4:00 AM), or communication suddenly occurring during working hours; Sudden change in heart rate interval: The previously fixed heart rate interval suddenly becomes random.

[0036] (2) Abnormal behavioral patterns: Sudden protocol switch: from HTTP to HTTPS, or vice versa; Sudden port change: The port used was originally a standard port (such as 443), but was suddenly changed to a non-standard port (such as 8443, 9999); Sudden change in data packet size: A data packet that was originally of a fixed size suddenly becomes larger (e.g., from 100-200 bytes to more than 10KB) or smaller (<50 bytes); Sudden change in encryption method: TLS 1.3 is suddenly downgraded to TLS 1.0 or plaintext communication.

[0037] (3) Abnormal characteristics of flow: Sudden surge in data transfer: The amount of data transferred in a single instance far exceeds the historical baseline (e.g., a sudden increase from KB to over MB); Sudden change in connection duration: A short connection (connection duration < 1 second) suddenly becomes a long connection (lasting for several hours); A sudden change in communication direction: what was originally one-way data reporting suddenly becomes two-way interaction; Abnormal heartbeat pattern: A periodic heartbeat suddenly appears when there was no heartbeat before, or the intervals between heartbeats are jittery.

[0038] (4) Network topology anomaly characteristics: Suddenly connected to an unknown IP: The first connection is to an IP that is not in the whitelist; Geographic location change: IP address changes geographic location to high-risk countries / regions; Multi-hop communication mutation: The communication path suddenly adds intermediate nodes (possibly proxy chains); P2P communication suddenly appeared: suddenly establishing peer-to-peer communication with other devices; The calculation of the trust weight includes: The comprehensive trust weight calculation formula is used as follows: Overall Trust Weight = (Positive Trust Evidence Score × 0.6) - (Reverse Malicious Behavior Score × 0.4); Positive trust evidence score = α × certificate chain integrity + β × DNS resolution trustworthiness + γ × communication pattern stability + δ × trust delivery reliability; Reverse malicious behavior score = ε × time sequence anomaly + ζ × behavior pattern anomaly + η × traffic feature anomaly + θ × network topology anomaly. Weighting: α=β=γ=δ=0.15 (total 0.6), ε=ζ=η=θ=0.10 (total 0.4).

[0039] Each edge is assigned a weight, and the comprehensive trust weight is a value between -1 and 1. A positive value indicates trustworthiness, a negative value indicates high risk, and the larger the absolute value, the higher the degree of trustworthiness or risk.

[0040] Existing technologies rely on static feature matching to detect C2 communication. Attackers can forge heartbeat intervals, use legitimate TLS certificates, and utilize standard ports, leading to high false negative rates. Furthermore, existing technologies fail to consider the supply chain characteristics of IoT devices, making it difficult to distinguish between normal unknown communication and malicious C2 communication, resulting in high false positive rates. This invention constructs a trust link within the supply chain network, establishes a supply chain trust baseline, and calculates the deviation degree of the trust path for unknown communication. This enables accurate identification of C2 communication that deviates from the normal supply chain trust path, while avoiding misclassifying normal supply chain communication as C2 communication.

[0041] S04: Define the trust transfer model and establish a trust baseline; The trust transfer model describes the rules for trust transfer along the link, where trust = Σ(link trust weight × distance decay factor), and establishes a supply chain trust baseline.

[0042] The calculation of the distance attenuation factor includes: defining the link distance as the number of hops from the device to the target server, the distance attenuation factor = e^(-λ×distance), where λ is the attenuation coefficient, and its value ranges from 0.1 to 0.5.

[0043] The establishment of the supply chain trust baseline includes: calculating the trust value of each supply chain link, establishing the statistical distribution of the trust value (such as mean and standard deviation), and using the mean of the trust value as the supply chain trust baseline.

[0044] In this embodiment, a supply chain network link diagram with trust weights is constructed in step S03, and a supply chain trust baseline is established based on step S04. This assigns high trust weights to normal supply chain communications such as OEM configuration downloads and cloud platform upgrades, while assigning low or negative trust weights to unknown communications that deviate from this link. Compared to existing methods based on static feature matching, this embodiment can effectively distinguish between normal supply chain communications and malicious C2 communications, preventing attackers from bypassing detection by forging heartbeat intervals, using standard ports, or legitimate TLS certificates, thereby reducing both false negative and false positive rates.

[0045] S05: Detect unknown communication of the equipment and calculate the multi-dimensional deviation of the unknown communication; The multi-dimensional deviation includes trust path deviation, traffic anomaly, behavior pattern deviation, timing anomaly, and network topology anomaly.

[0046] The identification of unknown communications includes: real-time monitoring of network traffic of devices to identify new communications (i.e., communications not in the supply chain network link diagram), including new IP addresses, new domain names, new ports, and new protocols.

[0047] The calculation of the trust path deviation includes: If the IP / domain name of the unknown communication is not in the normal supply chain communication path, then: Trust path deviation = 1 - (trust weight of similar IP / domain name × similarity coefficient), where the similarity coefficient is calculated based on the network segment similarity of IP address (e.g., the same Class C network segment) or the subdomain similarity of domain name (e.g., the same second-level domain name). If the IP / domain name of the unknown communication is in the normal supply chain communication path, but the communication characteristics deviate from the normal characteristics, then: Trust path deviation degree = (1 - link trust weight) × feature deviation coefficient, where the feature deviation coefficient is calculated based on the degree of deviation of port, protocol, and encryption strength.

[0048] The calculation of the traffic anomaly includes comparing the traffic characteristics of unknown communication with the normal supply chain traffic baseline. The traffic characteristics include data packet size distribution, data packet interval distribution, and encrypted traffic ratio. The traffic anomaly is calculated as Σ(traffic feature deviation weight × feature deviation degree), and the feature deviation degree is calculated as |unknown communication feature value - baseline value| / baseline value.

[0049] The calculation of the behavioral pattern deviation includes comparing the behavioral pattern of unknown communication with the normal supply chain communication pattern. The behavioral pattern includes connection frequency, heartbeat interval, and protocol usage pattern (such as the PLAY→PAUSE state transition of RTSP). The behavioral pattern deviation is calculated as Σ(behavioral feature deviation weight × feature deviation degree).

[0050] The calculation of the time-series anomaly degree includes: detecting the time-series characteristics of communication, including the first occurrence time, communication frequency changes, communication timing distribution, and heartbeat interval standard deviation. The time-series anomaly degree is calculated as Σ(time-series characteristic anomaly weight × anomaly degree).

[0051] The calculation of the network topology anomaly degree includes: detecting network topology characteristics of communication, including IP geographical location, IP reputation, communication hop count, and P2P communication ratio. The network topology anomaly degree is calculated as Σ(topology feature anomaly weight × anomaly degree).

[0052] S06: Construct a Bayesian network to calculate the posterior probability and confidence level of unknown communication being C2 communication; The root node of the Bayesian network is whether it is C2 communication, the intermediate nodes are trust path deviation, traffic anomaly, behavior pattern deviation, timing anomaly, and network topology anomaly, and the leaf nodes are observable features, including IP address, port, heartbeat interval, packet size, and TLS certificate. Based on historical data, a conditional probability table is learned to calculate the posterior probability and confidence that the unknown communication is C2 communication.

[0053] The structure of the Bayesian network includes: root node C2 (values ​​true / false), intermediate nodes T (trust path deviation, values ​​high / medium / low), F (traffic anomaly, values ​​high / medium / low), B (behavioral pattern deviation, values ​​high / medium / low), Time (time sequence anomaly, values ​​high / medium / low), Topo (network topology anomaly, values ​​high / medium / low), and leaf nodes IP (values ​​known / unknown), P (port, values ​​standard / non_standard), H (heartbeat interval, values ​​normal / abnormal), S (packet size, values ​​normal / abnormal), and C (TLS certificate, values ​​valid / invalid).

[0054] The edges of the Bayesian network include: C2→T, C2→F, C2→B, C2→Time, C2→Topo, T→IP, T→P, T→C, F→S, F→H, B→H, B→P, Time→H, Time→P, Topo→IP.

[0055] The learning of the conditional probability table includes: calculating the conditional probability of each node based on historical data (known C2 communication and normal supply chain communication), such as P(T=high|C2=true), P(IP=unknown|T=high), P(H=abnormal|F=high), etc.

[0056] The calculation of the posterior probability includes: given the observable features (IP, P, H, S, C) of the unknown communication, using Bayesian inference to calculate the posterior probability P(C²=true|IP,P,H,S,C), the calculation formula is as follows: P(C2=true|feature)= Where P(C2=true) is the prior probability (e.g., 0.01), and P(feature|C2=true) is the likelihood probability, calculated using a Bayesian network.

[0057] The calculation of the confidence interval includes: using the bootstrap method or the Markov chain Monte Carlo (MCMC) method to calculate the confidence interval of the posterior probability.

[0058] The determination of C2 communication includes: if P(C2=true|feature)>threshold (e.g., 0.8), it is marked as C2 communication; otherwise, it is marked as normal communication.

[0059] This invention realizes C2 communication probability inference based on Bayesian network, outputs the probability and confidence interval of C2 communication, provides probabilistic C2 communication judgment, and improves the interpretability of detection.

[0060] S07: Analyze the temporal evolution of unknown communications, track changes in trust in device communications over time, and identify scenarios of trust decay or trust enhancement. The analysis of the temporal evolution includes: tracking the temporal changes of device communication and recording the communication IP address, domain name, traffic characteristics, behavior patterns, trust path deviation, and C2 communication probability at each time point.

[0061] The identification of the trust decay scenario includes: The device initially connects to the OEM server (high trust level, low trust path deviation, low probability of C2 communication); Subsequent unknown IP communication occurs (trust decay, increased trust path deviation, and increased probability of C2 communication); The frequency of unknown IP communication is increasing (trust is further weakened, trust path deviation is further increased, and the probability of C2 communication is further increased). Ultimately, the probability of C2 communication exceeds the threshold and is marked as C2 communication.

[0062] The identification of the trust enhancement scenario includes: The device is connected to an unknown IP address (low trust level, high deviation of the trust path, high probability of C2 communication). Subsequent verification via TLS certificate confirmed that the IP belongs to the OEM's CDN (enhanced trust, reduced trust path deviation, and reduced probability of C2 communication). It was ultimately identified as normal supply chain communication.

[0063] The marking of the trust inflection point includes: identifying the time point when the trust path deviation or C2 communication probability changes significantly (such as the change exceeding a threshold), marking it as a trust inflection point, and analyzing the event that triggers the inflection (such as the first connection to an unknown IP or successful TLS certificate verification).

[0064] The construction of the temporal trust evolution curve includes: constructing a temporal trust evolution curve with time on the horizontal axis and trust path deviation or C2 communication probability on the vertical axis, and visually displaying the evolution of trust over time.

[0065] This invention realizes temporal trust evolution analysis, tracks the changes in trust in device communication over time, identifies scenarios of trust decay or trust enhancement, and can identify dynamically changing C2 communication.

[0066] S08: Generate C2 communication test report; The report includes a trust path map, trust path deviation score, C2 communication probability, confidence interval, time-series trust evolution curve, and trust level of supply chain network links.

[0067] The trust path graph includes: a visual representation of the supply chain network link diagram, marking the trust weight of each edge, and marking unknown communication connections.

[0068] The trust path deviation score includes: displaying the values ​​and rating levels (such as high / medium / low) of the trust path deviation, traffic anomaly, behavior pattern deviation, timing anomaly, and network topology anomaly of unknown communication.

[0069] The C2 communication probability includes: the posterior probability that an unknown communication is C2 communication, the confidence interval, and the classification result (C2 communication / normal communication).

[0070] The time-series trust evolution curve includes: visually displaying the change in trust path deviation or C2 communication probability over time, and marking trust inflection points.

[0071] The trust level of the supply chain network links includes: marking the trust level of each supply chain link (such as high / medium / low), based on historical security events, server reputation, and communication encryption strength assessment.

[0072] This invention analyzes multiple dimensions, including trust path deviation, traffic anomaly, behavioral pattern deviation, Bayesian network, and temporal trust evolution curve, to clearly explain to users why a certain communication was judged as C2 communication, thereby improving the interpretability and credibility of the detection results.

[0073] This invention is applicable to firmware supply chain security assessment of various IoT devices such as charging pile TCUs, network cameras, smart door locks, and industrial PLCs. It can help security testing companies, equipment manufacturers, cloud platform operators, etc., identify C2 communication risks in firmware and improve the supply chain security level of IoT devices.

[0074] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An IoT device C2 communication detection method based on supply chain network trust link modeling, characterized in that, Includes the following steps: Capture network traffic from IoT devices; Based on the network traffic, extract the normal supply chain communication path of IoT devices and identify supply chain network links; Based on the supply chain network links, construct a supply chain network link graph with trust weights, and calculate the trust weight for each edge; Based on the supply chain network diagram and the trust weights, a trust transfer model is defined; The trust value of each supply chain link is obtained based on the trust transfer model, and a supply chain trust baseline is established based on the trust value. Detect unknown communications of the IoT devices and calculate the multi-dimensional deviation of the unknown communications based on the supply chain trust baseline; Based on the multi-dimensional deviation, a Bayesian network is used to calculate the posterior probability that the unknown communication is C2 communication; if the posterior probability exceeds a threshold, the unknown communication is determined to be C2 communication.

2. The IoT device C2 communication detection method based on supply chain network trust link modeling according to claim 1, characterized in that, The supply chain network links include at least one of the following: the configuration download link between the IoT device and the OEM manufacturer's server, the firmware upgrade link with the cloud platform, and the data synchronization link with a third-party API; Identifying the supply chain network links includes: parsing the network traffic, extracting the communication IP address, domain name, port, and protocol, identifying the entity to which the server belongs through DNS resolution, WHOIS query, and IP geolocation, and analyzing the purpose of the communication.

3. The IoT device C2 communication detection method based on supply chain network trust link modeling according to claim 1, characterized in that, The calculation of the trust weight includes: obtaining the positive trust evidence score and the negative malicious behavior score, multiplying the positive trust evidence score by 0.6 and subtracting the negative malicious behavior score multiplied by 0.4 to obtain the comprehensive trust weight, and assigning a weight between -1 and 1 to each edge.

4. The IoT device C2 communication detection method based on supply chain network trust link modeling according to claim 3, characterized in that, The positive trust evidence includes at least one of the following: OEM verification status, cloud platform authentication status, TLS certificate validity, and communication encryption strength; The reverse malicious behavior characteristics include at least one of the following: time sequence abnormality characteristics, behavior pattern abnormality characteristics, traffic characteristic abnormality characteristics, and network topology abnormality characteristics.

5. The IoT device C2 communication detection method based on supply chain network trust link modeling according to claim 1, characterized in that, The trust transfer model calculates the trust value based on the link trust weight and the distance attenuation factor. The distance attenuation factor is calculated based on the link distance, and the calculation formula is: distance attenuation factor = e^(-λ×distance); Where λ is the attenuation coefficient; The establishment of the supply chain trust baseline includes: calculating the trust value of each supply chain link, establishing the statistical distribution of the trust value, and using the mean of the trust value as the supply chain trust baseline.

6. The IoT device C2 communication detection method based on supply chain network trust link modeling according to claim 1, characterized in that, The multi-dimensional deviation includes trust path deviation; The calculation of the trust path deviation includes: If the IP address or domain name of the unknown communication is not in the normal supply chain communication path, then the trust path deviation = 1 - (trust weight of similar IP address or domain name × similarity coefficient); If the IP address or domain name of the unknown communication is in the normal supply chain communication path, but the communication characteristics deviate from the normal characteristics, then the trust path deviation degree = (1 - link trust weight) × characteristic deviation coefficient.

7. The IoT device C2 communication detection method based on supply chain network trust link modeling according to claim 6, characterized in that, The multi-dimensional deviation also includes traffic anomaly, behavior pattern deviation, timing anomaly, and network topology anomaly. The traffic anomaly is calculated by comparing the traffic characteristics of unknown communication with the normal supply chain traffic baseline. The behavior pattern deviation is calculated by comparing the behavior pattern of unknown communication with the normal supply chain communication pattern. The timing anomaly is calculated by detecting the timing characteristics of unknown communication. The network topology anomaly is calculated by detecting the network topology characteristics of unknown communication.

8. The IoT device C2 communication detection method based on supply chain network trust link modeling according to claim 1, characterized in that, The Bayesian network uses whether it is C2 communication as the root node, trust path deviation, traffic anomaly, behavior pattern deviation, time sequence anomaly, and network topology anomaly as intermediate nodes, and observable features as leaf nodes.

9. The IoT device C2 communication detection method based on supply chain network trust link modeling according to claim 1, characterized in that, It also includes analyzing the temporal evolution of the unknown communication: tracking changes in trust in the communication of the IoT devices over time, identifying scenarios of trust decay or trust enhancement, and marking trust inflection points.

10. The IoT device C2 communication detection method based on supply chain network trust link modeling according to claim 1, characterized in that, It also includes generating a detection report, which includes: a supply chain network link diagram marked with trust weights, a trust path deviation score, the posterior probability and its confidence interval, a time-series trust evolution curve, and the trust level of the supply chain network link.

Images