Check if executable may try to connect to the internet

Question

I'm writing a simple anti-malware for my end of year school project. I've got some basics nailed down but I would like to add a feature that checks an executable to see if it may attempt to connect to the internet.

Which way should I approach this? Looking at the hex of a program written in C I can see that the libraries included are shown in plain text. Should I look for librairies like socket.h ? Is this reliable?

Note that I'm a second year ethical hacking student so I'm not expected to produce something that rivals professional AV software.

Also I'm programming my AV in Python and demonstrating it under Linux.

Answer 1

I don't think you'll be able to see if socket.h was included, and the relevant functions are in libc, so they will always be available to the application. I would try to see if the application actually calls those functions.

A simple way (in shell) to check if an executable directly calls socket functions:

objdump -D `which wget` | grep '<\(accept\|bind\|connect\|getpeername\|getsockname\|getsockopt\|listen\|recv\|recvfrom\|recvmsg\|send\|sendmsg\|sendto\|setsockopt\|shutdown\|socket\|socketpair\)@'

objdump -D disassembles the executable (including data sections, in case some malicious executable is using some trickery), then grep checks for any calls to the libc functions prototyped in socket.h.

But that only works if the executable itself directly calls the socket functions, which is not always the case. Replace wget with curl and you'll get no results. The reason is that curl's network functionality is all within libcurl.

So, next step: look at the libraries.

ldd `which curl`

Actually, this could be your first step even. If the executable is linked to some obvious networking libraries (i.e. libssl.so.1.0.0), you could stop here. But assuming it isn't, you now have the list of dynamic libraries loaded by the executable. You can use objdump -D on those as well. And disassembling /usr/lib/x86_64-linux-gnu/libcurl.so.4 shows that the library does indeed call the socket functions.

Hopefully this gives you a decent starting point. Besides the tediousness (though that's mitigated by the fact that you're going to write code to do this for you), there is also the issue that ANY external function named the same as the socket functions will show up using my command line. That shouldn't be a big deal if you're ok with erring on the side of false-positives, but there might be a better way to check the functions.

EDIT: This may not work on all binaries. grep finds those function names directly in the executable, which I didn't expect on the distributed wget and curl in Ubuntu.

Answer 2

What you're talking about is a form of Signature Scanning.

You will compare code to known malicious code signatures and see if the code is included in the rogue application.

Say this is a line of code that is known as malicious and compiles to a certain signature that is also know:

Send IP address to hacker

HEX OF

 00105e0 e6b0 343b 9c74 0804 e7bc 0804 e7d5 0804
 00105f0 e7e4 0804 e6b0 0804 e7f0 0804 e7ff 0804
 0010600 e80b 0804 e81a 0804 e6b0 0804 e6b0 0804

Your program could then search the hex of files in an attempt to locate known malicious signatures.

Something more likely you could accomplish in a short amount of time is what is called:

Behavioral Blocking

Think of things a virus or malicious code might try to do to your system, and watch for it. The previous code pretends to connect out and send an IP address somewhere. Much like a firewall, you can watch for the attempted connection OUT to be established and alert the user.

You can also monitor for files that are NOT normally modified or accessed to have such happen.