RastLeak Tool To Automatic Leak Information Using Hacking With Search Engine

RastLeak: Tool to automatic leak information using Hacking with Search Engines

How to install

Install requirements with:

pip install -r requirements.txt

#How to use:

python rastleak.py

The last stable version is rastleak.py

$python rastleak.py -h

Usage: rastleak.py [-h] -d DOMAIN -o OPTION -n SEARCH -e EXT [-f EXPORT]

This script searchs files indexed in the main searches of a domain to detect a possible leak information

Optional Arguments:

-h, --help show this help message and exit

-d DOMAIN, --domain DOMAIN


The domain which it wants to search

-o OPTION, --option OPTION

                    Indicate the option of search
                  
                     1.Searching leak information into the target
                     2.Searching leak information outside target

-n SEARCH, --search SEARCH

                    Indicate the number of the search which you want to do

-e EXT, --ext EXT Indicate the option of display:

                     1-Searching the domains where these files are found
                     2-Searching ofimatic files

-f EXPORT, --export EXPORT

                    Indicate the type of format to export results.
                  
                     1.json (by default)
                     2.xlsx              

Download RastLeak

PyREBox A Python Scriptable Reverse Engineering Sandbox

Python scriptable Reverse Engineering Sandbox, a Virtual Machine instrumentation and inspection framework based on QEMU

PyREBox is a Python scriptable Reverse Engineering sandbox. It is based on QEMU, and its goal is to aid reverse engineering by providing dynamic analysis and debugging capabilities from a different perspective. 

PyREBox allows to inspect a running QEMU VM, modify its memory or registers, and to instrument its execution, by creating simple scripts in python to automate any kind of analysis.

QEMU (when working as a whole-system-emulator) emulates a complete system (CPU, memory, devices...). By using VMI techniques, it does not require to perform any modification into the guest operating system, as it transparently retrieves information from its memory at run-time.

Several academic projects such as DECAF, PANDA, S2E, or AVATAR, have previously leveraged QEMU based instrumentation to overcome reverse engineering tasks. These projects allow to write plugins in C/C++, and implement several advanced features such as dynamic taint analysis, symbolic execution, or even record and replay of execution traces. With PyREBox, author aim to apply this technology focusing on keeping the design simple, and on the usability of the system for threat analysts.

Goals

• Provide a whole system emulation platform with a simple interface for inspecting the emulated guest system.

1. Fine grained instrumentation of system events.
2. Integrated Virtual Machine Introspection (VMI), based on volatility. No agent or driver needs to be installed into the guest.
3. An IPython based shell interface.
4. A Python based scripting engine, that allows to integrate into the scripts any of the security tools based on this language (one of the biggest ecosystems).

• Have a clean design, de-coupled from QEMU. Many projects that are built over QEMU do not evolve when QEMU gets upgraded, missing new features and optimizations, as well as security updates. In order to achieve this, PyREBox is implemented as an independent module that can be compiled together with QEMU requiring a minimal set of modifications.
• Support for different architectures. Currently, PyREBox only supports Windows for x86 and x86-64 bit architectures, but its design allows to support other architectures such as ARM, MIPS, or PowerPC, and other operating systems as well.

IPython shell

Starting a PyREBox shell is as easy as typing the sh command on QEMU’s monitor. It will immediately start an IPython shell. This shell records the command history as well as the defined variables. For instance, you can save a value and recover it later at a different point of the execution, when you start the shell again. PyREBox takes advantage of all the available features in IPython such as auto-completion, command history, multi-line editing, and automated command help generation.

PyREBox will allow you to debug the system (or a process) in a fairly stealthy way. Unlike traditional debuggers which stay in the system being debugged (even modifying the memory of the debugged process to insert breakpoints), PyREBox stays completely outside the inspected system, and it does not require the installation of any driver or component into the guest.

REBox offers a complete set of commands to inspect and modify the state of the running VM. Just type list_commands to obtain a complete list. You can run any volatility plugin just by typing vol and the corresponding volatility command. For a complete list of available volatility plugins, you can type list_vol_commands. This list is generated automatically, so it will also show any volatility plugin you install on PyREBox's volatility/ path.

