Method for generating honeypot
By training a large language model to simulate operating system command line interfaces, the method automates the creation of honeypots, addressing the manual effort challenge and enhancing efficiency in creating effective honeypot simulations.
Patent Information
- Application Number
- JP2024167968
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-09-29
- Filing Date
- 2024-09-27
- Publication Date
- 2025-04-10
AI Technical Summary
Implementing honeypots suitable for specific requirements and target systems requires significant manual effort from experts, making it a time-consuming and labor-intensive process.
A method involving training a large language model to respond to operating system command line interface commands, allowing for the creation of a honeypot that simulates the command line interface of a target system, thereby reducing the need for manual implementation of commands.
This approach enables the automatic and low-risk simulation of command line interfaces for various operating systems, reducing manual effort and enhancing the efficiency of honeypot creation while maintaining a controlled environment to analyze attacker strategies.
Smart Images

Figure 2025060466000001_ABST
Abstract
Description
[Technical field]
[0001] The present disclosure relates to a method for creating a honeypot. [Background technology]
[0002] The number of networked data processing devices (including embedded devices) is growing rapidly. Whether it is a server computer on the Internet or a control mechanism in the automotive or IoT field, an important aspect of all these devices is product security. A honeypot is a dummy function that mimics such a valuable (target) system, attracting attackers and obtaining information about their attack strategies and attack targets. Above all in corporate IT, honeypots are an established tool for threat analysis and are now also used in the field of (Industrial) Internet of Things ((I)IoT). Honeypots are a very useful tool to complement a cybersecurity strategy, but their implementation, adapted to the special requirements and the respective target system, requires a lot of manual work by experts. Summary of the Invention [Problem to be solved by the invention]
[0003] Therefore, measures that allow easier provisioning (especially configuration) of suitable honeypots are desirable. [Means for solving the problem]
[0004] According to various embodiments, a method is provided for creating a honeypot for a target system, the method including training a large scale language model to respond to operating system command line interface commands, such as a command line interface of the target system, and using the trained large scale language model to create a honeypot that responds to operating system command line interface commands it receives (e.g., over a computer network) (i.e., the honeypot is designed to forward incoming command line interface commands to the large scale language model (i.e., generate corresponding prompts) and respond to the command line interface commands according to the output of the large scale language model).
[0005] In other words, according to various embodiments, a suitably trained large-scale language model simulates the target system's command line interface (typically an operating system command line interface, such as a shell), such as Secure Shell (SSH), Power Shell, or another command line interpreter.
[0006] The above-mentioned method allows for a comprehensive simulation of operating system command line interfaces (e.g. shells). For this, no manual implementation of commands (e.g. shell commands) is necessary. Command line interfaces of various operating systems can be emulated (simulated). The use of such simulations is essentially risk-free (even if the language model malfunctions) (because with regard to compromising the honeypot via the command line interface, the command line interface is only simulated and thus does not hand a dangerous tool to the attacker).
[0007] Various exemplary embodiments are presented below. Exemplary embodiment 1 is a method for creating a honeypot as described above. Exemplary embodiment 2 is a method as described in exemplary embodiment 1, including creating a honeypot with an output filter that filters on an output filter criterion before the output of the large-scale language model is used in response to an operating system command line interface command received by the honeypot.
[0008] For example, the filter criteria may include filtering out unreliable (e.g., syntactically incorrect) information and / or information that is to be kept confidential, either to increase the reliability of the honeypot or to avoid sensitive information being leaked.
[0009] Exemplary embodiment 3 is a method according to exemplary embodiment 1 or 2, comprising creating a honeypot with an input filter that filters operating system command line interface commands received by the honeypot before the operating system command line interface commands received by the honeypot are fed to a large-scale language model to generate a response to the operating system command line interface commands received by the honeypot.
[0010] For example, the filter criteria may include filtering out operating system or command line interface commands that may induce erroneous (unreliable) outputs (and thus responses), as well as filtering out inputs that may adversely affect further training (e.g., online training) of the large-scale language model.
[0011] Exemplary embodiment 4 is a method according to any one of exemplary embodiments 1 to 3, further comprising training the large-scale language model based on attacker behavior in response to responses to command line interface commands generated using the large-scale language model.
[0012] For example, an attacker can be trained to be rewarded (e.g., in the sense of reinforcement learning with human feedback) if, after a response, he or she still remains in the honeypot (i.e., does not terminate communication) or continues with a particular attack.
[0013] Exemplary embodiment 5 is a honeypot creation mechanism designed to implement the method described in any one of exemplary embodiments 1 to 4. Exemplary embodiment 6 is a computer program comprising instructions which, when executed by a processor, cause the processor to perform the method according to any one of exemplary embodiments 1 to 4.
[0014] Exemplary embodiment 7 is a computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform a method according to any one of exemplary embodiments 1 to 4.
[0015] Exemplary embodiment 8 is a honeypot (or a data processing mechanism implementing a honeypot) that responds to operating system command line interface commands it receives (e.g., over a computer network) using a large scale language model (which has been trained to respond to operating system command line interface commands, such as a target system's command line interface) (i.e., each received command line interface command is fed to the large scale language model (possibly filtered by an input filter), and each output of the large scale language model (possibly filtered by an output filter) is used as a response to the command line interface command).
[0016] In the drawings, like reference characters generally refer to the same parts in all the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various aspects are described with reference to the following drawings: [Brief description of the drawings]
[0017] [Figure 1] FIG. 1 illustrates a computer network. [Diagram 2] FIG. 2 illustrates the creation of a honeypot according to one embodiment. [Diagram 3] 1 is a flow chart illustrating a method for creating a honeypot according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0018] The following detailed description refers to the accompanying drawings, which show, for the purpose of illustration, specific details and aspects of the present disclosure that can be implemented in the present invention. Other aspects can be used and structural, logical and electrical changes can be made without departing from the scope of protection of the present invention. Various aspects of the present disclosure are not necessarily mutually exclusive, since some aspects of the present disclosure can be combined with one or more other aspects of the present disclosure to form new aspects.
[0019] Various examples are described in more detail below. 1 shows a computer network 100. The computer network 100 includes a number of data processing devices 101 to 105 interconnected by communication links. The data processing devices 101 to 105 include, for example, a server computer 101, a control device 102, and user terminals 103 and 104.
[0020] The server computer 101 provides various services, such as an internet site and a bank portal. For example, the control device 102 is a control mechanism for a robotic device, such as a control mechanism in an autonomous vehicle. Thus, the server computer 101 and the control device 102 perform different tasks, and typically, user terminals 103, 104 can access the server computer 101 or the control device 102. This is especially true when the server computer 101 provides a function for the user, such as a bank portal. However, the control device 102 can also allow access from the outside (for example, so that the settings of the control device 102 can be made). The server computer 101 and the control device 102 can store security-critical data and perform security-critical tasks depending on the task of the server computer 101 or the control device 102. Therefore, the server computer 101 and the control device 102 must be protected from attackers. For example, an attacker using one of the user terminals 104 could successfully launch an attack to obtain sensitive data (e.g., keys), tamper with accounts, or even tamper with the control device 102 and cause an accident.
[0021] One security measure against such attacks is the so-called honeypot 106 (which is implemented by one of the data processing devices 105). The honeypot 106 is thought to provide a facility to attract potential attackers, thereby acting as a decoy. But now the honeypot is isolated from sensitive information or critical functions, so that attacks against the honeypot are made in a controlled environment and the risk of compromising real functions is minimized. In this way, the honeypot 106 makes it possible to obtain information about attacks against a target system (e.g. one of the server computers 101 or one of the control devices 102), thus understanding the threat landscape, and to respond to the threat landscape by implementing appropriate countermeasures in the target system, so that these attacks do not compromise the target system.
[0022] That is, a honeypot is a masquerading system that mimics a target system (also called a "valuable target"). The honeypot induces attackers to attack the honeypot, which uncovers attack vectors that target the real valuable target. So, for example, web servers (or web server software) are often the targets that are simulated by honeypots. Because web servers make up a large portion of the public Internet, it is important to continually monitor for threats targeting web servers.
[0023] Honeypots are particularly interesting in the automotive industry, since there is little data on real attacks: according to various embodiments, for example, honeypots 106 can be implemented in a vehicle, where the computer network 100 may at least partially include the internal network of the vehicle (but may also include networks that establish connections to the vehicle from the outside, such as mobile networks).
[0024] That is, honeypots are decoy resources that mimic valuable target systems to attract attackers. Honeypots are used to receive attacks so that defenders who closely monitor the systems can gain insights into the adversary's strategy. The value of these insights depends on the number of interaction options the honeypot provides to the attacker. When an attacker interacts with such an imitation of a target system, this may completely reveal the attack path, while honeypots that only allow easier interactions may only reveal part of the attack. For example, a honeypot that only mimics the login shell will only locate the registration data that the attacker is trying to use.
[0025] However, with more interaction options comes greater risk: an attacker may compromise the honeypot system itself or use it in a later attack against a third party. To address this risk, for example, honeypots can be used that only simulate the system shell of the simulated target system (but do not actually contain the system shell with all its functionality). Such simulations can be implemented manually, so that individual shell commands are reprogrammed for simulation by the honeypot. However, because a system shell typically contains many commands, typically only a small subset of shell commands that an attacker is likely to use are implemented in this approach, limiting the complexity. However, this also reduces the reliability of the honeypot and / or the attacker's interest in it.
[0026] Thus, according to various embodiments, a solution is provided for realizing an automated, low-risk command line interface simulation (e.g., shell simulation) for various operating systems for use in honeypots, where the command line interface is extensively simulated based on a language model (e.g., a large-scale language model (LLM) using a neural transformer network architecture, among others). The command line interface thus simulated can then be used for the honeypot (e.g., an automated honeypot creator uses this simulation in the honeypot). The language model (which is trained to simulate the command line interface) provides an attacker with a high degree of system interaction without the risk of the honeypot being compromised and, potentially, without the risk of an attack being performed using the compromised honeypot (since the command line interface is only simulated).
[0027] FIG. 2 illustrates the creation of a honeypot 200 according to one embodiment. The configuration decisions for the honeypots (and possibly also the selection of an architecture for the honeypots to be configured) are made by a honeypot creation mechanism (or honeypot configuration mechanism), which corresponds, for example, to one of the user terminals 104 (e.g., a computer that configures the honeypots 106 by a user (e.g., a system administrator) and instructs the data processing device 105 to provide the honeypots 106 so configured). Thus, the methods for creating honeypots described herein are, for example, performed (e.g., automatically) by such a honeypot creation mechanism.
[0028] The creation of Honeypot 200 involves the following components: Training example 201: command line interface inputs and outputs of a command line interface of a particular target system, which the honeypot 200 will mimic and which the LLM will mimic correspondingly. Since different operating systems provide different types of functionality and syntax of their command line interfaces, the LLM 202 is trained to learn basic properties of the command line interface of each target system.
[0029] Filter 203 for malicious inputs: command line interface inputs that are fed to the LLM 202 during operation of the honeypot 200 and that may induce erroneous outputs are filtered out to avoid being discovered by an attacker (who could for example expose the honeypot as such based on the erroneous output). This is done automatically, for example using a whitelist of command line interface commands of the target system. For all commands not in the whitelist, the honeypot then only issues a system-specific error message. Alternatively, blacklisting techniques can be used.
[0030] LLM-based simulated command line interface 204: The LLM 202 simulates a command line interface (e.g. a system shell of the target system) of the target system inside the honeypot 200 (i.e. the data processing device 105 implementing the honeypot 200 implements the LLM 202 therefor or has access to it (if the LLM 202 is implemented in e.g. another data processing device). The attacker 205 may interact with the command line interface, and the LLM 202 generates text feedback corresponding to the attacker's 205 interactions. The LLM-based command line interface 204 transmits the attacker's 205's respective user interface inputs 206 to the LLM 202 and outputs the output 208 generated by the LLM 202 (possibly filtered by an output filter 207) in response to the attacker's 205's user interface inputs 206.
[0031] The inputs 206 of the attacker 105 can also be used to further train the LLM 202 (i.e., the base model for the simulated user interface 204). The LLM 202 can be refined when it is observed which parts of the honeypot 200 the attacker frequently explores or which user interface commands (or the honeypot 200's responses thereto) cause the attacker to leave the honeypot 200. For example, the LLM 202 can be rewarded (e.g., in the sense of reinforcement learning) for the generated outputs 208 depending on how the attacker behaves in response to the outputs 208, e.g., how long the attacker still stays in the honeypot 200 or whether the attacker continues the attack in a particular area or changes the area.
[0032] Training can be done online (while an attack is in progress, to prepare for a specific attack), if further (re)training can proceed relatively quickly, or offline (after an attack), if, for example, the entire honeypot fleet needs to be retrained. Attacker inputs to other honeypot systems can also be used for learning, since attack strategies can usually be transferred to other operating systems.
[0033] If such training (and thus the learning honeypot 200) is provided, the LLM 202 can also be protected by using a filter 203 against malicious inputs. That is, one problem with learning honeypots is the spoofing of the learning algorithm by an attacker. For example, suppose an attacker repeatedly executes a harmless command (e.g. creating a text file) without any other commands in between. The learning algorithm of the LLM 202 may then assume that, in some cases, the attacker expects a different output and tries to adjust the previously correct output of the LLM 202. The attacker can then execute this same command on any system and either get a correct response (=correct system) or get a wrong output because the LLM 202 has learned incorrectly (=honeypot). Such poisoning attacks can be filtered out, that is, it is possible to avoid an attacker influencing the training of the LLM 202 and causing the LLM 202 to react in an undesirable way (from the perspective of the honeypot 202 operator).
[0034] For example, a honeypot creator agent might do the following: 1. Train the LLM 202 (as a base model for the honeypot 200) using training examples (e.g., pairs of inputs and associated outputs) of the user interface of the target system that the LLM 202 will simulate. Alternatively, a pre-trained model can be obtained and trained for this specific purpose. This pre-trained model typically should contain only non-critical information so that it can be used as the basis for the LLM 202 without filtering.
[0035] 2. In the event that sensitive information is introduced into the training of LLM202 (which may occur by training against specific features of LLM202), LLM202 will be filtered for such sensitive content, ensuring that an attacker cannot extract content that is intended to be sensitive when the trained LLM202 is deployed.
[0036] 3. The LLM 202 is used to simulate a user interface 204 inside the honeypot 200. The attacker's 205 input 206 forms the prompt for the LLM 202. Alternatively, the input 206 can be augmented or modified by a filter 203 for malicious input before being used as a prompt for the LLM 202.
[0037] 4. The output 208 of the LLM 202 is then presented to the attacker 205. The output 208 may have been filtered by an output filter 207 (e.g., to filter out information that should be kept confidential, or non-sense or erroneous output (e.g., blacklisted output)).
[0038] 5. For ongoing training of LLM202, data on attacks such as, for example, the following will be collected and training will be adapted accordingly: - The area of the honeypot 200 that is under attack (i.e. the attacker's area of interest) - Attacker's time investment - Information about what caused the attacker to leave the honeypot 200 (for example, an output that caused the attacker to leave the honeypot 200 during training, i.e., to terminate communication, is penalized).
[0039] Steps 4 and 5 can be repeated to continually improve the simulation and extend the attacker's time investment. In summary, according to various embodiments, a method is provided as shown in FIG.
[0040] FIG. 3 shows a flow chart 300 illustrating a method for creating a honeypot according to one embodiment. At 301, a large scale language model is trained to respond to operating system command line interface commands, such as a command line interface of a target system.
[0041] At 302, a honeypot is created (and implemented or deployed) that responds to operating system command line interface commands it receives (e.g., over a computer network) using the trained large-scale language model (i.e., the honeypot is designed to forward incoming command line interface commands to the large-scale language model (i.e., generate corresponding prompts) and respond to the command line interface commands according to the output of the large-scale language model).
[0042] The method of FIG. 3 can be performed by one or more computers with one or more data processing units. The term "data processing unit" can be understood as any type of entity that allows processing of data or signals. For example, data or signals may be handled according to at least one (i.e. one or more) specific functions performed by the data processing unit. The data processing unit may include or consist of analog circuits, digital circuits, logic circuits, microprocessors, microcontrollers, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable gate array integrated circuits (FPGAs), or any combination thereof. Any other manner for implementing the respective functions described in more detail herein may also be understood as a data processing unit or logic circuit configuration. One or more of the method steps individually described herein may be realized (e.g. implemented) by a data processing unit by one or more specific functions performed by the data processing unit.
[0043] Thus, the method is inter alia computer-implemented according to various embodiments. [Explanation of symbols]
[0044] 106 Honeypot 200 Honeypot 202 Large-scale Language Model 203 Input Filter 204 LLM-based command line interface 205 Attacker 206 Operating System · Command Line Interface · Commands 207 Output Filter 208 Response
Claims
1. A method for creating a honeypot (106, 200) for a target system, comprising: training a large-scale language model (202) to respond to operating system command line interface commands (206), such as a command line interface of a target system; using the trained large-scale language model (202) to create a honeypot (106, 200) that responds to incoming operating system command line interface commands (206); A method comprising:
2. 2. The method of claim 1, further comprising creating the honeypot (106, 200) with an output filter (207) that filters on an output filter criterion before an output of the large-scale language model (202) is used as a response (208) to an operating system command line interface command (206) received by the honeypot (106, 200).
3. 3. The method of claim 1, further comprising creating the honeypot (106, 200) with an input filter (203) that filters the operating system command line interface command (206) received by the honeypot (106, 200) before the operating system command line interface command (206) received by the honeypot (106, 200) is provided to the large-scale language model (202) to generate a response (208) to the operating system command line interface command (206) received by the honeypot (106, 200).
4. 4. The method of claim 1, further comprising: training the large scale language model (202) based on attacker behavior in response to responses (208) to the command line interface commands (206) generated using the large scale language model (202).
5. A honeypot creation mechanism designed to carry out the method according to any one of claims 1 to 4.
6. A computer program comprising instructions which, when executed by a processor, cause the processor to carry out a method according to any one of claims 1 to 4.
7. A computer readable medium storing instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 4.
8. A honeypot (106, 200) that responds to incoming operating system command line interface commands (206) using a large-scale language model (202).