Cover your tracks during Linux Exploitation by leaving zero traces on system logs and filesystem timestamps. 👻🐚

Last update: Jan 6, 2023

Related tags

Overview

`moonwalk`

Cover your tracks during Linux Exploitation / Penetration Testing by leaving zero traces on system logs and filesystem timestamps.

ℹ️ Introduction

moonwalk is a 400 KB single-binary executable that can clear your traces while penetration testing a Unix machine. It saves the state of system logs pre-exploitation and reverts that state including the filesystem timestamps post-exploitation leaving zero traces of a ghost in the shell.

⚠️ NOTE: This tool is open-sourced to assist solely in Red Team operations and in no means is the author liable for repercussions caused by any prohibited use of this tool. Only make use of this in a machine you have permission to test.

Features

Small Executable: Get started quickly with a curl fetch to your target machine.
Fast: Performs all session commands including logging, trace clearing, and filesystem operations in under 5 milliseconds.
Reconnaissance: To save the state of system logs, moonwalk finds a world-writable path and saves the session under a dot directory which is removed upon ending the session.
Shell History: Instead of clearing the whole history file, moonwalk reverts it back to how it was including the invokation of moonwalk.
Filesystem Timestamps: Hide from the Blue Team by reverting the access/modify timestamps of files back to how it was using the GET command.

Installation

$ curl -L https://github.com/mufeedvh/moonwalk/releases/download/v1.0.0/moonwalk_linux -o moonwalk

Download the executable from Releases OR Install with cargo:

$ cargo install --git https://github.com/mufeedvh/moonwalk.git

Install Rust/Cargo

Build From Source

Prerequisites:

Git
Rust
Cargo (Automatically installed when installing Rust)
A C linker (Only for Linux, generally comes pre-installed)

$ git clone https://github.com/mufeedvh/moonwalk.git
$ cd moonwalk/
$ cargo build --release

The first command clones this repository into your local machine and the last two commands enters the directory and builds the source in release mode.

Usage

Once you get a shell into the target Unix machine, start a moonwalk session by running this command:

$ moonwalk start

While you're doing recon/exploitation and messing with any files, get the touch timestamp command of a file beforehand to revert it back after you've accessed/modified it:

$ moonwalk get ~/.bash_history

Post-exploitation, clear your traces and close the session with this command:

$ moonwalk finish

That's it!

Contribution

Ways to contribute:

Suggest a feature
Report a bug
Fix something and open a pull request
Help me document the code
Spread the word
Find something I missed which leaves any trace!

License

Licensed under the MIT License, see LICENSE for more information.

Liked the project?

Support the author by buying him a coffee!

Support this project by starring ⭐ , sharing 📲 , and contributing 👩‍💻 ! ❤️

Comments

Fix the parsing of the timestamps

The timestamps of creation, access and modification were parsed based on the raw output of the "/bin/stat" command. This parsing was dependant of the text in the output, like the "Access" word. On non-English systems this parsing didn't work and the "touch" command didn't show the timestamps.

The parameter "--printf='%w\n%x\n%y'" has been added to the "/bin/stat" command so we only get the timestamps of creation, access and modification. It simplifies the parsing rules and make the parsing language-agnostic.

It's the same as in #5 except this time the order is valid in parsing.

opened by nalysius 6

Crash when using start

moonwalk crashes when I try to use start subcommand (other also subcommand btw).

I have tried all the installation way provided in the README, nothing change.

Here is the output of the command:

$ moonwalk start
thread 'main' panicked at 'failed to execute child process: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/core/recon.rs:10:10
stack backtrace:
   0:     0x5556628d9ebc - <unknown>
   1:     0x55566289ebfc - <unknown>
   2:     0x5556628dba6f - <unknown>
   3:     0x5556628db09f - <unknown>
   4:     0x5556628da524 - <unknown>
   5:     0x5556628db01d - <unknown>
   6:     0x555662893521 - <unknown>
   7:     0x555662893613 - <unknown>
   8:     0x5556628aa0fb - <unknown>
   9:     0x5556628adce0 - <unknown>
  10:     0x5556628b422b - <unknown>
  11:     0x555662894c6c - <unknown>
  12:     0x5556628b2483 - <unknown>
  13:     0x5556628a93f3 - <unknown>
  14:     0x5556628b3d36 - <unknown>
  15:     0x7fd44b532bf7 - __libc_start_main
                               at /build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
  16:     0x55566289682e - <unknown>
  17:                0x0 - <unknown>
