Vulnerable Life by Vulneraman | Information Security Blog

OWASP OWTF – Offensive Web Testing Framework

OWASP Offensive Web Testing Framework is a project focused on penetration testing efficiency and alignment of security tests to security standards like: The OWASP Testing Guide (v3 and v4), the OWASP Top 10, PTES and NIST.

OWASP OWTF - Offensive Web Testing Framework

The purpose of this tool is to automate the manual and uncreative parts of pen testing. For example, Figuring out how to call “tool X” then parsing results of “tool X” manually to feed “tool Y” and so on is time consuming.

By reducing this burden we hope pen testers will have more time to:

  • See the big picture and think out of the box,
  • Find, verify and combine vulnerabilities efficiently,
  • Have time to Investigate complex vulnerabilities like business logic, architectural flaws, virtual hosting sessions, etc.
  • Perform more tactical/targeted fuzzing on seemingly risky areas
  • Demonstrate true impact despite the short time-frames we are typically given to test.


This tool is however not a silver bullet and will only be as good as the person using it. Understanding and experience will be required to correctly interpret the tool output and decide what to investigate further in order to demonstrate the impact.


  • Web UI. Now configure and monitor OWTF via a responsive and powerful interface accessible via your browser.
  • Exposes RESTful APIs to all core OWTF capabilties.
  • Instead of implementing yet another spider (a hard job), OWTF will scrub the output of all tools/plugins run to gather as many URLs as possible.
  • Scan by various aggression levels: OWTF supports scans which are based on the aggressiveness of the plugins/tools invoked.
  • Extensible OWTF manages tools through ‘plugins’ making it trivial to add new tools.
  • OWTF has been developed keeping Kali Linux in mind, but it also supports other pentesting distros such as Samurai-WTF, etc.
  • Tool paths and configuration can be easily modified in the web interface.
  • Fastest Python MiTM proxy yet!
  • Crash reporting directly to Github issue tracker
  • Comprehensive interactive report at end of each scan
  • Easy plugin-based system; currently 100+ plugins!
  • CLI and web interface

You can download OWASP OWTF here:

Or read more here.


Download Offensive Web Testing Framework:

Original Post:

Portable Penetration Testing Distribution for Windows: PentestBox

    PentestBox is not like other Penetration Testing Distributions which runs on virtual machines. It is created because more than 70% of penetration testing distributions users uses windows and provides an efficient platform for Penetration Testing on windows. It provides all security tools as a software package, eliminating requirement of Virtual machines or dualboot environments on Windows Operating System. It is created because more than 50% of penetration testing distribution users uses windows.




A Portable Penetration Testing Distribution for Windows: PentestBox


Easy to Use

It is a command line utility which is all what you want.


Awesome Design

It is the same green font on black terminal but in an modern way.


Best Performance

PentestBox directly runs on host machine instead of virtual machines, so performance gain is obvious.


No Dependencies Needed

All the dependencies required by tools are inside PentestBox, so you can even run PentestBox on freshly installed windows without any hassle.



PentestBox is entirely portable, so now you can carry your own Penetration Testing Environment on a USB stick. It will take care of dependencies required to run tools which are inside it.


Linux Environment

PentestBox contains nearly all Linux utilities like bash, cat, chmod, curl, git, gzip, ls, mv, ps, ssh, sh, uname and others. It even contains your favourite text editor “vim”.  Because of this, most penetration testing tools which were earlier compatible only with Linux are working smoothly in PentestBox on Windows.


No Driver Issue

Windows has already large support of drivers for Graphic Cards and wireless chip-sets. Now, you don’t have to worry about drivers compatibility issues.



Only the best tools went into PentestBox, but if you miss something you can easily install it using tools-manager from the inside of PentestBox environment.


Less memory Usage

PentestBox runs on host machine without any need for virtual machine. It only needs 20 MB – compared to at least 2GB of RAM need for running virtual machine distributions.


Less Disk Usage

PentestBox is very light. It requires less than third of space of other penetration testing Linux distributions.


Inbuilt Browser

PentestBox packs a Mozilla Firefox Browser with nearly all security addons.


Automatic Updates

Automatic update feature will keep your tool up to date.


Can Be Shared On A Network

You can use PentestBox on many computers by sharing it through network. You don’t have to install it on each and every computer that you want it to run on. Just install PentestBox on one computer and share it to all other computers on the same network.











No Metasploit ?

Metasploit contain exploits/payloads inside its folder structure, so when installed on windows machines nearly all anti-viruses and firewalls fire up. Metasploit officially instruct users to disable anti-viruses and firewalls while using it. It’s your call. If you willing to switch off your antiviruses program and want to use Metsaploit on Windows, you can download windows installer for Metsaploit from officially Metsaploit website.


PentestBox throwing up red flags ?

PentestBox is packed by UPX which is identified as malware by some antivirus softwares. You can scan PentestBox.exe with and see the result. As an alternative there is a PentestBox.bat file in the same directory which upon running won’t show any warnings. There are some ruby gems also which can also flag as virus/malware, you can remove those of your antivirus are flagging it. Also THC-SSL-DOS will also be flagged because of it’s action against SSL servers.If you worried about those warnings then you can allow your Antivirus to remove those files, in that case you can start PentestBox through PentestBox.bat file and THC-SSL-DOS will not work. Rest other tools/products will work normally.


