67

I found a file in my home directory named "sudo". It's 1.5GB in size and I have no idea where it came from.

-rw-r--r--  1 foo foo 1598296064 Aug  9 11:22 sudo

Does anybody have any tips on how to proceed investigating this file? I fear that my computer may be compromised but I still want to know what I'm dealing with.

Here's what I've done so far:

  • Running file sudo shows `sudo: data'.
  • Running strings sudo showed a large amount of random data.
  • Running which sudo points to the sudo file in /usr/bin/sudo

If it's an executable binary I plan to run it but might transfer to a virtual machine before I do that. I have limited gdb knowledge so at least I can inspect it.

  • Comments are not for extended discussion; this conversation has been moved to chat. – Rory Alsop Aug 31 at 11:17
  • 2
    Note that which sudo does not do anything with the file in the current directory named sudo and will give that result from any folder. It just searches all of your different locations of your path and tells you which one it would use if you ran the sudo command right now. – CR Drost Aug 31 at 13:51
  • Just open it in some "more visual" viewer, like one built into Midnight Commander or something similar and scroll around. Chances are you will recognize output of "botched command" from answer below. – Oleg V. Volkov Sep 1 at 2:39
144

You probably made it by accident with a botched shell command. I've done stuff like that myself. As a result it is probably filled with innocuous data. Here are a few reasons why I would guess it is not malicious:

  1. 1.5 GB would be an extremely large virus. Since viruses are usually transmitted over a network, smaller is better.
  2. It isn't executable.
  3. Malware typically hides much better than this.
  4. file thinks it is just a data file.

Of course none of that proves that it isn't malicious (a.k.a. viruses don't have to be small, just because it isn't executable doesn't mean it might not be part of a malicious payload, and sometimes they don't bother hiding), but I suspect this is harmless. This is probably too old, but I would see if your bash history goes to the day/time in question.

I realize I haven't given you any hints on how to analyze the file, but you've already hit the main helpers (file and strings), and they haven't helped! A file filled with random data from an errant command would explain what you are seeing, and likely has a better chance of generating a file named sudo in your home directory than malware does, IMO.

  • 12
    I mostly agree, except that which will only find executables in directories in $PATH -- which should not include either the home folder or . (the current directory). But in this case, ls -l does show it's not marked as executable. – Gordon Davisson Aug 29 at 2:50
  • 144
    You probably intended to do somecommand | sudo tee -a something and ended up running somecommand > sudo tee -a something – ThoriumBR Aug 29 at 2:56
  • 44
    history | grep "> sudo" – Jeffrey supports Monica Aug 29 at 14:53
  • 100
    @Jeffrey Not to be confused with history | grep > sudo, which would just make the problem worse. – Ray Aug 29 at 19:47
  • 9
    @Ray lol, that cracked me up soooo bad – Conor Mancone Aug 29 at 20:33
25

I'd start with history | grep sudo from the terminal and look at the most recent sudo commands to see if any are malformed.

  • It's your home directory.
  • You haven't said it has special ownership so I'll assume you own it.
  • It's almost certainly a botched shell command, so you probably made it from the terminal.
  • It might be something created by a script but it's pretty rare to put "sudo" commands in a script.
  • It's displaying itself openly and obviously so you probably would have noticed it if you hadn't created recently.
  • 5
    history | grep sudo | wc -l -> 8343 :p – Conor Mancone Aug 29 at 18:16
  • 1
    @ConorMancone I'd suggest "history | grep sudo | tail" but I doubt he needs it. – Dark Matter Aug 29 at 20:19
25

Does anybody have any tips on how to proceed investigating this file?

Since file doesn't recognize the "data" as an executable, it will be difficult to try to analyze dynamically (by running it) unless you can find the proper entry point.

Another standard Linux tool you could try is:

stat

This will give you a little more of the metadata information than what you can see with just the directory listing.

Another tool you could try is:

binwalk

which can provide analysis of binary files like firmware images. For example, if the binary file contains a file system binwalk may recognize it.

Yet another tool freely available on Linux is "The Sleuth Kit." If the binary file happens to be a raw disk image or file system data then you can try to process it with "The Sleuth Kit."

You could also try dropping the binary into IDA (the "Interactive Disassembler" from Hexrays--a freeware version is available) to see if IDA can make sense of it. But if file doesn't recognize it, I'm not too hopeful that IDA will.

  • 2
    I've heard good things about Ghidra (nsa.gov/resources/everyone/ghidra), a pretty good (and open source) binary analyzer. – Peter Cordes Aug 29 at 22:16
  • 1
    Ghidra is another good option. It is freely available and can parse a number of different types of binaries. It may be able to handle some things the IDA Free version can not. The best option would be to use the commercial IDA Pro, but it is quite expensive. – hft Aug 29 at 22:24
11

I think the other answers cover nearly everything already (and have already solved the mystery). One additional thing to try if you are still unsure about deleting it is to do a scream test. You won't necessarily get a resolution as to the source of the file, but you can have some confidence it is safe to remove.

Rename the file to something else and see if anything happens. Some things to look out for are

  1. The file is recreated. That means something recent made it and it might be easier find out what through bash history or logs.
  2. Something crashes. Depending how often programs crash this might be a red herring, but it might also be a hint as to the file's source.

Other methods to do a scream test would be to remove all access permissions so nobody can read or write to the file, or to corrupt the file.

EDIT

As Daniel points out, renaming the file won't work if process still has the file open. If the file is open you can see all open files with lsof, or you can find process id(s) of those processes which have the file open using fuser. ps will then give more information on the processes.

> fuser sudo
/home/bob/sudo:  3132  7070
> ps 3132 7070
  PID TTY      STAT   TIME COMMAND
 3132 ?        R    203:50 pdflatex
 7070 ?        Sl     0:45 evince
  • 1
    Apps with a file handle open will keep the file open through renaming, moves and will not care until it closes the handle. – Daniel Hill Aug 29 at 12:42
  • @DanielHill Good point. lsof | grep sudo to the rescue. Will lsof report the current name of the file or the name of the file when it was opened? – spyr03 Aug 29 at 13:48
  • If something recently created it, why would its modification time be almost 3 weeks ago? – Barmar Aug 29 at 14:16
  • @Barmar I presume this is an accidentally created file that is unused. But there is no reason it couldn't still be held open by the process that made it, if the process is long lived and computer has not been shutdown since. – spyr03 Aug 29 at 14:22
  • I was just questioning whether 3 weeks ago counts as "recently". – Barmar Aug 29 at 14:23
5

You could try "hexdump -C -n 512" to see if anything pops out at you in either the binary or ascii dump. It could be some mix of binary data and text data. Like a wget of a script that you mistyped, the hexdump might allow you to see some of the script.

1

You can also try head and see the first few lines of the file. The first few characters could reveal something about the file type. See magic number for more information.

  • 12
    If the magic number of this file was a well known one, then file would have guessed the file type. – binarym Aug 29 at 14:15
  • 6
    Also, dropping the output of head into your bare terminal on a probably binary file has a high likelihood of screwing up your terminal. Remember that head looks for a certain number of "lines", which it expects to be separated by newline characters. If it doesn't happen to find any newlines in the first hundred MB or so, head doesn't care; it's just going to drop all that output on your terminal, and what are the odds that there aren't any terminal escapes in there that could do things like mess up your command prompt? Low. Instead, try xxd <file> | less. Look at the hex dump. – guenthmonstr Aug 29 at 14:46
  • 7
    @d-b commands to the terminal are transmitted in-line. No amount of "betterness" is going to fix this, because it's the standard. If you dump control codes directly into your terminal then your terminal is rightly going to interpret them. – Score_Under Aug 30 at 8:52
  • 1
    @d-b The most common such issue is with sequences that change the terminal character set, so perhaps the Mac OS terminal does not support character set switching. If you printf '\033(0', it instructs the terminal to change the G0 character set to line drawing characters. If this sequence is in a file you happen to cat, the same thing happens (which is why the "strictly correct" way is to use less or some other utility intended to display files). – Score_Under Aug 31 at 19:42
  • 1
    @Score_Under printf '\033(0' "messed" up my terminal. – d-b Sep 1 at 4:40
0

You could go the plain old straightforward way: installing an antivirus and scanning the file. It's not a perfect solution, but it's a place to start and at least it would give you at least a little peace of mind about it.

I'm actually a bit surprised no one suggested this.

I'm not sure what distro you're on, but I'm sure there are plenty of antivirus solutions that would work. Off the top of my head, I would give ClamAV a try for something like this, seems easy to install.

protected by Rory Alsop Aug 31 at 11:17

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.