Aborted (core dumped)

bug

opened by ariary 5

Fix the parsing of the timestamps

The timestamps of creation, access and modification were parsed based on the raw output of the "/bin/stat" command. This parsing was dependant of the text in the output, like the "Access" word. On non-English systems this parsing didn't work and the "touch" command didn't show the timestamps.

The parameter "--printf='%w\n%x\n%y'" has been added to the "/bin/stat" command so we only get the timestamps of creation, modification and access. It simplifies the parsing rules and make the parsing language-agnostic.

opened by nalysius 3

Does not seem to delete .zsh_history

With last version, it seems that my .zsh_history was not clean as expected

Step to reproduce

$ #in zsh
$ sudo moonwalk start
$ echo "in moonwalk"
$ sudo moonwalk finish

Then :

$ history # or cat ~/.zsh_history
[...]
 1054  sudo moonwalk start
 1055  echo "in moonwalk"
 1056  sudo moonwalk finish

is it not the expectedbehaviour right?

opened by ariary 3

crash on finish

I'm seeing this crash on moonwalk finish using the latest:

error: Utf8Error { valid_up_to: 16527, error_len: Some(1) } }', src/core/clear.rs:34:15
stack backtrace:
   0:     0x56158421f44c - std::backtrace_rs::backtrace::libunwind::trace::he79a6b2087577c89
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x56158421f44c - std::backtrace_rs::backtrace::trace_unsynchronized::h9277c4233029dddb
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x56158421f44c - std::sys_common::backtrace::_print_fmt::hbb2b612ef9b02ca8
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x56158421f44c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hc8c6e5fc9f07659b
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x5615841e439c - core::fmt::write::h72801a82c94e6ff1
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/core/src/fmt/mod.rs:1149:17
   5:     0x561584220f1a - std::io::Write::write_fmt::h49956859070326a8
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/io/mod.rs:1660:15
   6:     0x561584220f1a - std::sys_common::backtrace::_print::h7c949d00e447ca1b
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x561584220f1a - std::sys_common::backtrace::print::hac5d7b208ff86b2e
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x561584220f1a - std::panicking::default_hook::{{closure}}::h2d5b8c951b73433e
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:211:50
   9:     0x561584220f1a - std::panicking::default_hook::hc1d5a882e94ba293
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:228:9
  10:     0x561584220f1a - std::panicking::rust_panic_with_hook::hc9dd570d8cf7aba9
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:606:17
  11:     0x56158422046f - std::panicking::begin_panic_handler::{{closure}}::hf5dee398c82a5cad
  12:     0x56158421fab4 - std::sys_common::backtrace::__rust_end_short_backtrace::hc6e01318a754dc4c
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/sys_common/backtrace.rs:139:18
  13:     0x5615842203ed - rust_begin_unwind
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:498:5
  14:     0x5615841d9521 - core::panicking::panic_fmt::h7b8580d81fcbbacd
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/core/src/panicking.rs:107:14
  15:     0x5615841d9613 - core::result::unwrap_failed::h885d3f7beb571353
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/core/src/result.rs:1661:5
  16:     0x5615841f4f00 - moonwalk::core::clear::clear_me_from_history::h38035a5b95404389
  17:     0x5615841f9c3c - moonwalk::start::init::h5a36c6e6fc465eb6
  18:     0x5615841eec53 - std::sys_common::backtrace::__rust_begin_short_backtrace::ha39658a6b03ed62d
  19:     0x5615841eec6d - std::rt::lang_start::{{closure}}::h0ef3ca2fc82345bf
  20:     0x56158421eddd - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h6c750193e4920652
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/core/src/ops/function.rs:259:13
  21:     0x56158421eddd - std::panicking::try::do_call::h02274dfcd9faf3ac
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:406:40
  22:     0x56158421eddd - std::panicking::try::h6804f9d41b571054
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:370:19
  23:     0x56158421eddd - std::panic::catch_unwind::hd51f6164bf3938ec
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panic.rs:133:14
  24:     0x56158421eddd - std::rt::lang_start_internal::{{closure}}::h9b7eb891d44cd5c3
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/rt.rs:128:48
  25:     0x56158421eddd - std::panicking::try::do_call::haf8d551523bae443
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:406:40
  26:     0x56158421eddd - std::panicking::try::h7a438e992ba8b1cc
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panicking.rs:370:19
  27:     0x56158421eddd - std::panic::catch_unwind::h759691315e97e81b
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/panic.rs:133:14
  28:     0x56158421eddd - std::rt::lang_start_internal::hff5980633344c2a1
                               at /rustc/c5ecc157043ba413568b09292001a4a74b541a4e/library/std/src/rt.rs:128:20
  29:     0x5615841fa0b2 - main
  30:     0x7fb6bd9c2d0a - __libc_start_main
                               at ./csu/../csu/libc-start.c:308:16
  31:     0x5615841dbdda - _start
  32:                0x0 - <unknown>

