Method for creating a honeypot

DE102023209244A1Pending Publication Date: 2025-03-27ROBERT BOSCH GMBH
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
DE102023209244
Authority / Receiving Office
DE · DE
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-09-21
Publication Date
2025-03-27

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

According to various embodiments, a method for creating a honeypot for a target system is described, comprising: determining, by means of a honeypot creation device to which access to the target system is granted, the directory tree of a file system of the target system, shell commands supported by the operating system and processes running on the target system by means of access to the target system, and creating, by means of the honeypot creation device, a honeypot containing a file system with a copy of the determined directory tree, imitating the determined shell commands and imitating the execution of the determined processes.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] The present disclosure relates to methods for creating a honeypot.

[0002] The number of networked computing devices (including embedded devices) is increasing rapidly. A key aspect of all these devices—be they server computers on the internet or control devices in automotive or IoT systems—is product security. Honeypots are decoys that mimic such valuable (target) systems to lure attackers and gather information about their attack strategies and objectives. Honeypots are an established threat analysis tool, especially in corporate IT, and they are now also being used in the (Industrial) Internet of Things (IoT). Although honeypots are a very useful tool to complement cybersecurity strategies, implementing them for specific needs and target systems requires a great deal of manual work by experts.

[0003] Approaches that enable easier deployment (especially configuration) of a suitable honeypot for a given target system are therefore desirable.

[0004] According to various embodiments, a method for generating a honeypot for a target system is provided, comprising determining, by a honeypot generating device, access to the target system is granted from • the directory tree of a file system of the target system; • operating system shell commands supported by the operating system; • processes running on the target system (in operation) (and thus services supported by the target system, since there are also internal processes for these) by accessing the target system and creating, through the honeypot creation facility, a honeypot that contains a file system with a copy of the detected directory tree, imitates the detected shell commands and imitates the execution of the detected processes.