You can also define your own commands! It is as simple as declaring a function in a script, and loading it.

If you need something more expressive than a command, you can write a Python snippet leveraging the API. For a detailed description of the API, see Documentation or type help(api) in the shell.

Scripting

PyREBox allows to dynamically load scripts that can register callback functions that are called when certain events occur, like instructions executed, memory read/written, processes created/destroyed, and so on.

Given that PyREBox is integrated with Volatility, it will let you take advantage of all the volatility plugins for memory forensics in your python scripts. Many of the most famous reverse engineering tools are implemented in Python or at least have Python bindings. Our approach allows to integrate any of these tools into a script.

Finally, given that python callbacks can introduce a performance penalty on frequent events such as instructions executed, it is also possible to create triggers. Triggers are native-code plug-in’s (developed in C/C++) that can be inserted dynamically at run-time on any event just before the Python callback is executed. This allows to limit the number of events that hit the python code, as well as to precompute values in native code.

In this repository you will find example scripts that can help you to write your owncode . Contributions are welcome!

Install

A build script is provided. For specific details about dependencies, please see BUILD. We also provide a Dockerfile.

Starting a VM

PyREBox is based on QEMU, so in order to start a VM withing PyREBox, you need to run it exactly as you were booting up a QEMU VM. A couple of example scripts are provided: start_i386.sh, start_x86_64.sh, you can use them as an example.

The only QEMU monitor option supported currently is stdio (-monitor stdio).

Roadmap

• VM image configuration and management console.
• Support for ARM, MIPS, and other architectures.
• Support for GNU/Linux guest systems.

Download PyREBox

LinEnum: A Tool To Check Local Linux Enumeration And Privilege Escalation Script

LinEnum : A Tool to Check Local Linux Enumeration & Privilege Escalation Script 

General usage:

version 0.6

• Example: ./LinEnum.sh -k keyword -r report -e /tmp/ -t

Options:

• -k Enter keyword
• -e Enter export location
• -t Include thorough (lengthy) tests
• -r Enter report name
• -h Displays this help text

Running with no options = limited scans/no output file

• -e Requires the user enters an output location i.e. /tmp/export. If this location does not exist, it will be created.
• -r Requires the user to enter a report name. The report (.txt file) will be saved to the current working directory.
• -t Performs thorough (slow) tests. Without this switch default 'quick' scans are performed.
• -k An optional switch for which the user can search for a single keyword within many files (documented below).

See CHANGELOG.md for further details

High-level summary of the checks/tasks performed by LinEnum:

• Kernel and distribution release details
• System Information:
  • Hostname
  • Networking details:
  • Current IP
  • Default route details
  • DNS server information
• User Information:
  • Current user details
  • Last logged on users
  • Shows users logged onto the host
  • List all users including uid/gid information
  • List root accounts
  • Extracts password policies and hash storage method information
  • Checks umask value
  • Checks if password hashes are stored in /etc/passwd
  • Extract full details for ‘default’ uid’s such as 0, 1000, 1001 etc
  • Attempt to read restricted files i.e. /etc/shadow
  • List current users history files (i.e .bash_history, .nano_history etc.)
  • Basic SSH checks
• Privileged access:
  • Determine if /etc/sudoers is accessible
  • Determine if the current user has Sudo access without a password
  • Are known ‘good’ breakout binaries available via Sudo (i.e. nmap, vim etc.)
  • Is root’s home directory accessible
  • List permissions for /home/
• Environmental:
  • Display current $PATH
  • Displays env information
• Jobs/Tasks:
  • List all cron jobs
  • Locate all world-writable cron jobs
  • Locate cron jobs owned by other users of the system
• Services:
  • List network connections (TCP & UDP)
  • List running processes
  • Lookup and list process binaries and associated permissions
  • List inetd.conf/xined.conf contents and associated binary file permissions
  • List init.d binary permissions
• Version Information (of the following):
  • Sudo
  • MYSQL
  • Postgres
  • Apache
    • Checks user config
    • Shows enabled modules
