Wednesday, April 20, 2016

Abracadabra! It's Sho(dan) time!

Shodan -- used by pentesters, stalkeˆWˆWˆWresearchers and data scientists everywhere to analyze information about computers on the Internet. From webcams to SCADA to looking at where various SSL information in certificates can tie organisations together. It is a common tool used by many different people. We really wanted to get some Maltego goodness on that!

TL;DR -- You can get the Shodan transforms in the transform hub right now. To use all of the different transform options (or you can stick with the free options) you can simply click on settings in the transform hub after installing to add your API key.

There have been transforms written for Shodan before, but we really felt like they needed refreshing. So we took it upon ourselves to look at the information provided by Shodan and decide how we could integrate it into the needs of Maltego users. We first started by looking at what information was readily and easily available and then if it was useful in an n-th order graph. This is what we came up with.

(Please note these screenshots are from the newest closed beta of Maltego 4 -- it's coming soon!)

IP Information


Taking an IP address you can identify various pieces of information for that IP address, these are broken down into the following:

  • Service - A service is an application running on a particular port and is represented as <port>:<banner> in a new maltego.Service entity. If the banner is unknown the text "<unknown>" is displayed.
  • Hostnames - Any hostnames enumerated by Shodan will be displayed. Most often this is the reverse DNS for the IP address.
  • Owner Details - This will return two phrases (unless they are the same), one for the ISP and one for the organisation identified by Shodan.
  • Location - If GPS and Location variables have been identified these will be returned as one or two different entities.
  • AS -  Returns the AS number for the IP address in question.
With this kind of information and the power of Maltego it means you can easily to do link analysis across a large number of IP addresses (and later networks!) ... fantastically. Graphing information such as common services, owners or locations means that even if the machines you are investigating/targeting are on disparate networks you can find connection between them. It is of course still up to the analyst to identify if the connections are valid or not. 

An example of this could be something like looking at the infrastructure of the NSA (starting with nsa.gov) and performing a simple footprint with Maltego ( Domain -> DNS -> IP Addresses). Once we have the IP addresses we can run the "To Shodan Details" transform and see the following:


From here we can switch to 'bubble view' (replaced in M4) to get an idea of the most common nodes, and we see the usual suspects, Layer 3 communications (a T1 provider ), the AS used and a number of machines running what looks like webservers:


Above example shows the ability to correlate - however it may be even more interesting to look at machines that did not match the more common nodes. Looking at these you can quickly identify 'the odd one out':



Netblocks
The ability to send a netblock to Shodan and have it return IP Addresses it has found within a particular range is phenomenally useful. As such we have included this transforms within the pack! What it gives you is the ability to take a large network space (think multiple Class A/B's) and have only a small subset of that returned. This is usually interesting as the results returned show only the populated space in the netblock -- Shodan does the pre-scanning for you!

Keeping with our previous example of the NSA, if we take a handful of IP addresses within the 8.44.101.x network space found previously:

8.44.101.21 - remoteoffice1.nsa.gov
8.44.101.8   - smtp.nsa.gov
8.44.101.9   - smtp.nsa.gov
8.44.101.5   - dsdn-gh1-uea05.nsa.gov
8.44.101.20 - remoteoffice.nsa.gov
8.44.101.6   - dsdn-gh1-uea06.nsa.gov
8.44.101.22 - remoteoffice2.nsa.gov

If we now run the transform "To Netblock [Using natural boundaries]" to get the  class C those are in (or do it manually), which returns 8.44.101.1-255. 

From here you can run to "toIPs [Shodan]" and you will see the following in the ouput window:


As you can see from this example we're using a free API key and our results are limited to 100 but you can use your own paid-for key to get all the results available! Even with just the first 100 results (of 198) it means we have already managed to narrow down our space further.

Now we can look at the results and perform tasks such as looking at the reverse DNS names (with the transform "To DNS Name [Reverse DNS]") and already get new DNS names we previously did not find such as emvm-gh1-uea08.nsa.gov and eas.nsa.gov.


Service/Port Splitting


One thing you might notice about the first example is that there is a service entity returned that contains the details in the format of <port> : <service> . There are two additional transforms included in the Shodan transform hub item that will break these apart into the various ports and services. This allows you to quickly visualize which ports and applications are more commonly used.

If we look at an example quickly mapping defense.gouv.fr to DNS, then to IP addresses as we did above we see something like the following:


From here however it becomes more interesting as we can take each of the services to a port and banner and within bubble view examine the common infrastructure on a port and service level:


Typically you would see something like the graph above where there are a lot of port 80's running an HTTPd of some kind, but it is interesting to see things like port 81,82,83 and 84 as well. In this case these all seem to be a standard webmail configuration. A graph like the one above however is filled with additional interesting artifacts...

Further Port Manipulation


From a port entity (either in your existing graph or dragging it in from the palette) you can also run transforms that identify other IP addresses running services on that port. For example if we look at S7 devices (from https://icsmap.shodan.io/) we can see that they generally run on port 102.

In Maltego we add the port to our graph and run the transform to IPs From Port [via Shodan]. This gives us the option of adding additional terms in the query (that might be found in the response) as well as the country code as seen below:


From here we get a number of results back for IP addresses that have services running on port 102. We can then take each of these services to the details for those IP addresses and visualize the results to identify commonality between them. Here we can see that a lot of the machines running the Siemens S7 devices on port 80 also have VNC listening on port 5900.



Native Shodan Queries


In addition to the above queries we have also included the ability to search for your own custom terms or use a more guided version of the transform.

The first is the advanced search - this transform will send the terms you specify in a phrase entity directly and unmodified to Shodan. For example if you started with the phrase "National Security Agency" and wanted to see all results that contained that exact string you could run the "to IPs via Shodan [Advanced Search]" transform. This would return the following:


You can also see in the detail view that the text Basic realm="National Security Agency" is seen within the IP address highlighted. You can view additional key terms used by exploring the Shodan API documentation at https://developer.shodan.io/api and viewing the keywords available under the  /Shodan/Host/Search heading.

If you would prefer to be guided through the four terms we use (ssl, hostname, org and isp) you can run the transform "to IPs via Shodan [Basic]" which will allow you to specify the terms you want. You can use a space ( " " ) for terms you wish to exclude. 

PLEASE NOTE:  The free API will only allow you to use one term at a time. To use more terms you need your own API key.

Let's see how this works. If you used the phrase "NSA Search" (remember this can be anything as we are doing the basic search), and you filled in the terms as shown below when running the transform "to IPs via Shodan [Basic]":


You would receive the following in your response:


Here you can now run the standard IP to Shodan details to get the details of each of these IP addresses, and as we were searching for any DNS Name containing nsa.gov we get the following out:

nsaoa.nsa.gov.cn
msux-gh1-uea02.nsa.gov
ns2.nsa.gov.cn
cli456.nsa.gov
emvm-gh1-uea09.nsa.gov
www.nsa.gov.pl
...list truncated...

Keep in mind that Shodan returns *anything* that contains the word nsa.gov - so entries like nsaoa.nsa.gov.cn are also returned!

Domain Queries


The last two transforms are more an incorporation of the previous ones where we will use two specific Shodan keywords (namely 'ssl' and 'hostname') to search through any results found for additional DNS records that we might not have seen before using the other DNS transforms. These are uber useful, especially with certificates (the ssl keyword) to find specific machines on the Internet.

If we run the two transforms we get a nice subset of DNS names (that we had also seen before) with just two simple transforms (To DNS Names [Via Shodan] and To DNS Names SSL [Via Shodan]) -- Abracadabra! 



Adding Shodan Transforms:

To add the Shodan transforms it's as simple as going to the transform hub item and clicking on "Install":



API Keys:

Shodan API keys are free with limitations for any user on the Shodan website and registration is completely free. The limitations of the free API key are as follows:
  • Only the first 100 results per query
  • Advanced keywords can only be used one at a time (ie you cannot search for a dns name within a particular country)
Registered users (a once off fee) do not have these limitations (apart from a certain number of lookups per month on a  registered key) and the project is really useful so we would encourage you to signup.

To add your API key you can simply click on "settings" within the transform hub and enter your key.


May your english be fluid and your dancing be premium. Use responsibly!

-Andrew


Tuesday, April 12, 2016

Visualising the Bitcoin Blockchain in Maltego

This post will provide a quick overview of our new Maltego transforms for visualizing the Bitcoin blockchain. There are 11 new transforms in the seed which use Blockchain.info’s API to query data from the blockchain.

(Screenshot's in this post are taken with the Maltego 4 beta release.)

Before we begin, it is important to have an understanding of how Bitcoin and their transactions work so I will start with an overview of some of the main concepts:

Bitcoin Overview


Bitcoin address:
Bitcoin addresses are transaction endpoints that are used to send Bitcoin to another person. A person can generate as many addresses as they want and people should (which they often don’t) use a new address for every transaction that is made. An address is represented with a 26-35 sequence of alphanumeric characters and looks like this: 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2. For a more in-depth explanation of Bitcoin addresses you can have a look at the Bitcoin Wiki here.

Bitcoin wallet:
A Bitcoin wallet is a file that contains a collection of private keys that are used to generate bitcoin addresses associated with the wallet. Ownership of these private keys allows the user to spend bitcoin that have been sent to associated addresses. Naturally these private keys should be kept private.

Bitcoin transactions: 
The Bitcoin Wiki has a good explanation of a Bitcoin transactions here

A transaction is a transfer of Bitcoin value that is broadcast to the network and collected into blocks. A transaction typically references previous transaction outputs as new transaction inputs and dedicates all input Bitcoin values to new outputs. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block. Standard transaction outputs nominate addresses, and the redemption of any future inputs requires a relevant signature.

Misconceptions about Bitcoin:
Addresses are not wallets and technically do not have a balance. However most blockchain explorers that you find online will specify an address's balance as the amount of Bitcoin that the address has received minus the amount of Bitcoin the address has sent.

Address attribution:
A single Bitcoin address is only intended to be used for a single transaction, however a lot of the time people will reuse addresses. Address reuse has numerous associated problems including making it easier for people to identify the owner of a particular address. Some Bitcoin services allow users to add tags and meta information about addresses that they know. This information can be publicly queried which provides a useful way for attributing an addresses back to its owner. Keep in mind that this information can be edited by anyone and therefore should not be fully relied upon without further analysis. Our Bitcoin transforms will check for tags associated with addresses and if found will return them in an entity note.

Transform List


The Bitcoin transforms include two new entity types, namely a Bitcoin Address and a Bitcoin Transaction.



Transforms that run on a Bitcoin address:
  • (Bitcoin) Get Address Details – This transform will return additional information about a specific Bitcoin address and adds this information to the address entity's detail view.
  • (Bitcoin) To Addresses [*Received from] - This transform returns Bitcoin addresses that were inputs to transactions where this address was an output. Essentially this transform returns Bitcoin addresses that sent Bitcoin to your input address.
  • (Bitcoin) To Addresses [*Sent To] - This transform returns Bitcoin addresses that were outputs to transactions where this address was an input. Essentially this transform returns Bitcoin addresses that received Bitcoin from your input address.
  • (Bitcoin) To Addresses [Received from][Using Taint Analysis] - The taint relationship between two Bitcoin addresses is represented as a percentage and indicates how closely related two addresses are. This transform allows the user to specify a taint relationship threshold (in %) and returns Bitcoin addresses that have sent Bitcoin to your input address with a higher taint relationship than what was specified in the transform setting.
  • (Bitcoin) To Addresses [Sent To][Using Reversed Taint Analysis] - This transform allows the user to specify a taint relationship threshold (in %) and returns Bitcoin addresses that have received Bitcoin from your input address with a higher taint relationship than what was specified in the transform setting.
  • (Bitcoin) To Transactions [where address was an OUTPUT] - Returns transaction hashes where Bitcoin address was an output of the transactions (receiver).
  • (Bitcoin) To Transactions [where address was an INPUT] - Returns transaction hashes where Bitcoin address was an input to the transaction (sender).

Transforms that run on a Bitcoin transaction:
  • (Bitcoin) To INPUT Addresses - This transform will return the input addresses for the Bitcoin transaction.
  • (Bitcoin) To OUTPUT Addresses - This transform will return the output addresses for the Bitcoin transaction.
  • (Bitcoin) To IP Address of First Relay - This transform returns the IP address of the node which first broadcast this transaction to BlockChain.info. This does not necessarily mean that the IP address returned is the true source of the transaction.
Transforms that run on a URL entity:
  • (Bitcoin) To Bitcoin Addresses on Page - This transform will pass any Bitcoin addresses found on a specific webpage.

Using the transforms


Let’s have a look at an example of how we can use these transforms in a practical scenario. Starting with the address 1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX which is allegedly the SilkRoad Seized Coins address. Running the transform (Bitcoin) Get Address Details returns the following information about the address as well as a link to open the address in a blockchain explorer.




Next running the transform (Bitcoin) To Addresses [Output to transactions] to get all the addresses that were outputs in transactions where this address was an input. Running this returns a single address that includes meta data stating US Marshal Auction Coins. The meta data for this address also includes a link that provides more information about the alleged owner of the address.



In the detail view of the returned address further information about the transaction that links these addresses is included.



Going directly from an address to another address, like we have done here, is a bit of a shortcut as we miss out on including the transaction entity on the graph which is the link between these two addresses. An alternative method would be first running the transform (Bitcoin) To Transactions [Where address is an INPUT] which will return a Bitcoin transaction entity. From the transaction entity we could then run the transform (Bitcoin) To Transactions [Where address is an OUTPUT] which will return us the same US Marshal Auction address entity that we had previously.



Most of the time you won’t actually be interested in taking the intermediate step of getting the transaction entity first and you can just run the transform that takes you straight from one address to another.

Next let’s go back to our original address and run the transform (Bitcoin) To Addresses [Inputs to transactions] which will return Bitcoin addresses that were inputs to transaction where this address was an output.

*small portion of the graph


As you would expect we get a large number of addresses back (remember this address was allegedly used on Silk Road). The transform returns the maximum amount of entities of 10 000. The entities that are returned are weighted according to how many transactions they were involved in with the input address making it easier to pick out the addresses that are most related to the input. The entities that are most related will appear in the top left of the block layout while the least related entities will be found at the bottom right.

Finally let's have a look at the transforms that make use of Blockchain.info’s Taint Analysis data. These transforms allow you to return addresses that have either sent or received bitcoins to or from a particular address. Additionally these transforms have another parameter called Taint Relationship which is measured as a percentage and represents how strong the link is between the addresses. Running the transform To Addresses [Using Taint Analysis] on our address while specifying a Taint Relationship of greater than 1% results in the three entities below being returned.



API keys for Blockchain.info:
By default the Bitcoin transforms use Paterva's API key which is subject to being rate limited by Blockchain.info. If our API key does get rate limited you will receive a message returned from the transform indicating this. To reduce the chances of being rate limited you can sign up for a free  API from Blockchain,info and enter it in the blockchain.info APIKEY transform setting. Please also note that the endpoint used for Taint Analysis is heavily rate limited.

You can install the Bitcoin transforms to your Maltego client from the transform hub simply by clicking Install:



As usual enjoy responsibly.

PR

Thursday, April 7, 2016

NameChk Transform

NameChck is a really useful service for quickly finding online accounts associated with a specific alias. This blog post showcases our new Maltego transform that queries NameChk to find social accounts across a wide range of social networks.

The transform runs on an alias entity and returns entities that represent different online accounts.  Running the transform To Social Account [Using NameChk] on the aliases used by Paterva employees returns the results below:



Clearly Andrew is the most socially active Paterva employee...;)

In the Detail View of the entities that we get back there is a link to the actual social account:


Pivoting from existing alias entities


In Maltego we already have a couple of transforms that are useful for finding aliases associated with a person. Our Flickr and MySpace transforms both run on email addresses and return the accounts associated with the address as well as additional aliases that are used on that account. This provides a great way for finding aliases that a person might go by. Next with the use of our new NameChk transform we can quickly pivot from these aliases to find what social networks they have been used on.

In the example below we start by running the transform emailToMySpaceAccount on the email address andrew@punks.co.za which returns a MySpace account entity as well as three additional aliases associated with the account. Namely zapunk, AndrewMacPherson and Andrew MacPherson. The alias AndrewMacPherson is quite common and could be anyone however the zapunk looks interesting so next we run the transform To Social Account [Using NameChk] which returns links to 10 different social accounts that have a user with the alias zapunk.


These social accounts can now be manually inspected for accuracy.

API keys


The NameChk API is subject to rate limiting. By default our transform will use Paterva's limited API key but to avoid being rate limited you can register your own API key from the NameChk website. You should then replace the default value with your API key under the NameChk APIKEY transform setting.

Getting the transform


Simply click on the 'Update transforms' button in the Transform Hub next to the Start Page - the NameChk transform is part of the standard transforms supported by Paterva.


Enjoy responsibly,
PR