[0005] According to various embodiments, a honeypot generation device is granted access to the target system, whereby such access can be understood as such that the honeypot generation device can determine at least the aforementioned information (directory tree, shell commands, running processes) (by exploring the target system, e.g. determining the directory tree e.g. using a crawler, reading the running processes (e.g. accessing a task manager) and determining the supported shell commands (e.g. reading a corresponding list). The honeypot generation device then creates a corresponding honeypot. Since the creation of the honeypot is thus based on detailed knowledge of the internal function or structure of the target system, the above approach can be regarded as white-box creation of a honeypot.

[0006] The method described above not only allows static content to be copied to a honeypot, but also dynamic parts of the target system, e.g., system services and command-line tools, are explored and the honeypot is implemented to support them. This means that essentially the entire functionality of an operating system (as far as externally visible) is automatically imitated using a honeypot, including dynamic content such as shell input. Thus, the generated honeypot does not just support a single service or protocol, but the honeypot is created with the aim of creating a (at least approximately) complete imitation of the functionality of an operating system, whereby different operating systems can be imitated. This is particularly important in the world of embedded systems, where a large number of operating systems are used.

[0007] Various examples of implementation are given below.

[0008] Embodiment 1 is a method for creating a honeypot (for a given target system) as described above.

[0009] Embodiment 2 is the method according to embodiment 1, wherein the honeypot generation device checks a secrecy criterion for information obtained by it through access to the target system and generates the honeypot in such a way that it does not contain information to be kept secret according to the secrecy criterion, which it determines through access to the target system.

[0010] The honeypot creation facility can therefore filter the information obtained and create the honeypot based on the filtered information (i.e., without the filtered information). This particularly applies to information from the file system (such as possibly specific files).

[0011] Embodiment 3 is the method according to embodiment 1 or 2, wherein the honeypot generating device generates the honeypot in such a way that it imitates the determined shell commands in such a way that their invocation via a network interface of the honeypot is supported, wherein the honeypot supports the shell commands in a form such that, compared to their implementation on the target system, they lack functionalities that meet a predetermined risk criterion (for example, are classified as dangerous for one or more other data processing devices according to the predetermined risk criterion).

[0012] The honeypot creation facility implements the shell commands in a “defused” form on the honeypot to prevent damage caused by their implementation on the honeypot.

[0013] Embodiment 4 is the method according to one of the embodiments 1 to 3, wherein the honeypot generation device determines information about the resource consumption of the detected processes on the target system and generates the honeypot in such a way that it imitates the detected processes in such a way that their resource consumption on the honeypot imitates the resource consumption they have on the target system.

[0014] This increases the credibility of the honeypot against a potential attacker.

[0015] Embodiment 5 is a data processing system with a honeypot generation device, which is configured to carry out the method according to one of the embodiments 1 to 4.

[0016] Embodiment 6 is a computer program including instructions that, when executed by a processor, cause the processor to perform a method according to any one of embodiments 1 to 4.

[0017] 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 embodiments 1 to 4.

[0018] In the drawings, like reference characters generally refer to the same parts throughout the several 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. Fig. 1 shows a computer network. Fig. Figure 2 illustrates the process of creating and deploying a honeypot. Fig. Figure 3 shows the creation of a honeypot for a target system in more detail. Fig. 4 shows a flowchart illustrating a method for creating a honeypot for a target system according to one embodiment.

[0019] The following detailed description refers to the accompanying drawings, which, by way of illustration, show specific details and aspects of this disclosure in which the invention may be practiced. Other aspects may be utilized, and structural, logical, and electrical changes may be made without departing from the scope of the invention. The various aspects of this disclosure are not necessarily mutually exclusive, as some aspects of this disclosure may be combined with one or more other aspects of this disclosure to form new aspects.

[0020] Various examples are described in more detail below.

[0021] Fig. 1 shows a computer network 100. The computer network 100 includes a plurality of data processing devices 101-105 interconnected by communication links 106. The data processing devices 101-105 include, for example, server computers 101 and control devices 102, as well as user terminals 103, 104.

[0022] Server computers 101 provide various services, such as websites, banking portals, etc. A control unit 102 is, for example, a control device for a robotic device such as a control device in an autonomous vehicle. The server computers 101 and control units 102 therefore perform various tasks, and typically a server computer 101 or a control unit 102 can be accessed from a user terminal 103, 104. This is particularly the case when a server computer 101 offers a user a functionality, such as a banking portal. However, a control unit 102 can also enable external access (e.g., so that it can be configured). Depending on the task of a server computer 101 or control unit 102, they can store security-relevant data and perform security-relevant tasks. Accordingly, they must be protected against attackers.For example, an attacker using one of the user terminals 104 could, through a successful attack, obtain secret data (such as keys), manipulate accounts, or even manipulate a control device 102 in such a way that an accident occurs.

[0023] One security measure against such attacks is a so-called honeypot 106 (implemented by one of the data processing devices 105). It supposedly provides functionality and thus serves as bait to attract potential attackers. However, it is isolated from secret information or critical functionality so that attacks on it take place in a controlled environment and the risk of compromising the actual functionality is minimized. It thus makes it possible to gain knowledge about attacks on a target system (e.g., one of the server computers 101 or one of the control units 102)—and thus the threat landscape—to which the implementation of suitable measures on the target system can respond without these attacks endangering the target system.

[0024] Gaining insights into the threat landscape related to a specific device or product is a challenging task. Putting a real system into the hands of attackers to investigate the attack path can provide a wealth of information. However, sacrificing a real device is often not an option – such environments could be misused for later attacks or are expensive to maintain in large numbers. Therefore, medium-interaction honeypots are an alternative to these high-interaction environments. These medium-interaction honeypots are computer programs that pretend to be a real system. Because they emulate a system shell, file system, and services, medium-interaction honeypots attract attackers without compromising a real system. Implementing such a real-looking environment, i.e., deploying a honeypot for a specific (target) system (e.g.,However, creating a system (e.g., a server computer 101 or a control unit 102) in a way that makes it credible to potential attackers is a labor-intensive process. An engineer must manually adopt all the specifics of the emulated operating system. It also requires experience and / or detailed knowledge of honeypots.

[0025] According to various embodiments, an approach is therefore provided that makes it possible to automate the creation of a medium-interaction honeypot, ie to derive a medium-interaction honeypot environment from a system to be protected without manual implementation.

[0026] Fig. 2 illustrates the process of creating and deploying a honeypot (e.g., honeypot 106).

[0027] The configuration is performed by a honeypot generation device 201 (implementing a "honeypot agent" A) corresponding, for example, to one of the user terminals 104 (e.g., a computer with which a user (such as a system administrator) configures the honeypot 106 and instructs the data processing device 105 to provide the thus configured honeypot 106).

[0028] Honeypot agent A gains access to a (critical, i.e., protected) target system. This can occur independently of the operating system or the services running on the target system. Honeypot agent A extracts operating system properties 202 of the target system (i.e., "samples" relating to the target system) such as the file system FS, shell commands Shl, internal processes procs, and outward-facing services SV (i.e., services offered by the target system via a network interface of the target system).

[0029] At 204, honeypot agent A filters the extracted information about the target system 202, i.e., removes sensitive (e.g., confidential and / or brand-damaging) data. At 205, honeypot agent A can supplement (i.e., complete) information about the target system from previous investigations (from a database 206 with previous "samples").

[0030] The honeypot generation device 201 then creates a honeypot 207 according to the (possibly filtered and completed) information.

[0031] During operation, the honeypot 208 logs attacks by attackers 209 for analysis in an attack log 210.

[0032] The logged attacks are analyzed, and the information obtained is used to update the respective target system 211. Whether the security policies have been (appropriately) updated determines whether an attacker's 209 attack on the target system 211 is successful (ie, grants the attacker access 212 to the target system) or not (ie, fails 213).

[0033] If an attacker gains access to a safety-critical system, such as a vehicle's engine control unit, this can have serious consequences, e.g., leading to a fatal accident. A honeypot 208 created according to the described approach makes it possible, for example, to protect vehicle components, such as an ECU, from potential attacks by detecting the attacks and protecting the vehicle components accordingly. This can, for example, reduce the likelihood of car theft, the extraction of sensitive (user) driving data from a vehicle, and manipulation of the car's properties (braking, lane changes, engine life, and other behaviors during manual or autonomous driving).

[0034] As explained above, the honeypot agent A in 203 extracts operating system properties of the target system 211 so that the generated honeypot 208 can correctly imitate the target system 211. This will be explained below with reference to Fig. 3 described in more detail.

[0035] Fig. 3 shows the creation of a honeypot 301 for a target system 302 in greater detail.

[0036] The honeypot agent explores (ie examines) the operating system (OS) of the target system 302, in Fig. 3 labeled "VaTS" (for "valuable target system") and creates an emulated version 303 of the operating system that correctly mimics this. According to one embodiment, the operating system components that the honeypot agent explores include at least the following: • File system FS: The honeypot agent not only copies the file system but also detects and modifies sensitive data, ensuring, for example, that no secrets are present on the honeypot or made accessible by it. The file system is indexed, for example, using a crawler that explores the entire file system and provides a detailed image of the file system tree. To remove sensitive data (resulting in a filtered and thus "defused" file system 304), the honeypot agent can rely on pattern matching (PM) (e.g., "password_file") or use an appropriately trained machine learning (ML) model to reliably detect and modify sensitive data. • Shell commands Shl: To enable an attacker to interact with the honeypot, the honeypot 301 should implement at least a subset of the shell commands of the target system 302. It should be noted that shell commands that cause harm to third parties (e.g., executing Python scripts, pinging third parties, scanning third-party systems) are implemented according to one embodiment in such a way that the attacker receives positive feedback when calling a shell command, but no real consequences are to be feared. The honeypot 301 is therefore implemented in such a way that it realizes a defused shell 305: The attacker receives feedback on a shell command in the form of text, but the honeypot does not take any further steps to execute the shell command (at least not for critical shell commands).To implement the shell on the honeypot, the honeypot agent can access existing commands from the help or documentation of the target system 302. To identify and mitigate potentially dangerous commands, the honeypot agent can also use pattern matching of the command description or be supported by machine learning. • Internal processes (procs): To convincingly imitate the target system 302, the intermediate interaction environment offered by the honeypot must emulate the target system's internal processes. These can attract attackers because they provide clues about the system's nature. To imitate realistic processes, the honeypot agent observes the internal processes of the target system 302 (e.g., ps displays a list of all internal processes on most Unix systems). With this information, the honeypot agent can realistically recreate not only the processes but also their hardware utilization over time on the honeypot. It also detects processes that run external network services (e.g., sshd for SSH or ntpd for NTP).

[0037] From at least the three components above, the honeypot agent creates a model 306 of the target system 302, which it inserts into a honeypot framework 307 to create the honeypot. It also stores the model in a database 308 (which corresponds, for example, to database 206), which it can also use to supplement the model it has created (and ultimately the build for the honeypot 301) if the current model (or honeypot) is either missing a component or has already been built and only some components need to be rebuilt / updated. It can select previous models (or builds) to supplement a current honeypot, for example, based on the similarity of the operating system. The framework 308 creates the honeypot 301 with medium interaction, which imitates the target system 302 and collects data about how attackers 309 might attempt to attack the target system 302.

[0038] In summary, according to various embodiments, a method is provided as described in Fig. 4 shown.

[0039] Fig. 4 shows a flowchart 400 illustrating a method for creating a honeypot for a (given) target system according to one embodiment.

[0040] In 401, a honeypot creation device, which is granted access to the target system (by appropriate control of the target system and / or granting appropriate access rights to the honeypot creation device), • the directory tree of a file system of the target system; • operating system shell commands supported by the operating system; and • processes running on the target system (in operation) (and thus services supported by the target system, since internal processes also exist for these) are determined by accessing the target system.

[0041] In 402, the honeypot creation facility creates a honeypot containing a file system with a copy of the detected directory tree, imitates the detected shell commands, and imitates the execution of the detected processes.

[0042] The procedure of Fig.4 may be performed by one or more computers having one or more data processing units. The term “data processing unit” may be understood as any type of entity that enables the processing of data or signals. The data or signals may, for example, be handled according to at least one (i.e., one or more than one) specific function performed by the data processing unit. A data processing unit may include or be formed from an analog circuit, a digital circuit, a logic circuit, a microprocessor, a microcontroller, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable gate array (FPGA) integrated circuit, or any combination thereof.Any other way of implementing the respective functions described in more detail herein may also be understood as a data processing unit or logic circuit arrangement. One or more of the method steps described in detail herein may be performed (e.g., implemented) by a data processing unit through one or more specific functions performed by the data processing unit.

[0043] According to various embodiments, the method is therefore particularly computer-implemented.

Claims

[1] A method for creating a honeypot (106, 208, 301) for a target system (302, 211), comprising: Determining (401), by a honeypot generating device (104, 201), which is granted access to the target system (302, 211), from - the directory tree of a file system of the target system (302, 211); - operating system shell commands supported by the operating system; and - processes running on the target system (302, 211); by accessing the target system (302, 211); and Creating (402), by the honeypot creation device (104, 201), a honeypot (106, 208, 301) containing a file system with a copy of the detected directory tree, imitating the detected shell commands and imitating the execution of the detected processes. [2] Method according to claim 1, wherein the honeypot generating device (104, 201) checks a secrecy criterion for information determined by it through access to the target system (302, 211) and generates the honeypot (106, 208, 301) in such a way that it does not contain information to be kept secret according to the secrecy criterion, which it determines through access to the target system (302, 211). [3] Method according to claim 1 or 2, wherein the honeypot generating device (104, 201) generates the honeypot (106, 208, 301) in such a way that it imitates the determined shell commands in such a way that their invocation via a network interface of the honeypot (106, 208, 301) is supported, wherein the honeypot (106, 208, 301) supports the shell commands in a form such that they lack functionalities that meet a predetermined risk criterion compared to their implementation on the target system (302, 211). [4] Method according to one of claims 1 to 3, wherein the honeypot generating device (104, 201) determines information about the resource consumption of the detected processes on the target system (302, 211) and generates the honeypot (106, 208, 301) in such a way that it imitates the detected processes in such a way that their resource consumption on the honeypot (106, 208, 301) imitates the resource consumption that they have on the target system (302, 211). [5] Data processing system with a honeypot generating device (104, 201) which is arranged to carry out the method according to one of claims 1 to 4. [6] A computer program comprising instructions which, when executed by a processor, cause the processor to perform 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 a method according to any one of claims 1 to 4.