In order to ensure to cyber security of an organization, the logs of the systems it owns must be collected, analyzed and repeated continuously. For provide the continuous of the process, monitoring systems can be installed. The fact that what is happening inside is being followed reduces the attack area of the attackers. But it is possible to manipulate the monitoring systems with generating fake logs.
The purpose of generating a fake log may be to the target’s reading of wrong data, not being able to read existing data, disrupt log collection.
The attempt to generate a successful fake log consists of 2 main stages:
- Discover log format
- Log generation
- A device on the network
You can access the SIEM simulation free of charge at Letsdefend.io
Discover Log Format
For the fake logs produced in the attack to be successful, they must be sent in the format used by the target system. For instance, sending a log in CEF format to a system using LEEF log format will cause parsing problem. Methods that can be used to find the format:
Identifying the application
After the application is identified, internet research can be done about the application or install the application and log stream can be monitored.
Monitoring network traffic
If the logs are transferred over the network without encryption, the log format will be determined.
In accordance with the information obtained in the previous stage, fake logs are generated and sent to the target system.
Let’s take an example of an imaginary institution with a simple topology below.
There is a log server in the network that collects logs from clients, it use Splunk product for collect logs. Collected logs are transferred to the monitoring server and correlated, and alarms are generated for analysts to investigate security threats.
Adversary is involved in the network and begins collecting information to find the log format, which is the first stage of the attack. First, the adversary is scanning the target ports.
After scanning, he/she discovering that Splunk is installed in the server. Starting to listen to the network traffic, considering that the open “514” and “1234” ports are used for log collection. Immediately afterwards, he/she sees that TCP packets pass over the “1234” port.
When it comes to the packet details, adversary sees that the communication is not encrypted and by reading the entire content, he/she learns the log format.
Having learned the format, the attacker is getting ready to send the fake logs to the log server by going to the 2nd stage. At this stage, the purposes of fake logs may be different. For example, it may be one of the purposes to send a large number of logs, to fill the data storage area of the server and not to be able to receive new logs, to drop false alarms in front of the analyst with false attack logs, to send a very high number of logs instantly and to delay the processing of logs.
The attacker intends to distract the analyst with unnecessary alarms and prepares a fake log appropriate for the format that shows that the SQL injection attempts are made to the Web server.
192.168.131.23 – – [19/Apr/2020:11:33:23 -0700] “GET /read.php?id=1%27%20UNION%20ALL%20SELECT%20LOAD_FILE(%27/etc/passwd%27) HTTP/1.1” 404 208 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36”
Adversary prepares various logs similar to the above and sends them to the “1234” port of the log server.
When searching from the splunk interface, we can see the log is processed.
Precautions That Can Be Taken
- Applying Whitelist and connecting only the addresses with permission to the log server
- Alert on abnormal increases / decreases by monitoring instant log flow values
- Encrypted log transfer