Tracing system calls

The strace utility can be used to trace which system calls are being made by a program.

This program works by running a program and keeping track of (tracing) any system calls that are made. Never run this command against an unknown binary on your forensics workstation. Only run this inside a sandbox in a virtual machine or on your dedicated machines for malware investigation described above. In addition to being cautious when running this command, there are a few things that you should keep in mind. First, when you run the program as anyone other than root, it might fail because of permission issues. Second, if command line parameters are required, it might fail, or at least take a different execution path, that can make it hard to see what it does. Third, it may require some libraries not installed in your test environment. If this is the case, you should be able to tell, because you will see system calls attempting to load the libraries. Partial output from running strace against xingyi_bindshell is shown in Figure 10.19.

FIGURE 10.19

Partial output from running strace against xingyi_bindshell in a sandbox virtual machine.

From Figure 10.19 we can see that the C library (/lib/x86_64-linux-gnu/libc.so.6) was opened read-only and the call returned a file handle of 3. The file was read and parts of it were mapped to memory so that some of the functions in the library can be used. Two file handles automatically exist for all programs, 1 and 2, for standard out (stdout) and standard error (stderr), respectively. The call to write(1, “\n”, 1) is the same as calling printf(“\n”) from a C program (which is exactly what this file is). The output from strace, also shows that a pipe was created using popen. Popen stands for pipe open. It is used to execute a command and then open a pipe to get the responses from the command. From the read command that follows a few lines later, it looks like the program is trying to determine the version of Python installed.

Don’t think of strace as the perfect tool to help you understand how a program works. The best way to see what a program does is to trace through it with gdb. Using strace is a good starting place before moving on to gdb. The results of running strace against another Xing Yi Quan binary, xingyi_rootshell, with no command line arguments are shown in Figure 10.20. Note that the program terminated with a “wrong password” message. Rerunning this command with the “sw0rdm4n” password we discovered during static analysis leads to the results shown in Figure 10.21.

FIGURE 10.20

Running strace against xingyi_rootshell without a password.

FIGURE 10.21

Running strace against xingyi_rootshell with the correct password supplied.

If we run strace against xingyi_reverse_shell, it generates an error. If we add the IP address 127.0.0.1 to the command, it succeeds and creates a process listening on port 7777, as shown in Figure 10.22.

FIGURE 10.22

Running strace against xingyi_reverse_shell 127.0.0.1. A process listening on port 7777 is created as confirmed by running nmap.