opened by jpegleg 2

Use the dates instead of timestamps in touch

When the user gets a file using Moonwalk, the program gives it the command to reset the timestamps of creation, modification and access to their previous values.

When using the timestamps, the precision is no more than seconds, so in the stat command the dates end with "000000000" for nanoseconds. It is a hint that the timestamps have been changed.

To avoid this issue, the raw dates as returned by the stat command are used now. This way, they can be given to the touch command and the exact same date is reset.

opened by nalysius 1
[ENHANCEMENT] - One Moonwalk for clearing traces on all OS

Hello! Currently I see that moonwalk can be used only on a Linux or Darwin target machine and they seem to be two different executables in the Release section.

Is it possible to have one single executable that is able to identify alone the OS or by an argument provided by the user (i.e., --os linux) and it clears all logs?

And mostly, is it possible to be compatible it for Windows target machines?

opened by D3vil0p3r 0
Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }

hello.. it seem moonwalk get is broken

$ ./moonwalk start
[INFO] Found /dev/shm/.MOONWALK as world writable. [INFO] Set /dev/shm/.MOONWALK as the logging directory [SKIPPED] Logging /var/log/messages requires sudo privileges. [SKIPPED] Logging /var/log/auth.log requires sudo privileges. [SKIPPED] Logging /var/log/kern.log requires sudo privileges. [SKIPPED] Logging /var/log/boot.log requires sudo privileges. [SKIPPED] Logging /var/log/lighttpd requires sudo privileges. [SUCCESS] Saved the current log states.

$ /tmp/moon  ./moonwalk get nolog.txt

[>] To restore the access/modify timestamp of this file, use command ↓

$ touch -a -d '2022-10-08 12:33:26.379565377 +0800' -m -d '2022-10-08 12:33:26.379565377 +0800' nolog.txt

$ /tmp/moon  ./moonwalk finish
Error: Os { code: 2, kind: NotFound, message: "No such file or directory" }

opened by w3xsense 3

Does not clear tracks with bash debug traps

moonwalk does not seem to clear track in bash session when it used in bash session which contains trap with DEBUG mode

Step to reproduce

Put the command logger in ~/.bashrc:

#!/bin/sh
debug_poc() {
  echo "$USER($UID:$GROUPS) ran $BASH_COMMAND" >> /tmp/commands.log
}
trap debug_poc DEBUG

And try moonwalk in a bash session:

$ sudo moonwalk start
$ echo "in mw"
$ sudo moonwalk finish

Now let's see if our tracks were cleared:

$ cat /tmp/commands.log
kali(1000:1000) ran sudo moonwalk start
kali(1000:1000) ran echo "in mw"
kali(1000:1000) ran sudo moonwalk finish

enhancement

opened by ariary 4

Releases(v1.0.0)

v1.0.0(Dec 19, 2021)

v1.0.0 Release.
Source code(tar.gz)
Source code(zip)
moonwalk_darwin(449.75 KB)
moonwalk_linux(478.58 KB)

Owner

Mufeed VH

GitHub

Rapidly Search and Hunt through Windows Event Logs

Rapidly Search and Hunt through Windows Event Logs Chainsaw provides a powerful ‘first-response’ capability to quickly identify threats within Windows

1.8k Dec 28, 2022

Adds zero-cost stack overflow protection to your embedded programs

flip-link adds zero-cost stack overflow protection to your embedded programs The problem Bare metal Rust programs may not be memory safe in presence o

151 Dec 29, 2022

Advanced Fuzzing Library - Slot your Fuzzer together in Rust! Scales across cores and machines. For Windows, Android, MacOS, Linux, no_std, ...

LibAFL, the fuzzer library. Advanced Fuzzing Library - Slot your own fuzzers together and extend their features using Rust. LibAFL is written and main