• Default/Weak Credentials:
  • Checks for default/weak Postgres accounts
  • Checks for default/weak MYSQL accounts
• Searches:
  • Locate all SUID/GUID files
  • Locate all world-writable SUID/GUID files
  • Locate all SUID/GUID files owned by root
  • Locate ‘interesting’ SUID/GUID files (i.e. nmap, vim etc)
  • List all world-writable files
  • Find/list all accessible *.plan files and display contents
  • Find/list all accessible *.rhosts files and display contents
  • Show NFS server details
  • Locate *.conf and *.log files containing keyword supplied at script runtime
  • List all *.conf files located in /etc
  • Locate mail
• Platform/software specific tests:
• Checks to determine if we're in a Docker container
• Checks to see if the host has Docker installed

Download

Dork-cli Command Line Tool To Find Google Dork

Dork-cli Command-line Google Dork Tool

dork-cli performs searches against a Google custom search engine and returns a list of all the unique page results it finds, optionally filtered by a set of dynamic page extensions. 

Any number of additional query terms / dorks can be specified. dork-cli was designed to be piped into an external tool such as a vulnerability scanner for automated testing purposes.

Setup

In order to use this program you need to configure at a minimum two settings: a Google API key and a custom search engine id.

Custom Search Engine:

• Create a custom search engine via https://www.google.com/cse/
• Add your desired domain(s) under "Sites to search"
• Click "Search engine ID" button to reveal the id, or grab it from the "cx" url paramter

API key:

• Open the Google API console at https://code.google.com/apis/console
• Enable the Custom Search API via APIs & auth > APIs
• Create a new API key via APIs & auth > Credentials > Create new Key
• Select "Browser key", leave HTTP Referer blank and click Create

Usage

$ ./dork-cli.py -h
usage: dork-cli.py [-h] [-e ENGINE] [-f [FILETYPES]] [-k KEY] [-m MAX_QUERIES]
                   [-s SLEEP]
                   [T [T ...]]

Find dynamic pages via Google dorks.

positional arguments:
  T                     additional search term

optional arguments:
  -h, --help            show this help message and exit
  -e ENGINE, --engine ENGINE
                        Google custom search engine id (cx value)
  -f [FILETYPES], --filetypes [FILETYPES]
                        File extensions to return (if present but no
                        extensions specified, builtin dynamic list is used)
  -k KEY, --key KEY     Google API key

 -m MAX_QUERIES, --max-queries MAX_QUERIES
                        Maximum number of queries to issue
  -s SLEEP, --sleep SLEEP
                        Seconds to sleep before retry if daily API limit is
                        reached (0=disable)

Examples:

• NOTE: including -f/--filetypes without an argument, e.g. followed by --, defaults to filtering by a builtin list of dynamic file extensions.

$ ./dork-cli.py inurl:login
https://www.example.com/usher/Login.aspx
https://www.example.com/login/
http://www.example.com/rooms/index.php?option=com_user&view=login&Itemid=8
http://www.example.com/index.php?cmd=login
[...]
$ ./dork-cli.py --filetypes -- inurl:id
http://www.example.com/its/sla/sla.php?id=1617
http://www.example.com/bbucks/index.php?site=5&scode=0&id=720
http://www.example.com/directory/details.aspx?id=33
http://www.example.com/SitePages/VOIP%20ID.aspx
http://www.example.com/personnel_ext.php?id=44
http://www.example.com/its/alerts/event.php?id=7220
[...]
$ ./dork-cli.py --filetypes=php,aspx intitle:login inurl:admin
https://www.example.com/users/lab/admin/portal.php
https://www.example.com/admin/start/login.aspx?ReturnUrl=%2Fadmin%2Fscheduling%2Faudit%2Fdefault.aspx
http://www.example.com/admin/admin.php
[...]

API Limitations

The free Google API limits you to 100 searches per day, with a maximum of 10 results per search. This means if you configure dork-cli.py to return 100 results, it will issue 10 queries (1/10th of your daily limit) each time it is run.

You have the option to pay for additional searches via the Google API console. At the time of writing, signing up for billing on the Google API site gets you $300 free to spend on API calls for 60 days.

Download 

How To Port Windows Dynamic Link Libraries to Linux

Porting Windows Dynamic Link Libraries to Linux.

Tavis Ormandy, who is the vulnerability researcher at Google have developed loadlibrary tool.

Introduction

This repository contains a library that allows native Linux programs to load and call functions from a Windows DLL.

As a demonstration, Ormandy ported Windows Defender to Linux.

$ ./mpclient eicar.com
main(): Scanning eicar.com...
EngineScanCallback(): Scanning input
EngineScanCallback(): Threat Virus:DOS/EICAR_Test_File identified.

How does it work?

The peloader directory contains a custom PE/COFF loader derived from ndiswrapper. The library will process the relocations and imports, then provide a dlopen-like API. The code supports debugging with gdb (including symbols), basic block coverage collection, and runtime hooking and patching.

What works?

The intention is to allow scalable and efficient fuzzing of self-contained Windows libraries on Linux. Good candidates might be video codecs, decompression libraries, virus scanners, image decoders, and so on.

• C++ exception dispatch and unwinding.
• Loading additional symbols from IDA.
• Debugging with gdb (including symbols), breakpoints, stack traces, etc.
• Runtime hooking and patching.
• Support for ASAN and Valgrind to detect subtle memory corruption bugs.

If you need to add support for any external imports, writing stubs is usually quick and easy.

Why?

Distributed, scalable fuzzing on Windows can be challenging and inefficient. This is especially true for endpoint security products, which use complex interconnected components that span across kernel and user space. This often requires spinning up an entire virtualized Windows environment to fuzz them or collect coverage data.

This is less of a problem on Linux, and Ormandy found that porting components of Windows Antivirus products to Linux is often possible. This allows to run the code testing in minimal containers with very little overhead, and easily scale up testing.

Windows Defender

MsMpEng is the Malware Protection service that is enabled by default on Windows 8, 8.1, 10, Windows Server 2016, and so on. Additionally, Microsoft Security Essentials, System Centre Endpoint Protection and various other Microsoft security products share the same core engine.

The core component of MsMpEng responsible for scanning and analysis is called mpengine. Mpengine is a vast and complex attack surface, comprising of handlers for dozens of esoteric archive formats, executable packers, full system emulators for various architectures and interpreters for various languages. All of this code is accessible to remote attackers.

Building

To build the test client, simply type make.

$ make

Dependencies

Fedora / RedHat         Ubuntu / Debian               Comment
glibc-devel.i686          libc6-dev:i386
libgcc.i686                    gcc-multilib
readline-devel.i686  libreadline-dev:i386 Optional, used in mpscript.
cabextract                    cabextract                 Used to extract definitions.

You will need to download the 32-bit antimalware update file from this page:
https://www.microsoft.com/security/portal/definitions/adl.aspx#manual

This should be a direct link to the right file:
http://go.microsoft.com/fwlink/?LinkID=121721&arch=x86

This will download a file called mpam-fe.exe, which is a cabinet file that can be extracted with cabextract. Extract the files into the engine directory:

$ cabextract mpam-fe.exe
Extracting cabinet: mpam-fe.exe
  extracting MPSigStub.exe
  extracting mpavdlta.vdm
  extracting mpasdlta.vdm
  extracting mpavbase.vdm
  extracting mpasbase.vdm
  extracting mpengine.dll

All done, no errors.

If you want to know which version you got, try this:

$ exiftool mpengine.dll | grep 'Product Version Number'
Product Version Number          : 1.1.13701.0

Running

The main mpengine loader is called mpclient, it accepts filenames to scan as a parameter.

$ ./mpclient netsky.exe
main(): Scanning netsky.exe...
EngineScanCallback(): Scanning input
EngineScanCallback(): Threat Worm:Win32/Netsky.P@mm identified.

There are some other sample tools, mpstreamfuzz and mpscript.

Debugging

If you want to debug a crash, single step through a routine or set breakpoints, follow these examples. First, you need a map file from IDA.

Microsoft doesn't release public symbols for every build, and sometimes the symbols lag behind for a few months after release. Make sure you're using an mpengine version with public symbols available.

Use the following sample commandline to generate map and idb files.

> idaw -A -P+ -S"createmap.idc mpengine.map" mpengine.dll


If you generate the map files on Windows, you'll get CRLF line terminators, fix them like this:

$ dos2unix mpengine.map

When you run mpclient under gdb, it will detect a debugger and print the commands you need to enter to teach gdb about the symbols:

$ gdb -q ./mpclient
(gdb) r testfile.txt
Starting program: mpclient
main(): GDB: add-symbol-file engine/mpengine.dll 0xf6af4008+0x1000
main(): GDB: shell bash genmapsym.sh 0xf6af4008+0x1000 symbols_19009.o < mpengine.map
main(): GDB: add-symbol-file symbols_19009.o 0

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0804d213 in main (argc=1, argv=0xffffcc64, envp=0xffffcc6c) at mpclient.c:156
156         __debugbreak();
(gdb)

If you enter the commands it shows into gdb, you will have symbols available.

(gdb) add-symbol-file engine/mpengine.dll 0xf6af4008+0x1000
add symbol table from file "engine/mpengine.dll" at
.text_addr = 0xf6af5008
Reading symbols from engine/mpengine.dll...done.
(gdb) shell bash genmapsym.sh 0xf6af4008+0x1000 symbols_19009.o < mpengine.map
(gdb) add-symbol-file symbols_19009.o 0
add symbol table from file "symbols_19009.o" at
.text_addr = 0x0
Reading symbols from symbols_19009.o...done.
(gdb) p as3_parsemetadata_swf_vars_t
$1 = {void (void)} 0xf6feb842 <as3_parsemetadata_swf_vars_t>

Then you can continue, and it will run as normal.

(gdb) c

Breakpoints, watchpoints and backtraces all work as normal, although it may be more reliable to use hardware breakpoints than software breakpoints.

To use hardware breakpoints in gdb, you just use hb or hbreak instead of break. Note that you only get a limited number of hardware breakpoints.

(gdb) b as3_parsemethodinfo_swf_vars_t
Breakpoint 1 at 0xf6feb8da
(gdb) c
Continuing.
main(): Scanning test/input.swf...
EngineScanCallback(): Scanning input
Breakpoint 1, 0xf6feb8da in as3_parsemethodinfo_swf_vars_t ()
(gdb) bt
#0  0xf6feb8da in as3_parsemethodinfo_swf_vars_t ()
#1  0xf6dbad7f in SwfScanFunc ()
#2  0xf6d73ec3 in UfsScannerWrapper__ScanFile_scanresult_t ()
#3  0xf6d6c9e3 in UfsClientRequest__fscan_SCAN_REPLY ()
#4  0xf6d6a818 in UfsNode__ScanLoopHelper_wchar_t ()
#5  0xf6d6a626 in UfsNode__Analyze_UfsAnalyzeSetup ()
#6  0xf6d71f7f in UfsClientRequest__AnalyzeLeaf_wchar_t ()
#7  0xf6d71bb9 in UfsClientRequest__AnalyzePath_wchar_t ()
#8  0xf6dbbd88 in std___String_alloc_std___String_base_types_char_std__allocator_char______Myptr_void_ ()
#9  0xf6d75e72 in UfsCmdBase__ExecuteCmd__lambda_c80a88e180c1f4524a759d69aa15f87e____lambda_c80a88e180c1f4524a759d69aa15f87e__ ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) x/3i $pc
=> 0xf6feb8da <as3_parsemethodinfo_swf_vars_t+7>: lea    ebx,[edx+0x1c]
   0xf6feb8dd <as3_parsemethodinfo_swf_vars_t+10>: push   esi
   0xf6feb8de <as3_parsemethodinfo_swf_vars_t+11>: mov    edx,ebx

What about Wine and Winelib?

This project does not replace Wine or Winelib.

Winelib is used to port Windows C++ projects to Linux, and Wine is intended to run full Windows applications. This project is intended to allow native Linux code to load simple Windows DLLs.

The closest analogy would be ndiswrapper but for userspace.

Download