How to include your own Tool

If you want to include a tool which is not currently present in PentestBox then below are the ways to include it.

  • If it is Python based program
    • Place that folder in PentestBox_Directory/bin or in any folder inside bin.
    • As Python is configured inside PentestBox, you can directly go to that directory and then run that program by prepending python to the filename.
    • But if you want to set an alias for that program then please follow How to add an alias
  • If it is Ruby Based Program
    • Place that folder in PentestBox_Directory/bin or in any folder inside bin.
    • As Ruby is configured inside PentestBox, you can directly go to that directory and then run that program by prepending ruby to the filename.
    • But if you want to set an alias for that program then please follow How to add an alias
  • It it is Executable file
    • Place that folder in PentestBox_Directory/bin or in any folder inside bin.
    • You can directly access by moving to that folder and typing the filename.
    • But if you want to set an alias for that program then please follow How to add an alias


Source && Download



Original Post:

MorphAES – IDPS & SandBox & AntiVirus STEALTH KILLER

MorphAES is the world’s first polymorphic shellcode/malware engine, with metamorphic properties and capability to bypass sandboxes, which makes it undetectable for an IDPS, it’s cross-platform as well and library-independent.


  • Polymorphism (AES encryption)
  • Metamorphism (logic and constants changing)
  • Platform independent (Linux/BSD/Windows)
  • IDPS stealthing (the total number of possible signatures is more the number of atoms in the universe for one given code)
  • Sandbox evasion (special assembly instructions)
  • Realism (no null bytes)
  • Can produce executables (malwares)
  • Input code can have arbitrary length

Dependencies for the morpher:

  • Python 2.7 – main engine
  • Python Crypto 2.6 – for encryption

Dependencies for the code execution:

  • 64-bit Intel AES-NI – for decryption

Nonetheless, there are some limitations (aka white-hat aspects):

  • Metamorphism is not very robust and can be detected using regular expressions (but can be improved pretty easily)
  • Unicode null bytes might still work (but who cares?)
  • It will only work on 64-bit Intel processors with AES-NI support, but since all the user’s PCs (like Pentium, Celeron, i3, i5, i7) and the industry’s servers (like Xeon) have it, it’s more a specification, rather than a limitation, thus a 32-bit implementation is unpractical
  • Almost any shellcode is guarantee to work however, an arbitrary code (malware) doesn’t
  • Windows/BSD PoC and executables are in progress…

How it works

  1. Shellcode padding with NOPs (since AES is a block cipher)
  2. Shellcode encryption with a random key using AES-128-ECB (not the best, but the simplest) – polymorphism
  3. Constants randomization, logic changes, instructions modification and rewriting – metamorphism

For Linux:

sudo apt-get install python python-crypto

Execute the Pyhton script and enter your shellcode or nothing for a default Linux shell. You can specify your own execution address as well.
It is possible to build and execute on Windows/BSD/Mac as well, but I’m still testing it.
You can also use the Linux PoC in assembly:

as shellcode.s -o shellcode.o
ld shellcode.o -o shellcode

Every file is commented and explained

At this point, it should be pretty obvious that, the hashes would be different every time, but let’s compare SSDEEPes of 2 Linux executables of the same shellcode:

  • 96:GztTHyKGQh3lo6Olv4W4zS/2WnDf74i4a4B7UEoB46keWJl09:Gzty6VOlvqSTDflmNroh,
  • 96:GQtT23yKmFUh3lo6OlOnIrFS4rkoPPf74i4a4B7UEoB46keWJ5:GQtCGWVOlOWFSsPflmNroh,

Well, there’s something in common, but globally those are 2 different signatures, now what about the shellcode it-self:

  • 48:eip2bR2LRNtRPORDGRopRBXR3cRzER2vRU9BnH6ksr:Srn+,
  • 48:6RjNeR2IRN7RPWRDeRokRB5R3xRz3R28RUxFT2+75eFK9iKMAdXAJKo:O9Tdwoo,

Almost totally different signatures for the same morphed shellcode!
At the publication date, the executable was detected as a shellcode only by 2 out of 53 antiviruses (AVG and Ikarus) onvirustotal , but now, it just fails to analyze.
malwr’s with cuckoo2 doesn’t see anything suspicious.
On the reverser’s perspective, IDA won’t see anything either.
Radare2 would show the real instructions only if assembled by the assembler it-self however, it doesn’t detects any crypto or suspicious activity for the executable.
Althrough, I didn’t test it personally, I think that FortiSandbox, Sophos Sandstorm, Blue Coat, GateWatcher and their derivatives might fail badly…

To put it in the nutshell
Basically, it can transform a script-kid’s code (or a known-one ) into a zero-day.
IDPS will fail because, it’s almost impossible to make a signature and difficult to make a regular expression or heuristic analysis.
Most of the sandboxes doesn’t use Intel’s AES-NI instructions directly, so they will not execute the code, so “everything is fine” for them, whereas it’s not.
The only way to defeat this type of shellcode/malware is to use an appropriate sandboxing or/and an AI.
Notice that, the whole execution is done by a pure assembly, no Python (or shitty OpenSSL) is needed for the shellcode’s/malware’s execution since, I use built-in assembly instructions only, thus it’s system-independent (surely, you will have to assemble it for each-one by adapting the instructions/opcodes, but they are still same).

This is still a work in progress, I will implement Windows and BSD/Mac engines and PoCs ASAP.
IDPSes and sanboxes suck.

“Tradition becomes our security, and when the mind is secure it is in decay.”

Jiddu Krishnamurti

Original Post:

Digital Forensics According to the FORZA Model and Diamond Model for Intrusion Analysis

The Bridge on the River Forza

We can teach these barbarians a lesson in Western methods and efficiency that will put them to shame.” -Colonel Nicholson (The Bridge on the River Kwai, 1957)

Efficiency. Something we look to implement in everything we do, whether that be through the elimination of waste through Six Sigma, or other frameworks and methodologies, efficiency is what we strive for. When performing digital forensics, efficiency and rigor in our approach to ensure no stone left unturned is paramount to the success of the investigation.

One of the many frameworks that exists is FORZA, a group of tasks and processes in a digital forensics investigation that revolves around a triad of: Reconnaissance, Reliability, and Relevancy.

For Reconnaissance, the case examiner will collect, recover, decode, discover, extract, analyze, and convert data that is kept on different storage media to readable evidence.

Reliability speaks to the integrity of the evidence and the relationship between the people and the evidence such that it will hold up in court if prosecuted.

Relevancy speaks to the relevancy of the evidence, even if it is admissible in court.

The FORZA Framework defines eight separate roles in a digital forensics investigation, the case leader, system/business owner, legal advisor, security/system architect/auditor, digital forensics specialist, digital forensics investigator/system administrator/operator, digital forensics analyst, and a legal prosecutor.

Each of these roles are interconnected through six categories of questions that must be answered in the investigation: (1) What (data); (2) Why (motivation); (3) How (function); (4) Who (people); (5) Where (network); and (6) when (time). If you think about it, this is very similar to what a crime scene investigator must answer when investigating a murder scene, which is why I’m always saying that digital forensics is like CSI: Miami meets Bones.

Here’s a short video I made on the topic.

Below is a table detailing out the responsibilities for each role in answering each of the six questions.

Okay, so now that we’ve covered FORZA (don’t get confused here), let’s discuss a newer, more novel model gaining widespread popularity, which is the Diamond Model of Intrusion Analysis; a model of intrusion analysis built by analysts, asking the simple question, “What is the underlying method to our work?” The model establishes the basic atomic element of any intrusion activity, the event, composed of four core features: adversary, infrastructure, capability, and victim.

These features are edge-connected representing their underlying relationships and arranged in the shape of a diamond, giving the model its name.

In its simplest form, the model describes that an adversary deploys a capability over some infrastructure against a victim. These activities are called events and are the atomic features. Analysts populate the model’s vertices as events are discovered and detected. The vertices are linked with edges highlighting the natural relationship between the features. By pivoting across edges and within vertices, analysts expose more information about adversary operations and discover new capabilities, infrastructure, and victims.

The Diamond Model of intrusion analysis comprises the core features of an intrusion event:adversary, capability, infrastructure, and victim. The core features are linked via edges to represent the fundamental relationships between the features which can be exploited analytically to further discover and develop knowledge of malicious activity.

The above depiction models analytic pivoting using the Diamond Model. One of the most powerful features of the Diamond — pivoting, allows an analyst to exploit the fundamental relationship between features (highlighted by edges between the features) to discover new knowledge of malicious activity.

Subsequent to this analysis is an Activity-Attack Graph, diagrammed above. This chart illustrates the integration of knowledge of actual adversary attack paths with the multitude of hypothetical attack paths that could be taken. Using an activity-attack graph highlights the potential paths of an adversary in the future as well as the preferred paths based on current knowledge.

As forensic analysts, we should always look to be continuously improving our craft, especially around our methodology in how we conduct investigations. I leave it to you to decide on which methodology you adopt, or possibly even make better.

A sample report has been created by Brier & Thorn that has been designed around the Diamond Model and is available here for free download.

More information on the Diamond Model can be found here and here.

Original Post:

Awesome Malware Analysis Lists

A curated list of awesome malware analysis tools and resources. Inspired by awesome-python and awesome-php.

Malware Collection


Web traffic anonymizers for analysts.

  • – A free, web based anonymizer.
  • OpenVPN – VPN software and hosting solutions.
  • Privoxy – An open source proxy server with some privacy features.
  • Tor – The Onion Router, for browsing the web without leaving traces of the client IP.


Trap and collect your own samples.

  • Conpot – ICS/SCADA honeypot.
  • Dionaea – Honeypot designed to trap malware.
  • Glastopf – Web application honeypot.
  • Honeyd – Create a virtual honeynet.
  • HoneyDrive – Honeypot bundle Linux distro.
  • Kippo – Medium interaction SSH honeypot.
  • Mnemosyne – A normalizer for honeypot data; supports Dionaea.
  • Thug – Low interaction honeyclient, for investigating malicious websites.

Malware Corpora

Malware samples collected for analysis.

  • Clean MX – Realtime database of malware and malicious domains.
  • Contagio – A collection of recent malware samples and analyses.
  • Exploit Database – Exploit and shellcode samples.
  • Malshare – Large repository of malware actively scrapped from malicious sites.
  • maltrieve – Retrieve malware samples directly from a number of online sources.
  • MalwareDB – Malware samples repository.
  • theZoo – Live malware samples for analysts.
  • ViruSign – Malware database that detected by many anti malware programs except ClamAV.
  • VirusShare – Malware repository, registration
  • Zeltser’s Sources – A list of malware sample sources put together by Lenny Zeltser.
  • Zeus Source Code – Source for the Zeus trojan leaked in 2011. required.

Open Source Threat Intelligence


Harvest and analyze IOCs.

  • Combine – Tool to gather Threat Intelligence indicators from publicly available sources.
  • IntelMQ – A tool for CERTs for processing incident data using a message queue.
  • IOC Editor – A free editor for XML IOC files, from Mandiant.
  • ioc_writer – Python library for working with OpenIOC objects, from Mandiant.
  • Massive Octo Spice – Previously known as CIF (Collective Intelligence Framework). Aggregates IOCs from various lists. Curated by the CSIRT Gadgets Foundation.
  • MISP – Malware Information Sharing Platform curated by The MISP Project.
  • PassiveTotal – Research, connect, tag and share IPs and domains.
  • threataggregator – Aggregates security threats from a number of sources, including some of those listed below in other resources.
  • ThreatCrowd – A search engine for threats, with graphical visualization.
  • TIQ-test – Data visualization and statistical analysis of Threat Intelligence feeds.

Other Resources

Threat intelligence and IOC resources.

Detection and Classification

Antivirus and other malware identification tools

  • AnalyzePE – Wrapper for a variety of tools for reporting on Windows PE files.
  • chkrootkit – Local Linux rootkit detection.
  • ClamAV – Open source antivirus engine.
  • ExifTool – Read, write and edit file metadata.
  • hashdeep – Compute digest hashes with a variety of algorithms.
  • Loki – Host based scanner for IOCs.
  • Malfunction – Catalog and compare malware at a function level.
  • MASTIFF – Static analysis framework.
  • MultiScanner – Modular file scanning/analysis framework
  • nsrllookup – A tool for looking up hashes in NIST’s National Software Reference Library database.
  • packerid – A cross-platform Python alternative to PEiD.
  • PEiD – Packer identifier for Windows binaries.
  • PEV – A multiplatform toolkit to work with PE files, providing feature-rich tools for proper analysis of suspicious binaries.
  • Rootkit Hunter – Detect Linux rootkits.
  • ssdeep – Compute fuzzy hashes.
  • – Python script for easy searching of the database.
  • TrID – File identifier.
  • YARA – Pattern matching tool for analysts.
  • Yara rules generator – Generate yara rules based on a set of malware samples. Also contains a good strings DB to avoid false positives.

Online Scanners and Sandboxes

Web-based multi-AV scanners, and malware sandboxes for automated analysis.

  • AndroTotal – free online analysis of APKs against multiple mobile antivirus apps.
  • Anubis – Malware Analysis for Unknown Binaries and Site Check.
  • AVCaesar – online scanner and malware repository.
  • Cryptam – Analyze suspicious office documents.
  • Cuckoo Sandbox – Open source, self hosted sandbox and automated analysis system.
  • cuckoo-modified – Modified version of Cuckoo Sandbox released under the GPL. Not merged upstream due to legal concerns by the author.
  • DeepViz – Multi-format file analyzer with machine-learning classification.
  • DRAKVUF – Dynamic malware analysis system.
  • Hybrid Analysis – Online malware analysis tool, powered by VxSandbox.
  • IRMA – An asynchronous and customizable analysis platform for suspicious files.
  • Jotti – Free online multi-AV scanner.
  • Malheur – Automatic sandboxed analysis of malware behavior.
  • Malwr – Free analysis with an online Cuckoo Sandbox instance.
  • MASTIFF Online – Online static analysis of malware.
  • Metascan Online – Free file scanning with multiple antivirus engines.
  • Noriben – Uses Sysinternals Procmon to collect information about malware in a sandboxed environment.
  • PDF Examiner – Analyse suspicious PDF files.
  • Recomposer – A helper script for safely uploading binaries to sandbox sites.
  • VirusTotal – Free online analysis of malware samples and URLs
  • Zeltser’s List – Free automated sandboxes and services, compiled by Lenny Zeltser.

Domain Analysis

Inspect domains and IP addresses.

  • – One click tool to retrieve as much metadata as possible for a website and to assess its good standing.
  • Dig – Free online dig and other network tools.
  • IPinfo – Gather information about an IP or domain by searching online resources.
  • SenderBase – Search for IP, domain or network owner.
  • SpamCop – IP based spam block list.
  • SpamHaus – Block list based on domains and IPs.
  • Sucuri SiteCheck – Free Website Malware and Security Scanner.
  • TekDefense Automator – OSINT tool for gatherig information about URLs, IPs, or hashes.
  • Whois – DomainTools free online whois search.
  • Zeltser’s List – Free online tools for researching malicious websites, compiled by Lenny Zeltser.

Browser Malware

Analyze malicious URLs. See also the domain analysis and documents and shellcode sections.

  • Firebug – Firefox extension for web development.
  • Java Decompiler – Decompile and inspect Java apps.
  • Java IDX Parser – Parses Java IDX cache files.
  • JSDetox – JavaScript malware analysis tool.
  • jsunpack-n – A javascript unpacker that emulates browser functionality.
  • Malzilla – Analyze malicious web pages.
  • RABCDAsm – A “Robust ActionScript Bytecode Disassembler.”
  • swftools – Tools for working with Adobe Flash files.
  • xxxswf – A Python script for analyzing Flash files.

Documents and Shellcode

Analyze malicious JS and shellcode from PDFs and Office documents. See also the browser malware section.

  • AnalyzePDF – A tool for analyzing PDFs and attempting to determine whether they are malicious.
  • diStorm – Disassembler for analyzing malicious shellcode.
  • JS Beautifier – JavaScript unpacking and deobfuscation.
  • libemu – Library and tools for x86 shellcode emulation.
  • malpdfobj – Deconstruct malicious PDFs into a JSON representation.
  • OfficeMalScanner – Scan for malicious traces in MS Office documents.
  • olevba – A script for parsing OLE and OpenXML documents and extracting useful information.
  • Origami PDF – A tool for analyzing malicious PDFs, and more.
  • PDF Tools – pdfid, pdf-parser, and more from Didier Stevens.
  • PDF X-Ray Lite – A PDF analysis tool, the backend-free version of PDF X-RAY.
  • peepdf – Python tool for exploring possibly malicious PDFs.
  • Spidermonkey – Mozilla’s JavaScript engine, for debugging malicious JS.

File Carving

For extracting files from inside disk and memory images.

  • bulk_extractor – Fast file carving tool.
  • EVTXtract – Carve Windows Event Log files from raw binary data.
  • Foremost – File carving tool designed by the US Air Force.
  • Hachoir – A collection of Python libraries for dealing with binary files.
  • Scalpel – Another data carving tool.


Reverse XOR and other code obfuscation methods.

  • Balbuzard – A malware analysis tool for reversing obfuscation (XOR, ROL, etc) and more.
  • de4dot – .NET deobfuscator and unpacker.
  • ex_pe_xor & iheartxor – Two tools from Alexander Hanel for working with single-byte XOR encoded files.
  • NoMoreXOR – Guess a 256 byte XOR key using frequency analysis.
  • unxor – Guess XOR keys using known-plaintext attacks.
  • XORBruteForcer – A Python script for brute forcing single-byte XOR keys.
  • XORSearch & XORStrings – A couple programs from Didier Stevens for finding XORed data.
  • xortool – Guess XOR key length, as well as the key itself.

Debugging and Reverse Engineering

Disassemblers, debuggers, and other static and dynamic analysis tools.

  • Bokken – GUI for Pyew and Radare.
  • dnSpy – .NET assembly editor, decompiler and debugger.
  • Evan’s Debugger (EDB) – A modular debugger with a Qt GUI.
  • GDB – The GNU debugger.
  • hackers-grep – A utility to search for strings in PE executables including imports, exports, and debug symbols.
  • IDA Pro – Windows disassembler and debugger, with a free evaluation version.
  • Immunity Debugger – Debugger for malware analysis and more, with a Python API.
  • ltrace – Dynamic analysis for Linux executables.
  • objdump – Part of GNU binutils, for static analysis of Linux binaries.
  • OllyDbg – An assembly-level debugger for Windows executables.
  • pestudio – Perform static analysis of Windows executables.
  • Process Monitor – Advanced monitoring tool for Windows programs.
  • Pyew – Python tool for malware analysis.
  • Radare2 – Reverse engineering framework, with debugger support.
  • strace – Dynamic analysis for Linux executables.
  • Udis86 – Disassembler library and tool for x86 and x86_64.
  • Vivisect – Python tool for malware analysis.
  • X64dbg – An open-source x64/x32 debugger for windows.


Analyze network interactions.

  • Bro – Protocol analyzer that operates at incredible scale; both file and network protocols.
  • CapTipper – Malicious HTTP traffic explorer.
  • chopshop – Protocol analysis and decoding framework.
  • Fiddler – Intercepting web proxy designed for “web debugging.”
  • Hale – Botnet C&C monitor.
  • INetSim – Network service emulation, useful when building a malware lab.
  • Malcom – Malware Communications Analyzer.
  • Maltrail – A malicious traffic detection system, utilizing publicly available (black)lists containing malicious and/or generally suspicious trails and featuring an reporting and analysis interface.
  • mitmproxy – Intercept network traffic on the fly.
  • Moloch – IPv4 traffic capturing, indexing and database system.
  • NetworkMiner – Network forensic analysis tool, with a free version.
  • ngrep – Search through network traffic like grep.
  • Tcpdump – Collect network traffic.
  • tcpick – Trach and reassemble TCP streams from network traffic.
  • tcpxtract – Extract files from network traffic.
  • Wireshark – The network traffic analysis tool.

Memory Forensics

Tools for dissecting malware in memory images or running systems.

  • DAMM – Differential Analysis of Malware in Memory, built on Volatility
  • FindAES – Find AES encryption keys in memory.
  • Muninn – A script to automate portions of analysis using Volatility, and create a readable report.
  • Rekall – Memory analysis framework, forked from Volatility in 2013.
  • TotalRecall – Script based on Volatility for automating various malware analysis tasks.
  • VolDiff – Run Volatility on memory images before and after malware execution, and report changes.
  • Volatility – Advanced memory forensics framework.
  • WinDbg – Live memory inspection and kernel debugging for Windows systems.

Windows Artifacts

  • AChoir – A live incident response script for gathering Windows artifacts.
  • python-evt – Python library for parsing Windows Event Logs.
  • python-registry – Python library for parsing registry files.
  • RegRipper (GitHub) – Plugin-based registry analysis tool.

Storage and Workflow

  • Aleph – OpenSource Malware Analysis Pipeline System.
  • CRITs – Collaborative Research Into Threats, a malware and threat repository.
  • Malwarehouse – Store, tag, and search malware.
  • MISP – Malware Information Sharing Platform curated by The MISP Project.
  • Viper – A binary management and analysis framework for analysts and researchers.


  • DC3-MWCP – The Defense Cyber Crime Center’s Malware Configuration Parser framework.
  • Pafish – Paranoid Fish, a demonstration tool that employs several techniques to detect sandboxes and analysis environments in the same way as malware families do.
  • REMnux – Linux distribution and docker images for malware reverse engineering and analysis.
  • Santoku Linux – Linux distribution for mobile forensics, malware analysis, and security.



Essential malware analysis reading material.


Some relevant Twitter accounts.


Related Awesome Lists

Reference :github

Original Post:

Anatomy of Paypal Phishing Attack

The phishing email

The email header

Received: by with SMTP id u125csp1210882oia;
 Fri, 29 Jul 2016 04:32:30 -0700 (PDT)
X-Received: by with SMTP id t66mr661693wmt.41.1469791950832;
 Fri, 29 Jul 2016 04:32:30 -0700 (PDT)
Return-Path: <>
Received: from ( [])
 by with ESMTP id v66si3080759wmf.69.2016.
 for <>;
 Fri, 29 Jul 2016 04:32:30 -0700 (PDT)
Received-SPF: pass ( best guess record for domain of designates as permitted sender) client-ip=;
 spf=pass ( best guess record for domain of designates as permitted sender)
Received: by (Postfix, from userid 500)
 id 77A34104353; Fri, 29 Jul 2016 13:32:30 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,HTML_FONT_SIZE_HUGE,
X-Spam-Languages: en
Received: by (Postfix, from userid 35301)
 id 8681717C0278; Fri, 29 Jul 2016 13:32:23 +0200 (CEST)
Subject: Unusual activity in your account
X-PHP-Script: for
From: Security Team <>
MIME-Version: 1.0
Content-Type: text/html
Message-Id: <>
Date: Fri, 29 Jul 2016 13:32:23 +0200 (CEST)

The phishing Paypal site

Without https of course, my firefox shows that hosting in Germary


The phishing IP information


The phishing site registration information


Try to login the phishing site


Login failed. However the “My Paypal” and “Log out” button at right top corner don’t work


After press the Continue button, it will brings you to update credit/debit card


The phisher wants all your information, have to add billing address to next step


The billing address page


The phisher will ask for remaining information of you


Congratulations! You have submitted all necessary information to phisher


Finally, the phisher will bring you back to the real Paypal website.


Final Thought:

The phishing campaign website design and quality is good. Phisher looking for high quality of data, many fields with validation, the data collection flow is nice.

To avoid trap by those kind of phishing email is easy, the website without https, and the domain name is very easy to identify.

Researchers find over 100 spying Tor nodes that attempt to compromise darknet sites


When it comes to accessing public websites, Tor has an intrinsic security problem: though the nodes between your computer and the public internet are unable to see where the traffic is coming from or going to, the final hop in the network (known as an exit node) gets to know what webserver you are connecting to.

If that final hop isn’t protected by an HTTPS connection — if it takes place without encryption — then all the traffic between you and the webserver are an open book to the exit node. It can see what you send and what you receive, and it can tamper with the connection (for example, it can inject malicious code that exploits bugs in your browser to take it over). If your session includes identifying information — your Google cookie, say, or a login and password — then someone running a spying exit node can figure out who you are without having to poison your session. This was much more of a problem when HTTPS connections were more rare, but now, thanks to the Snowden revelations and projects like Let’s Encrypt, much of the web is encrypted by default. That means that a spying exit node will only be able to see which server is being accessed, but not which page, and will not be able to inject code into the session, and will not be able to see the data going to and from the server.

There aren’t many exit nodes out there. Many people fear that running an exit node will put them in police crosshairs if it gets used in the commission of a crime. For the record, Boing Boing runs a very high-capacity exit node, and though we’ve received multiple contacts from US law enforcement, we’ve just explained that this is a Tor node that runs with logging switched off, and thus we have no information that’ll be relevant to any investigations, and the officers involved have thanked us and gone away without further trouble.

The lack of exit nodes means that if you run an exit node and want to spy on people, you can see an appreciable fraction of all the Tor traffic that goes to and from the public internet. Many governments, including the Chinese government, are understood to be running high-availability exit nodes that snoop on and log all the traffic they can see.

One answer to this problem is Tor “hidden services.” These are servers that have no public internet address; rather, they are accessed directly through the Tor network, without traffic ever being routed through an exit node. Because all this traffic takes place in the Tor network, without the intermediate nodes ever getting access to decrypted information, the sessions are considered very secure. Notorious darknet sites like The Silk Road ran as hidden services, and many sites maintain hidden service versions of their public offerings: for example, Facebook can be accessed on the Tor network via https://www.facebookcorewwwi.onion/, which resolves to a machine in one of Facebook’s data centers in Oregon, which is then bridged into the rest of Facebook’s system. By accessing Facebook over a .onion hidden service, you can disguise the fact that you’re visiting Facebook at all, and bypass censoring firewalls, like those used by schools, employers and governments.

However, hidden services are not without their own security issues. A pair of security researchers from Northeastern University have announced a paper(to be delivered at this summer’s Def Con hacker convention in Las Vegas) that reveals over 100 spying Tor nodes that were shown to be targeting hidden services.

These nodes — ordinary nodes, not exit nodes — sorted through all the traffic that passed through them, looking for anything bound for a hidden service, which allowed them to discover hidden services that had not been advertised. These nodes then attacked the hidden services by making connections to them and trying common exploits against the server-software running on them, seeking to compromise and take them over.

The researchers used “honeypot” .onion servers to find the spying computers: these honeypots were .onion sites that the researchers set up in their own lab and then connected to repeatedly over the Tor network, thus seeding many Tor nodes with the information of the honions’ existence. They didn’t advertise the honions’ existence in any other way and there was nothing of interest at these sites, and so when the sites logged new connections, the researchers could infer that they were being contacted by a system that had spied on one of their Tor network circuits.

This attack was already understood as a theoretical problem for the Tor project, which had recently undertaken a rearchitecting of the hidden service system that would prevent it from taking place.

No one knows who is running the spying nodes: they could be run by criminals, governments, private suppliers of “infowar” weapons to governments, independent researchers, or other scholars (though scholarly research would not normally include attempts to hack the servers once they were discovered).

“We create what we call ‘honey onions’ or ‘honions.’ These are onion addresses that we don’t share with anyone,” Noubir said. If someone visits the sites, it’s a good indication that their service has been picked up by a malicious HSDir.

At any one time, the pair ran 4,500 honey onions over 72 days, and found at least 110 HSDirs spying on hidden services. Some of the actors behind these weren’t just passive observers; many came back and then aggressively probed the hidden services.

“They’re looking for vulnerabilities in the web server,” Sanatinia said. Those attackers might look for cross-site scripting attacks, SQL-injection vulnerabilities, or just try to find the server’s status page, which can reveal lots of interesting, and potentially identifying, information about the site.

Most of the dodgy HSDirs the researchers found were hosted in the US, followed by Germany, France, and then other European countries. Of course, that doesn’t necessarily mean their operators are based in the same country; anyone can whip up a remote server from pretty much anywhere in the world. And because over half of the 110 nodes were hosted on cloud infrastructure, it’s not easy to immediately pin down who’s behind them.

Honey Onions: Exposing Snooping Tor HSDir Relays [Guevara Noubir and Amirali Sanatinia/Def Con]

Over 100 Snooping Tor Nodes Have Been Spying on Dark Web Sites[Joseph Cox/Motherboard]

(Image: Red onion closeup , Ogre, Public Domain)

Original Post:

Process Hallowing

In this article, we will learn what process hallowing is, how is it done, and how we can detect it while performing memory analysis.

Process Hallowing

It is a technique by which malware will replace a legitimate process with a duplicate process but with malicious code. The process helps the malware to hide among other legitimate processes. The new malicious process looks so similar to the original legitimate process that even the image name, path and command lines remain unchanged. Below are the steps usually followed for process hallowing:

  • First, target process is created in a suspended state using CreateProcess with CREATE_SUSPENDED option. After the process is created, its memory space can be altered with the handle provided. This handle will be referenced in all the subsequent function calls. Note that at this point malicious process is loaded but not yet executed because it was created in a suspended state.
  • Next step is to find the Process Environment Block (PEB section) for this malicious process which can be done using ReadRemotePEB helper function. After this is acquired, image base address is read to locate the NT headers.
  • Next step is to hollow the legitimate code from memory in the hosted process. For this NtUnmapViewOfSection is used. Because it is a kernel function, malware usually resolves the function at runtime using GetProcAddress.
  • Next step is to allocate a new block of memory to host malicious code. Malware usually makes the entire block PAGE_EXECUE_READWRITE for simplicity otherwise permissions can be set for each section as well.
  • Since space has been allocated for a new image, WriteProcessMemory is used to write the new image code in place of original image code. In the optional header structure, the base address will be changed to that of the new memory image. If however the image base of the new image does not match up with image base of original image then the image base of the new image need to be rebased.
  • SetThreadContext function is used to set the context of this process.
  • The last step is just to resume the process using ResumeThread.

Detection of Process Hallowing Using Volatility

Using Volatility plugin malfind

As discussed above, if the malware author forgot to fix the RWX protection on his malicious spawned process, then that can be detected by Volatility plugin ‘malfind’. Malfind looks for memory section that has PAGE_EXECUTE_READWRITE privileges and cannot be mapped onto the disk. It also dumps the assembly code at that memory section and final check to look at whether there is an executable code in the dump code is left for the analysts.

We first run the malfind plugin on a sample image and got following output

There is some clear process hallowing happened here. Multiple instances of lsass.exe are running where under normal circumstances only 1 should be running. To compare these with a normal lsass.exe we ran pslist plugin and got following output

Now process 680 has parent 624 and process 868 & 1928 has parent 668. Running a pstree will give us a good indication of parent-child relationship.

From above we can conclude that process 680 looks legitimate since it has a valid parent winlogon.exe and it was not present in malfind output. To further illustrate this, we will look at the dumped memory sections from process 868,1928.


Here we can see that both these has MZ header but cannot be mapped to disk (pre-requisite for malfind). However this MZ header can be easily manipulated by malware authors. To overcome this malfind gives you all the possible hallowed/injected section which Redline miss if the memory section does not have a MZ header.

It is worth to note that while performing memory analysis process hallowing and code injection looks very same.

Comparing the size of multiple instances of same process

We can even look at the sizes of all lsass process. First we will dump these lsass process using Volatility’s procdump plugin. Then we do a ls on the directory where we dumped all the 3 lsass processes. We can clearly see a difference in the size of the 680 vs. 1928 & 868.

After dumping these devices, I plugged it into a machine which has antivirus installed on it. McAfee recognized 1928 as a malicious process and as per set up policies as below

For other process i.e. 868 I submit it to virus total and it confirms that the process is malicious (39/54)

Comparing the processes with fuzzy hashing

We can even use fuzzy hashing to see how much of these processes match each other. With hashing like md5 we can only see whether an output matches or not but with fuzzy hashing we can see how different files are close to being the same. We will use tool ssdeep over the dumped processes in volatility.

Below is the ssdeep tool running over the executables dumped from volatility in above step.

Below we can see that process 680 has 0 match with process 868 & 1928.

So in this article we see how process hallowing is done and how we can detect it with volatility plugins and fuzzy hashing.

Original Post:

pytbull – Intrusion Detection/Prevention System (IDS/IPS) Testing Framework

pytbull is an Intrusion Detection/Prevention System (IDS/IPS) Testing Framework for Snort, Suricata and any IDS/IPS that generates an alert file. It can be used to test the detection and blocking capabilities of an IDS/IPS, to compare IDS/IPS, to compare configuration modifications and to check/validate configurations.

The framework is shipped with about 300 tests grouped in 11 testing modules:
  1. badTraffic: Non RFC compliant packets are sent to the server to test how packets are processed.
  2. bruteForce: tests the ability of the server to track brute force attacks (e.g. FTP). Makes use of custom rules on Snort and Suricata.
  3. clientSideAttacks: this module uses a reverse shell to provide the server with instructions to download remote malicious files. This module tests the ability of the IDS/IPS to protect against client-side attacks.
  4. denialOfService: tests the ability of the IDS/IPS to protect against DoS attempts
  5. evasionTechniques: various evasion techniques are used to check if the IDS/IPS can detect them.
  6. fragmentedPackets: various fragmented payloads are sent to server to test its ability to recompose them and detect the attacks.
  7. ipReputation: tests the ability of the server to detect traffic from/to low reputation servers.
  8. normalUsage: Payloads that correspond to a normal usage.
  9. pcapReplay: enables to replay pcap files
  10. shellCodes: send various shellcodes to the server on port 21/tcp to test the ability of the server to detect/reject shellcodes.
  11. testRules: basic rules testing. These attacks are supposed to be detected by the rules sets shipped with the IDS/IPS.
It is easily configurable and could integrate new modules in the future.
There are basically 5 types of tests:
  1. socket: open a socket on a given port and send the payloads to the remote target on that port.
  2. command: send command to the remote target with the python function.
  3. scapy: send special crafted payloads based on the Scapy syntax
  4. client side attacks: use a reverse shell on the remote target and send commands to it to make them processed by the server (typically wget commands).
  5. pcap replay: enables to replay traffic based on pcap files


Remote mode

In this mode, the IDS is plugged on the span port (or port mirroring) of the core switch and is configured in promiscuous mode. The IDS analyzes all traffic that goes through the core switch. Malicious files can be downloaded either by pytbull or by the server. This mode is called “remote”.

Local mode

In this mode, files are downloaded on the client pytbull is started from.

IDS mode with attacked server in DMZ

In this configuration, a firewall splits the network into 3 parts (lan, wan, dmz). The IDS is plugged in a span port (or port mirroring) of the switch with its interface configured in promiscuous mode. It will analyze every traffic that is sent to the LAN interface of the firewall.

IPS mode

In this configuration, a firewall splits the network into 3 parts (lan, wan, dmz). The IDS is plugged between pytbull and the firewall. To give the IDS a chance to detect the malicious files, pytbull has to download the infected files itself.

IPS mode with attacked server in DMZ

In this configuration, a firewall splits the network into 3 parts (lan, wan, dmz). The IDS is plugged between pytbull and the firewall. Malicious files have to be downloaded by pytbull directly to give the IDS a chance to detect them.


If you have selected the clientSideAttacks module (see configuration file section for more information), you will need to start the reverse shell on the server. Following command uses port 34567/tcp:

$ ./ -p 34567

Since the files are downloaded in the current directory, you can create a pdf/ directory and start pytbull from the parent location:

$ mkdir pdf/
$ cd pdf/
$ ../ -p 34567

Then start pytbull (on the client side). An example to start pytbull tests against, running Snort:

$ sudo ./pytbull -t

Notice that you will need to adapt (config.cfg) the port used by the reverse shell if you use the optional parameter -p on remote side.

Download pytbull

Original Post:

Blog at

Up ↑