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.

AccidentalRebel
  • 603
  • 1
  • 5
  • 7
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/98125/discussion-on-question-by-karlo-licudine-how-to-investigate-an-unknown-1-5gb-fil). – Rory Alsop Aug 31 '19 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 '19 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 01 '19 at 02:39

7 Answers7

142

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.

StanOverflow
  • 109
  • 2
Conor Mancone
  • 30,380
  • 13
  • 92
  • 98
  • 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 '19 at 02:50
  • 144
    You probably intended to do `somecommand | sudo tee -a something` and ended up running `somecommand > sudo tee -a something` – ThoriumBR Aug 29 '19 at 02:56
  • 2
    @ThoriumBR that makes sense. Can't remember if I did do something like that though, but it's a possibility. I tried searching my bash history as suggested by ConorMancone but it doesn't go as far. – AccidentalRebel Aug 29 '19 at 04:19
  • 7
    @KarloLicudine You should be able to check your command history if this was recent. – James Aug 29 '19 at 09:22
  • 2
    @GordonDavisson, thanks, you're correct about the fact that `which` is not helpful here. – Conor Mancone Aug 29 '19 at 10:09
  • 6
    It doesn't even have to be your fault. After running one of the provided scripts, my overpass folder contains the following empty directories: "2", "file", "File_Error", "No", "or", and "such". – Fax Aug 29 '19 at 12:12
  • 1
    @James It was apparently 3 weeks ago, look at the modification time. – Barmar Aug 29 '19 at 14:14
  • 44
    history | grep "> sudo" – Jeffrey Aug 29 '19 at 14:53
  • 101
    @Jeffrey Not to be confused with history | grep > sudo, which would just make the problem worse. – Ray Aug 29 '19 at 19:47
  • 9
    @Ray lol, that cracked me up soooo bad – Conor Mancone Aug 29 '19 at 20:33
  • 7
    Fortunately `history | grep > sudo` wouldn't actually work because `grep` won't run without a search term, but I'm going to run with it. The next time I see someone run a command without sudo, but which requires root permissions, I'm just going to suggest they run `history | sudo` as a quick fix... MUWAHAHA – Conor Mancone Aug 29 '19 at 20:37
  • 4
    @Jeffrey: Assuming they're using a shell like bash configured normally, control-r for interactive reverse-search. It's a simple text search so you can use a string like `> sudo`. If you're using grep you might want to search for `>.*sudo` to find variable amounts of whitespace. – Peter Cordes Aug 29 '19 at 22:14
  • 1
    After trying out all suggestions from everyone I now believe that it may have really been a botched command. I can't remember exactly what I did it is not farfetched considering the activities I've done with my machine recently. – AccidentalRebel Aug 30 '19 at 06:36
  • 4
    @Ray `history | grep > sudo` seems like a terrible idea. Better to do `history | grep >> sudo`. Then, at least you're not erasing the previous contents of the file you want to analyze... :-) – Alderath Aug 30 '19 at 09:24
  • 1
    @Alderath That's going to be more fun the more you try it. – Mast Aug 30 '19 at 10:29
  • 2
    @ConorMancone It will truncate the file though, making this un-investigatable – Izkata Aug 30 '19 at 15:20
  • 1
    @Izkata what will truncate what file? – Conor Mancone Aug 30 '19 at 16:28
  • 2
    @ConorMancone In your prior comment about grep not running without a search term, it's the shell that does the output redirection and `>` truncates the file whether or not grep errors out – Izkata Aug 30 '19 at 19:21
  • 1
    @Alderath I *did* say it'd make the problem worse. :-) – Ray Aug 30 '19 at 21:08
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.

Rory Alsop
  • 61,474
  • 12
  • 117
  • 321
hft
  • 4,940
  • 17
  • 32
  • 2
    I've heard good things about Ghidra (https://www.nsa.gov/resources/everyone/ghidra/), a pretty good (and open source) binary analyzer. – Peter Cordes Aug 29 '19 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 '19 at 22:24
24

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.
Dark Matter
  • 341
  • 2
  • 3
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
spyr03
  • 211
  • 1
  • 6
  • 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 '19 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 '19 at 13:48
  • If something recently created it, why would its modification time be almost 3 weeks ago? – Barmar Aug 29 '19 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 '19 at 14:22
  • I was just questioning whether 3 weeks ago counts as "recently". – Barmar Aug 29 '19 at 14:23
  • I think you misunderstand. If another file also called sudo is created after the original is "deleted" (which is what I mean by recreated) then that would be the recently created file to investigate. – spyr03 Aug 29 '19 at 14:26
  • Renaming it didn't do anything noticeable. Which means it's not anything particularly important? – AccidentalRebel Aug 30 '19 at 06:33
  • Changing permissions is only as effective as renaming - it won't affect any open file descriptors, only new attempts to open the file. You ought to be able to use `lsof` to identify those, though. – Toby Speight Aug 30 '19 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.

Sam
  • 226
  • 1
  • 3
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.

Radu Murzea
  • 149
  • 6
-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.

d-b
  • 489
  • 2
  • 11
  • 12
    If the magic number of this file was a well known one, then file would have guessed the file type. – binarym Aug 29 '19 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 | less`. Look at the hex dump. – guenthmonstr Aug 29 '19 at 14:46
  • You can use head with a char count too, for binaries. – mckenzm Aug 30 '19 at 03:56
  • @guenthmonstr Terminals getting screwed up was something I experienced in the 90s. Get a better client. – d-b Aug 30 '19 at 04:52
  • 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 '19 at 08:52
  • @Score_Under I haven't dug into this but when I used Digital Unix with CDE in the 90s terminals were constantly messed up while this never happens in the Mac OS X terminal. – d-b Aug 30 '19 at 14:43
  • 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 '19 at 19:42
  • 1
    @Score_Under printf '\033(0' "messed" up my terminal. – d-b Sep 01 '19 at 04:40