# Hacktor

The Hacktor is a software component that can be installed in a specific network segment to perform penetration tests on accessible assets.

<figure><img src="/files/sT3mvXkx7gjA5tJLMJ76" alt=""><figcaption></figcaption></figure>

{% hint style="warning" %}
Keep the Hacktor software component up to date and [perform updates regularly](#update-hacktor).
{% endhint %}

## Create Hacktor

{% hint style="danger" %}
If you want to **add a Hacktor container**, it is necessary that you log in on each machine via `docker loginregistry.enginsight.com`. \
This means that the access data must be entered and saved on several machines. \
In the case of password rotation, these access data must be updated accordingly everywhere! \
Further information on the secure storage of access data can be found [**here**](https://docs.docker.com/reference/cli/docker/login/#credential-stores).
{% endhint %}

To add a hacktor just press the 'Create Hacktor' button and run the source code with root privileges on a linux powered server or computer.

{% hint style="warning" %}
The host on which the hacktor is installed must be able to communicate with the target systems. If necessary, check your firewall settings and set Hacktor to an [IDS whitelist](/docs/manual/english/operation/platform/legacy/hosts-agent-pulsar/intrusion-detection-system.md#whitelist).
{% endhint %}

<figure><img src="/files/bLl0whEfAcSzDc86omap" alt=""><figcaption></figcaption></figure>

## Configuring the Hacktor

Click on the desired hacktor in the list to configure it according to your requirements.

<figure><img src="/files/nHj24T1FC0UuYXG8yk1h" alt=""><figcaption></figcaption></figure>

### Number of targets scanned in parallel

By default, two target systems are processed in parallel. However, if your system on which Hacktor is installed has sufficient resources, you can increase the default value. This is especially recommended if you want to pentest large IT infrastructures. This will reduce the time required for the pentest.

### Timeout per target in minutes

Use the timeout value to define when a pentest **on a single target system** should be aborted. To do this, you specify the minutes that the scan may take per target system. You can still view the results collected up to the time of abort in the audit report, and the target system is given the status timeout.

High timeout settings potentially cause pentests to take longer. However, they ensure that no results are lost. The default 180 minutes is a compromise that you can vary according to your needs.

### Frequency

You can set the frequency with which the penetration test is executed. The frequency depends on the resources available on the network. A higher frequency means shorter timeouts and more requests. This will significantly reduce the time the pentest takes. However, if a too high frequency is chosen, which overloads the tested systems, results can be lost.

In details the frequency settings have the following effects:

|                                | LOW   | MEDIUM  | HIGH  |
| ------------------------------ | ----- | ------- | ----- |
| Minimum RTT Timeout            | 100ms | 100ms   | 50ms  |
| Maximum RTT Timeout            | 10s   | 1,250ms | 300ms |
| Maximum connection attempts    | 10ms  | 6ms     | 2ms   |
| Maximum TCP scan delay         | 1s    | 10ms    | 5ms   |
| Maximum UDP scan delay         | 1s    | 1s      | 1s    |
| Timeout per target (Port Scan) | ---   | ---     | 15min |

### Port Range

Manually set the port range to be targeted by the attacked assets. By default, the 3500 most commonly used ports are scanned and tested. You can specify individual ports as a row or a sequence. Alternatively you can combine both variants or define a different number of frequently used ports.

Use the following syntax:

| **SYNTAX**                              | **Example**     | **Description**                                                |
| --------------------------------------- | --------------- | -------------------------------------------------------------- |
| TOP\_PORTS:\[number]                    | TOP\_PORTS:3500 | Steuere eine bestimmte Anzahl von häufig verwendeten Ports an. |
| \[number],\[number],\[number],\[number] | 21,22,80,443    | Enter your manually defined ports in a row.                    |
| \[number]-\[number]                     | 1-65535         | Enter your manually defined ports in a sequence.               |
| \[number],\[number]-\[number]           | 21-22,80-433    | Combine series and sequence.                                   |

## Update Hacktor

The Enginsight Hacktor is continuously updated by us. In order for all (new) functions to work as desired, it is necessary that you always keep the watchdog up to date.

1. Go to Penetration Testing → Hacktors and check if all version numbers are up to date. A warning will be given to you if an outdated version is installed.
2. If an Hacktor does not have the current version number, click the Update button in the right column at Actions.

The current version number [can always be found here.](/docs/manual/english/technical-details/version-numbers.md)

## Get logs

### Reading logs

Depending on your operating system, there are different ways to retrieve the current logs of the Hacktor software component.

### **Debian 12 and later versions**

Starting with Debian 12, system logs are managed by journalctl by default. The logs of the Enginsight components are therefore no longer located in the traditional log files.

**Display logs:**

```
sudo journalctl -u ngs-hacktor -n 50
```

**Save logs:**

```
sudo journalctl -u ngs-hacktor -n 50 > /tmp/hacktor.log
```

### Older Debian versions and CentOS

On older systems, logs are still managed via the classic log files.

*Debian:*

```
cat /var/log/syslog | grep -a hacktor-m24 > /tmp/<DATEINAME>.txt
```

*CentOS:*

```
cat /var/log/messages | grep -a hacktor-m24 > /tmp/<DATEINAME>.txt
```

{% hint style="info" %}
How far back the logs go also depends on the configuration and the load of the server.
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.enginsight.com/docs/manual/english/operation/platform/penetration-testing/hacktor.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
