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
    Commented Aug 31, 2019 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
    Commented Aug 31, 2019 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. Commented Sep 1, 2019 at 2:39

7 Answers 7


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. Commented Aug 29, 2019 at 2:50
  • 144
    You probably intended to do somecommand | sudo tee -a something and ended up running somecommand > sudo tee -a something
    – ThoriumBR
    Commented Aug 29, 2019 at 2:56
  • 44
    history | grep "> sudo"
    – Jeffrey
    Commented Aug 29, 2019 at 14:53
  • 101
    @Jeffrey Not to be confused with history | grep > sudo, which would just make the problem worse.
    – Ray
    Commented Aug 29, 2019 at 19:47
  • 9
    @Ray lol, that cracked me up soooo bad Commented Aug 29, 2019 at 20:33

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:


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:


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. Commented Aug 29, 2019 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
    Commented Aug 29, 2019 at 22: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.
  • 5
    history | grep sudo | wc -l -> 8343 :p Commented Aug 29, 2019 at 18:16
  • 1
    @ConorMancone I'd suggest "history | grep sudo | tail" but I doubt he needs it. Commented Aug 29, 2019 at 20:19

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.


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
 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. Commented Aug 29, 2019 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
    Commented Aug 29, 2019 at 13:48
  • If something recently created it, why would its modification time be almost 3 weeks ago?
    – Barmar
    Commented Aug 29, 2019 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
    Commented Aug 29, 2019 at 14:22
  • I was just questioning whether 3 weeks ago counts as "recently".
    – Barmar
    Commented Aug 29, 2019 at 14:23

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.


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.


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
    Commented Aug 29, 2019 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. Commented Aug 29, 2019 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. Commented Aug 30, 2019 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). Commented Aug 31, 2019 at 19:42
  • 1
    @Score_Under printf '\033(0' "messed" up my terminal.
    – d-b
    Commented Sep 1, 2019 at 4:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .