It is believed that the number of malicious files under a specific platform primarily depends on the popularity of this platform. This is often explained by the fact that there are hundreds of thousands of malware for Windows and very few for Linux. But the time goes on and Linux becomes more popular. There are more and more messages in the news that another large organization or even some municipal service started using Linux. Probably, the era of viruses running under this operating system is coming soon too. A reasonable question appeared: "Are we ready for this?" There are many excellent tools to deal with malware running under Windows: RootKit Unhooker, FileMon, RegMon, ProcessExplorer, GMER... The enumeration may last too long. But how many of these utilities do you know for Linux? And how many of them did you use at least once? Unfortunately, despite the fact that I'm engaged in anti-virus analytics for quite a long time I haven't accumulated knowledge in this area, because it wasn't necessary for me. So, I'd like to fill this gap now.
Let's start the story with a utility that can replace FileMon, and even excel it. The utility is called "strace". You can try it in any Linux distro. My examples are traditionally done in Ubuntu Linux.
So, we begin simply typing "strace" command in a terminal:
In response we receive a brief instruction about utility usage and accessible command line arguments.
One of the meanings of the word "trace", as you know, is "to follow or to watch somebody or something". What should we follow? An executable. The easiest way to understand it - look at an example. In order to do this, we take a simple command called "echo". The command is an executable file (you can check it in "/bin" folder). Type the following command in the terminal:
Doing this we get the following response: "Hello av-school" and a lot of strange text:
To make the output clearer, let's specify the command line switch "-o" and a filename to store the output log:
Now only the "Hello av-school" message is printed on the screen but the rest output is stored in the logfile,
Now take a look at the logfile thoughtfully.
These are system calls produced by the "echo" command:
execve - executing
brk - change data segment size
access - check real user's permissions for a file
mmap2 - map files or devices into memory
open - open a file or device
fstat64 - get file status
close - close file
read - read data from file
set_thread_area - set a Thread Local Storage (TLS) area
mprotect - set protection on a region of memory
munmap - unmap files or devices into memory
write - write to a file
exit_group - exit all threads in a process
If we compare to FileMon, we are primarily interested in the calls to "open", "write" and "read" in a less degree.
Let's start with "open". Which files are accessed?
Also there are mentions of
But these files don't exist - "No such file or directory".
The files with the extension ".so" - are libraries, which are similar to usual Windows ".dll". ld.so is a dynamic linker. libc.so.6 is a standard C library for the GNU operating system. These libraries will be encountered when running any Linux programs.
locale-archive is an archive file containing all locales in your system.
Now let's turn to the "write" command. In this simple case it occurs only once:
The parameters of this call are "1", "Hello av-school\n", and "16". "1" is a file descriptor which will be recorded. In this case, it is a pointer to the standard input/output stream, i.e. the output will be sent to a console instead of a file. The string "Hello av-school\n" does not cause any problems, it is what you want to print. Note the automatically added newline symbol. "16" is a number of bytes that you want to print. If we wrote:
then there would be 20. Number 16 after the equals sign is a value returned by a system call. It is none other than a number of bytes successfully written to the file.
Let's see what will be the difference between output to the console and writting to the file. Let's type the command:
Here we start "nano", a tiny console text editor, instead of the "echo" command. Its interface is very ascetic, but it allows prompt editing of some configuration files if there are no more powerful editors (for example, after a major kernel update X-server is down and it is unable to use GUI mode). It looks like this:
Let's write a simple test message "test text", and press "ctrl + x" to exit. Upon a request of the program, we provide a name for the file which will store the text. After that the program exits.
But we are interested in the contents of the log. At this time the log has a size greater than 40 KB and it is too long to show at a screenshot. We choose the part which is only interesting for us:
What's happening here? We see the events at the following order: checking a status of the file "test.txt", setting a file mode creation mask, and opening the file. Pay attention: the "open" function returns "3" (after the equals sign). This is none other than a descriptor of the newly created file called "test.txt". Then comes a series of insignificant calls, and, finally, the following entry:
This entry denotes storing the text "test text\n", which size is 10 bytes, to the file with descriptor "3" (i.e. test.txt). The returning value is a number of successful bytes written. It is 10 too, it means that everything went well,
Then the file with descriptor "3" is being closed:
The returning value is "0" - no errors.
That's such a wonderful tool. The absence of a graphical interface is a drawback for an ordinary user, but not for a malware analyst. While using FileMon, it was necessary to store output to a log file and then parse it separately, as it was often so large so it was difficult to analyze it with eyes.
Well, we have only to wait for malicious programs for Linux.
) 
