Classical cyber-attack detection methods, based on signatures and rules demonstrate stagnation and inability to fight the zero-day, advancedpersistent-threat and similar attacks, while anomaly-based detection methods, although were exploited for a number of years, are still characterized by huge numbers of false-positives (valid user or application behavior, that has been classified as intrusion) and ability to work in relatively stable conditions. The progress achieved in recent years in the area of deep learning artificial intelligence techniques provide a potential for renewing the research on the topic and for achieving promising results. Anomaly-based intrusion detection systems (IDS) utilize the ability to learn from a training set of legal and malicious actions. In order to train anomaly-based IDS systems enormous amount of data is required. Majority of available datasets used for IDS training are related to the network-level based intrusion detection, while datasets for host-based intrusion detection system (HIDS), which is becoming extremely important, training are not available or incomplete and lack important features. In this article we propose a method for automated system-level anomaly dataset generation that is to be used in further training of artificial intelligence-based HIDS training. Details for method implementation are also presented and test results discussed.
IDS are systems dedicated for monitoring user and application activity on company
networks and computers and alerting on possible attack attempts. More precise
definition of intrusion detection system is provided by [
IDS can be classified into two types [
The first intrusion detection model was introduced in 1987 [
Signature-based detection is designed to detect known attacks and has a small
number of false-positives. It scans for patterns associated with known attacks against
computer system. Those patterns can be: hardware-related parameters collection
(CPU and RAM usage), cryptographic hash value of rootkit or error log generated by
an attack [
The idea of anomaly-based intrusion detection is predicated on a belief that an
intruder’s behavior is noticeably different from that of a legitimate user and that many
unauthorized actions are detectable. This type of intrusion detection should be
effective against zero-day attacks. Another advantage for this type is that a – detection
algorithm can be tailored for a specific company, network or a user, making it
challenging task for the attacker to select effective and non-detectable intrusion actions.
Numerous machine learning methods of clustering and classification were applied for
anomaly detection [
Many IDS systems usually make use of a hybrid method which combines signature
and anomaly-based techniques. Such combination provides small amount of false
positives for unknown attacks and raises detection rate on known intrusions [
So far NIDS systems are dominating the field. However, HIDS systems are receiving more attention due to the fact that they provide more information about intrusion and can prevent from significant damage as well as offering an additional layer of security. However, HIDS research lack suitable datasets that can be used for evaluating new methods. Therefore, we propose a method for training data generation. The paper contains five main sections: related work of datasets generated to train anomaly-based IDS, the proposed method for new dataset generation description, results description, and conclusions.
Signature-based intrusion detection is showing better results on detecting known
attacks, but it fails to report new and unknown attacks. For that reason anomaly-based
intrusion detection methods are getting more attention [
A key factor in machine learning, which forms a basis for anomaly detection
algorithms, is the quality of data. Most of the recent research on intrusion detection has
been done using DARPA and KDD Cup 99 datasets. So far 42 % KDD cup dataset,
20 % DARPA dataset and 38 % other datasets have been used to verify proposed new
methods for anomaly detection[
Therefore, DARPA-related datasets have a data associated to a network and are
perfect to apply in NIDS research [
The research done in the sphere of anomaly dataset generation for HIDS training is minimal despite the fact of the growing need for anomaly-based HIDS systems.
Some information has been collected during the KDD dataset assembly. At first it
was a UNIX-type host systems information. Later, in January 2000, Windows NT
hosts data was collected on similar circumstances [
Some attempts have been made to generate novel public datasets for the Windows
operating system. Windows audit logs analysis method was introduced and collected
data was prepared for public usage by [
One of the latest datasets related to the host-based intrusion detection is the
ADFAIDS dataset. In an experiment a zero day attack was simulated and system calls in
Windows and Linux operating systems have been collected [
The minimal presence of datasets used for HIDS training, and absence of crucial data parameters in these datasets, encourages creation of a simple and reliable malicious activity dataset generation method. Such method must be easily implementable and not dependent on a specific HIDS system. 3 3.1
The following nonfunctional requirements were formulated for the malicious activity dataset generation method: the system has to be flexible (it must allow adapting new data collection in the future), easy to configure (no special tools must be required to change system parameters), and based on open-source software only. The target operating system for malicious activity collection chosen – was Windows, because it is still the most widely used operating system in the world, although the method can be adapted for any other OS.
For reasons of simplicity and proof of concept, only openly available malware samples were used to generate malicious activity samples. The method can be easily automated: any malware samples can be downloaded, prepared according to the requirements, and used. The proposed method has six following steps: 1. Malware samples preparation. At first, malware must be obtained from available sources. Later, malware of Windows OS executables type should be extracted and added to a separate collection for use. 2. Host machine preparation. Hypervisor must be installed and configured on the selected host machine. Malware samples must be copied to the host machine for later execution. 3. Guest machines preparation. Template for a virtual guest machine must be added and configured on the host machine. Later, the required number of guest machines (copies) should be created for malware execution. Execution of malware samples can be performed in parallel and is dependent on the number of guest machines available. 4. Data collection server preparation. Server storage for the malware execution log information (such as anomaly samples in form of logs, network activity, system calls, etc.) must be prepared. 5. Malware samples execution and data collection. When all machines are prepared – main execution script is started. The main script will upload a malware sample to the target guest machine and will start the operating system. Later, a script on the guest machine will execute malware on OS startup. Malware-generated activity log will be automatically collected and uploaded to the data collection server. 6. Collected data preparation and analysis. When all samples are executed, collected data can be transformed to the XML format and analyzed. 3.2
The proposed method implementation (architecture) can be seen in Fig. 1. The
virtualization technique, based on a free ProxMox hypervisor, was selected to simulate
quest machines that will be used for running malicious actions. ProxMox VE is a
completely open-source platform for enterprise virtualization, a built-in web interface
that allows management of VMs and containers, software-defined storage and
networking, high-availability clustering, and multiple out-of-the-box tools in a single
solution [
A main bash script is executing all commands required to collect data: a guest machine is prepared, started and stopped by that script. The main bash script has only one parameter – a folder that contains prepared malware samples. ProxMox firewall is enabled on the Host machine to manage network flow and minimize the risk of malware propagation. Only one-directional flow to the remote HIDS server was allowed – all other connections were blocked. All data sent to that server was stored on LOG server for later analysis.
An anomaly data collection was done by three tools: Dr. Memory provided system
call tracer for the Windows OS, OSSEC (open source HIDS [
Open malware collections were used to generate malignant activity on guest
machines. Malware execution was conducted on a Windows operating system. For
simplicity reasons, during the first step, only malware of executable type was used, in
order to minimize dependence on third party applications (e.g. office suites, utilities,
viewers or any other). Malware samples were taken from the freely available database
provided by VirusShare [
Usually the first byte of a file is holding information about the file type. If that is already a Windows-executable file – corresponding file extension is added to it and the file is packed to the archive with a password “infected”. If the analyzed file is an archive – it is extracted for further analysis and, if executable files are found, they are added to the password protected archive. All other files are skipped.
Malware transfer to the guest machine was implemented with the help of ProxMox VE, which provided the capability to attach an additional virtual drive and copy the file straight to it. It is not dependent on any other third-party software and firewall configuration has no impact on file transfer.
The number of malware samples that can be executed in parallel, thus influencing the dataset generation speed, depends on the number of running guest machines, that is directly related to the available hardware resources. For our experiments tests were performed on the HP ProLiant DL 380 G6 server with the following specifications: 2x Xeon E5520 CPU, 8 GB of RAM and 4x146 GB HDD’s connected to RAID 5. Six guest machines were running in parallel.
A bash script on the host machine was used to control guest machine’s state (startup and shutdown) and malicious file transfer to the corresponding virtual drive. Virtual drive preparation for the guest machine also was implemented via bash script: it can be mounted on a hypervisor system and updated with required malware file. Main actions performed by the bash script on the host machine are: 1. Copying guest machines disks from prepared templates. 2. Mounting virtual disk for every guest machine, copying prepared malware, unmounting disk. 3. Starting the guest machine. 4. Pausing script for defined time to provide the malware the possibility to reveal all functionality and features. The default pause time in tests was equal to 30 minutes. 5. Stopping the guest machines. The Stop command will halt the machine immediately. Shutdown process is not initiated.
Guest machine images were also prepared. Each guest machine was running Windows 7 OS and Dr. Memory, OSSEC agent and WinDump. A malware execution script was added to the Windows task scheduler. Task scheduler provides all required privileges for an unimpeded application/malware startup. Then defined archive file is extracted, malware is executed by a run command for every executable in the extracted folder. The anomaly data gathered (list of modified/accessed files, system calls with related information and network data) was sent to the LOG server for analysis.
All actions required for implementing malware samples execution are presented in Fig. 3. Malware samples are executed in a batch manner. Every batch has a number of files identical to the number of available guest machines. It can be seen, that host machine waits for the predefined time while a script on guest machine is executing the provided malware sample. This pause is needed to collect anomaly activities in case malware manifests itself after some delay after infecting the machine. 4
A total of 12226 executable malware samples in the form of password protected
archives were prepared from theZoo and VirusShare provided packages and used for
tests. All samples were tested over the period of two months (2017.07-2017.08). No
interruptions or errors related to the malware execution were noticed which is an
advantage against well-known tool for such task - Cuckoo sandbox. According to Miller
et al. – it has stability issues that cause Cuckoo samples results to be inconsistent
between runs [
The collected data has new valuable attributes that can be used to train anomalybased HIDS system properly. It is necessary to stress that as with any ML methods, the anomaly-based IDS trained under dataset generated, will be able to detect malware possessing features that were presented in the dataset.
The performed analysis has shown that there is an increasing requirement for the development and training of anomaly-based HIDS solutions, which is currently being slowed down due to the lack of available and suitable host-level anomaly datasets.
The method for host-level anomaly dataset generation was proposed. The proposed method is based on malware execution in a sterile, isolated virtual machine environment with further anomaly activity collection and data representation in SQLite database format.
The method was implemented and tested only with free or open-source tools and freely available malware samples. The tests performed have proved the method stability and method suitability for host-level anomaly dataset generation. Automated anomaly generation allows flexible training data-set expansion, response to the new attack types and generation of specific on-demand datasets.
Anomaly database of system call traces and other anomaly data was generated for 12226 malware samples. The dataset generated using the method proposed has an advantage against existing datasets because of additional parameters (system call arguments list and return value) that allow more in-depth HIDS training.
An expansion of the generated dataset is being planned for creating a more comprehensive host-level anomalies dataset for HIDS training. The expansion is planned via inclusion of non-executive type malware samples, non-malware attacks and optimizing the pause interval for better feature assembly of delayed malware activities.