A transform is a small piece of code that fetches related information for a given input, and formats the results to be returned as entities to Maltego.
- Be extensible (so that other transforms can run of their output)
- Return the smallest piece of information possible.
The reason we emphasise small pieces of information is that it means we can harness the power of Maltego's link analysis. Take the two images below as an example (they merely show IP addresses as well as ports):
The graph at the top has a whole layer less, whilst showing the same information. Using the second graph allows the analyst to quickly look at things like all the services running on port 80. Doing the same on the graph at the top would mean you would have to traverse up the tree to the IP addresses and then down again to the services giving you other services that are not running on port 80. Modelling your data correctly is a very important step in the process of building your own custom transforms. It is advised to give this step some thought before moving on with actually writing code for your transforms.
There are two ways to build transforms, namely ITDS transforms and local transforms. Each method of building transforms is described in the sections below:
An iTDS allows you to combine Maltego transforms, entities and their configurations into a single item that can be distributed and installed by different Maltego users. This makes it easy to share custom transforms and configurations amongst a team of analysts or, should you choose so, with the rest of the world by joining the transform hub. The iTDS is configured and managed using a web-interface and allows you to configure transforms in a single location, and they are automatically updated for anyone using them in their Maltego clients. Continue reading about iTDS by clicking here.
The pros and cons of iTDS transforms vs local transforms are described in the list below:
- Once setup transforms are easily distributed to multiple Maltego clients.
- No configuration needed client side, scripts all live in one place.
- Updating instantly impacts all clients.
- Deeper into the protocol (Slider value + Transform settings/Popups)
- Cannot integrate with applications local to the Maltego client.
- All requests come from a single point (may impact things like rate limiting APIs etc).
- Server infrastructure setup is required.
Public vs. Private iTDS
The public iTDS is located on the Internet and is free for all to use. It’s a convenient way to immediately start writing remote transforms. Since this server is located on Paterva’s infrastructure data will be flowing from the Maltego GUI to this server and finally to your transform code hosted on a web server of your choice. The server interface can be reached here.
For those dealing with sensitive internal data that cannot go over the Internet or over Paterva’s infrastructure we offer a private iTDS. The iTDS provide the same functionality as Paterva’s public iTDS however it can be hosted internally on your own infrastructure.
Local transforms are pieces of code that run on the same machine that the Maltego client application is on. These are very useful for integrating in machine specific tasks (such as running an application that's locally on the machine- like NMAP OR a task that is dependent on a setup on the machine such as accessing data over a VPN). These transforms can be written in any language (yes, *any* language) and merely rely on output to be sent via STDOUT (think a command line application).
Below are the advantages and disadvantages of building local transforms.
- Machine Specific.
- Nothing ever goes 'over the wire' - unless you want it to.
- Simple to write in any language.
- Does require any server infrastructure setup.
- Requires setup on each machine you wish to install them, eg. Python + Mechanize + BeautifulSoup
- Does not go as deep into the Transform Specification - no slider or settings.
- Updating a transform means it needs to be updated on every machine.
- Sensitive data such as usernames and passwords could reside on the computer of the analysts.
Sample Transform Response
The most simplest response should have an entity tag with at lease one entity and its value. It is a good practice to send weight of that entity too but it can be skipped.
<MaltegoMessage> <MaltegoTransformResponseMessage> <Entities> <Entity Type="maltego.Phrase"> <Value>Some Text</Value> <Weight>100</Weight> </Entity> </Entities> </MaltegoTransformResponseMessage> </MaltegoMessage>