Login
Introducing Tiny File Manager [WH1Z-Edition], the compact and efficient solution for managing your files and folders with enhanced privacy and security features. Gone are the days of relying on external resources โ I've stripped down the code to its core, making it truly lightweight and perfect for deployment in environments without internet access or outbound connections.
Designed for simplicity and speed, Tiny File Manager [WH1Z-Edition] retains all the essential functionalities you need for storing, uploading, editing, and managing your files directly from your web browser. With a single-file PHP setup, you can effortlessly drop it into any folder on your server and start organizing your files immediately.
What sets Tiny File Manager [WH1Z-Edition] apart is its focus on privacy and security. By removing the reliance on external domains for CSS and JS resources, your data stays localized and protected from potential vulnerabilities or leaks. This makes it an ideal choice for scenarios where data integrity and confidentiality are paramount, including RED TEAMING exercises or restricted server environments.
Download ZIP with latest version from master branch.
Simply transfer the "tinyfilemanager-wh1z.php" file to your web hosting space โ it's as easy as that! Feel free to rename the file to whatever suits your needs best.
The default credentials are as follows: admin/WH1Z@1337 and user/WH1Z123.
:warning: Caution: Before use, it is imperative to establish your own username and password within the $auth_users variable. Passwords are encrypted using password_hash().
โน๏ธ You can generate a new password hash accordingly: Login as Admin -> Click Admin -> Help -> Generate new password hash
:warning: Caution: Use the built-in password generator for your privacy and security. ๐
To enable/disable authentication set $use_auth to true or false.
FreshRSS zip, tar)150+ languages and a selection of 35+ themesPDF/DOC/XLS/PPT/etc. Files up to 25 MB can be previewed using the Google Drive viewerdatatable js for efficient file filtering
A bash script to retrieve user's .plist files on a macOS system and to convert the data inside it to a crackable hash format. (to use with John The Ripper or Hashcat)
Useful for CTFs/Pentesting/Red Teaming on macOS systems.
sudo)sudo ./osx_password_cracker.sh OUTPUT_FILE /path/to/save/.plist
Stealing and Duplicating SYSTEM tokens for fun & profit! We duplicate things, make twin copies, and then ride away.
You have used Metasploit's getsystem and SysInternals PSEXEC for getting system privs, correct? Well, here's a similar standalone version of that...but without the AV issues...at least for now ๏ธ
This tool also enables you to become TrustedInstaller, similar to what Process Hacker/System Informer can do. This functionality is very new and added in the latest code release and binary release as of 8/12/2023!
๏ต๏ฒIf you like this tool and would like to help support me in my efforts improving this solution and others like it, please feel free to hit me up on Patreon! https://patreon.com/G3tSyst3m
quick rundown on commands
Bypass UAC and escalate from medium integrity to high (must be member of local admin group)
Become Trusted Installer!
Duplicate Process Escalation Method
Duplicate Thread Escalation Method
Named Pipes Escalation method
Create Remote Thread injection method
ElevationStation is a privilege escalation tool. It works by borrowing from commonly used escalation techniques involving manipulating/duplicating process and thread tokens.
This was a combined effort between avoiding AV alerts using Metasploit and furthering my research into privilege escalation methods using tokens. In brief: My main goal here was to learn about token management and manipulation, and to effectively bypass AV. I knew there were other tools out there to achieve privilege escalation using token manip but I wanted to learn for myself how it all works.
Looking through the terribly organized code, you'll see I used two primary methods to get SYSTEM so far; stealing a Primary token from a SYSTEM level process, and stealing an Impersonation thread token to convert to a primary token from another SYSTEM level process. That's the general approach at least.
This was another driving force behind furthering my research. Unless one resorts to using named pipes for escalation, or inject a dll into a system level process, I couldn't see an easy way to spawn a SYSTEM shell within the same console AND meet token privilege requirements.
Let me explain...
When using CreateProcessWithToken, it ALWAYS spawns a separate cmd shell. As best that I can tell, this "bug" is unavoidable. It is unfortunate, because CreateProcessWithToken doesn't demand much as far as token privileges are concerned. Yet, if you want a shell with this Windows API you're going to have to resort to dealing with a new SYSTEM shell in a separate window
That leads us to CreateProcessAsUser. I knew this would spawn a shell within the current shell, but I needed to find a way to achieve this without resorting to using a windows service to meet the token privilege requirements, namely:
I found a way around that...stealing tokens from SYSTEM process threads :) We duplicate the thread IMPERSONATION token, set the thread token, and then convert it to primary and then re-run our enable privileges function. This time, the enabling of the two privileges above succeeds and we are presented with a shell within the same console using CreateProcessAsUser. No dll injections, no named pipe impersonations, just token manipulation/duplication.
This has come a long way so far...and I'll keep adding to it and cleaning up the code as time permits me to do so. Thanks for all the support and testing!
sandfly-entropyscan is a utility to quickly scan files or running processes and report on their entropy (measure of randomness) and if they are a Linux/Unix ELF type executable. Some malware for Linux is packed or encrypted and shows very high entropy. This tool can quickly find high entropy executable files and processes which often are malicious.
Entropy is a measure of randomness. For binary data 0.0 is not-random and 8.0 is perfectly random. Good crypto looks like random white noise and will be near 8.0. Good compression removes redundant data making it appear more random than if it was uncompressed and usually will be 7.7 or above.
A lot of malware executables are packed to avoid detection and make reverse engineering harder. Most standard Linux binaries are not packed because they aren't trying to hide what they are. Searching for high entropy files is a good way to find programs that could be malicious just by having these two attributes of high entropy and executable.
Usage of sandfly-entropyscan:
-csv output results in CSV format (filename, path, entropy, elf_file [true|false], MD5, SHA1, SHA256, SHA512)
-delim change the default delimiter for CSV files of "," to one of your choosing ("|", etc.)
-dir string directory name to analyze
-file string full path to a single file to analyze
-proc check running processes (defaults to ELF only check)
-elf only check ELF executables
-entropy float show any file/process with entropy greater than or equal to this value (0.0 min - 8.0 max, defaults 0 to show all files)
-version show version and exit
Search for any file that is executable under /tmp:
sandfly-entropyscan -dir /tmp -elf
Search for high entropy (7.7 and higher) executables (often packed or encrypted) under /var/www:
sandfly-entropyscan -dir /var/www -elf -entropy 7.7
Generates entropy and cryptographic hashes of all running processes in CSV format:
sandfly-entropyscan -proc -csv
Search for any process with an entropy higher than 7.7 indicating it is likely packed or encrypted:
sandfly-entropyscan -proc -entropy 7.7
Generate entropy and cryptographic hash values of all files under /bin and output to CSV format (for instance to save and compare hashes):
sandfly-entropyscan -dir /bin -csv
Scan a directory for all files (ELF or not) with entropy greater than 7.7: (potentially large list of files that are compressed, png, jpg, object files, etc.)
sandfly-entropyscan -dir /path/to/dir -entropy 7.7
Quickly check a file and generate entropy, cryptographic hashes and show if it is executable:
sandfly-entropyscan -file /dev/shm/suspicious_file
Do spot checks on systems you think have a malware issue. Or you can automate the scan so you will get an output if we find something show up that is high entropy in a place you didn't expect. Or simply flag any executable ELF type file that is somewhere strange (e.g. hanging out in /tmp or under a user's HTML directory). For instance:
Did a high entropy binary show up under the system /var/www directory? Could be someone put a malware dropper on your website:
sandfly-entropyscan -dir /var/www -elf -entropy 7.7
Setup a cron task to scan your /tmp, /var/tmp, and /dev/shm directories for any kind of executable file whether it's high entropy or not. Executable files under tmp directories can frequently be a malware dropper.
sandfly-entropyscan -dir /tmp -elf
sandfly-entropyscan -dir /var/tmp -elf
sandfly-entropyscan -dir /dev/shm -elf
Setup another cron or automated security sweep to spot check your systems for highly compressed or encrypted binaries that are running:
sandfly-entropyscan -proc -entropy 7.7
git clone https://github.com/sandflysecurity/sandfly-entropyscan.git
go build
./sandfly-entropyscan
There are a some basic build scripts that build for various platforms. You can use these to build or modify to suit. For Incident Responders, it might be useful to keep pre-compiled binaries ready to go on your investigation box.
build.sh - Build for current OS you're running on when you execute it.
We use a simple method for seeing if a file may be an executable ELF type. We can spot ELF format files for multiple platforms. Even if malware has Intel/AMD, MIPS and Arm dropper binaries we will still be able to spot all of them.
It's possible to flag a legitimate binary that has a high entropy because of how it was compiled, or because it was packed for legitimate reasons. Other files like .zip, .gz, .png, .jpg and such also have very high entropy because they are compressed formats. Compression removes redundancy in a file which makes it appear to be more random and has higher entropy.
On Linux, you may find some kinds of libraries (.so files) get flagged if you scan library directories.
However, it is our experience that executable binaries that also have high entropy are often malicious. This is especially true if you find them in areas where executables normally shouldn't be (such as again tmp or html directories).
The entropy calculation requires reading in all the bytes of the file and tallying them up to get a final number. It can use a lot of CPU and disk I/O, especially on very large file systems or very large files. The program has an internal limit where it won't calculate entropy on any file over 2GB, nor will it try to calculate entropy on any file that is not a regular file type (e.g. won't try to calculate entropy on devices like /dev/zero).
Then we calculate MD5, SHA1, SHA256 and SHA512 hashes. Each of these requires going over the file as well. It's reasonable speed on modern systems, but if you are crawling a very large file system it can take some time to complete.
If you tell the program to only look at ELF files, then the entropy/hash calculations won't happen unless it is an ELF type and this will save a lot of time (e.g. it will ignore massive database files that aren't executable).
If you want to automate this program, it's best to not have it crawl the entire root file system unless you want that specifically. A targeted approach will be faster and more useful for spot checks. Also, use the ELF flag as that will drastically reduce search times by only processing executable file types.
For incident responders, running sandfly-entropyscan against the entire top-level "/" directory may be a good idea just to quickly get a list of likely packed candidates to investigate. This will spike CPU and disk I/O. However, you probably don't care at that point since the box has been mining cryptocurrency for 598 hours anyway by the time the admins noticed.
Again, use the ELF flag to get to the likely problem candidate executables and ignore the noise.
There is a script called scripts/testfiles.sh that will make two files. One will be full of random data and one will not be random at all. When you run the script it will make the files and run sandfly-entropyscan in executable detection mode. You should see two files. One with very high entropy (at or near 8.0) and one full of non-random data that should be at 0.00 for low entropy. Example:
./testfiles.sh
Creating high entropy random executable-like file in current directory.
Creating low entropy executable-like file in current directory.
high.entropy.test, entropy: 8.00, elf: true
low.entropy.test, entropy: 0.00, elf: true
You can also load up the upx utility and compress an executable and see what values it returns.
Sandfly Security produces an agentless endpoint detection and incident response platform (EDR) for Linux. Automated entropy checks are just one of thousands of things we search for to find intruders without loading any software on your Linux endpoints.
Get a free license and learn more below:
https://www.sandflysecurity.com @SandflySecurity
A free, powerful, multi-purpose tool that helps you monitor system resources, debug software and detect malware. Brought to you by Winsider Seminars & Solutions, Inc.
Project Website - Project Downloads
Windows 7 or higher, 32-bit or 64-bit.
Requires Visual Studio (2022 or later).
Execute build_release.cmd located in the build directory to compile the project or load the SystemInformer.sln and Plugins.sln solutions if you prefer building the project using Visual Studio.
You can download the free Visual Studio Community Edition to build the System Informer source code.
See the build readme for more information or if you're having trouble building.
Please use the GitHub issue tracker for reporting problems or suggesting new features.
If you are running System Informer from a USB drive, you may want to save System Informer's settings there as well. To do this, create a blank file named "SystemInformer.exe.settings.xml" in the same directory as SystemInformer.exe. You can do this using Windows Explorer:
Plugins can be configured from Options > Plugins.
If you experience any crashes involving plugins, make sure they are up to date.
Disk and Network information provided by the ExtendedTools plugin is only available when running System Informer with administrative rights.
