The basics [Back to Top]

A pipeline is a sequence of filters and transforms. Looks at the following example:

//simple machine
machine("maltego.test", 
    displayName:"Testing it", 
    author:"Roelof Temmingh",
    description: "This is simply a test machine") {

    start{
	run("paterva.v2.DomainToMXrecord_DNS")
	run("paterva.v2.DNSNameToIPAddress_DNS")
	run("paterva.v2.IPAddressToNetblock_Cuts")
    }
}

From the example we can quickly see that ‘//’ is used to comment code. You will also see that each machine has a unique name, display name, author and a description. These are used to describe the machine and translates it showing up as follows:

   

In the example there are three transforms that are executed – top to bottom. The first one takes a domain name as input and generates an MX record. At that stage in the pipeline we have an MX record, so the next transform takes the MX record to an IP address which in turn is transformed into a netblock. The resultant graph looks like this (we used ‘paterva.com’ as input):



The pipeline looks like this (always left to right):



It’s important to know that the pipeline does not accumulate entity types. It ONLY contains what the previous step has generated. This is also true for filters which we’ll get to later.

 

Parallel paths [Back to Top]

To run transforms in parallel we’ll use the ‘paths’. Again, let’s look at an example:

 start{
	paths{
            run("paterva.v2.DomainToMXrecord_DNS")
            run("paterva.v2.DomainToNSrecord_DNS")
            run("paterva.v2.DomainToDNSName_DNSBrute")
	}

	//now resolve these to IP addresses
       run("paterva.v2.DNSNameToIPAddress_DNS")
    }


The pipeline for this looks as follows:



The resultant graph (running on ‘facebook.com’) looks like this:



Note that there are MX, NS and DNS Name records on the graph.

It’s important to note that because the MX record entity and the NS record entity inherit from the DNSName entity all of them can be resolved to IP with one transform.

Whenever you want to split a pipe into two or more sections the syntax is as follows:

paths{
	Parallel-1
	Parallel-2
	..
	Parallel-N
}



Commands inside the curly brackets will be executed in parallel.  

Serial Paths [Back to Top]

This is all fine but what when we want to do something like this:



The problem here that there is a sequence of transforms that’s within their own pipeline but that has to be executed in parallel. In Maltego scripting language this can be achieved as follows:

path {
	run("paterva.v2.DomainToMXrecord_DNS")
	run("paterva.v2.MXrecordToDomain_SharedMX")
}
path {
	run("paterva.v2.DomainToNSrecord_DNS")
	run("paterva.v2.NSrecordToDomain_SharedNS")
}



From this example you can clearly see that each ‘sub pipeline’ is in a ‘path’ clause, but that these run in parallel.
The resultant graph when run on ‘logica.com’ looks like this:



From this graph is becomes apparent that some form of user filtering is needed before we proceed with next steps. In this example the NS records ns1.logica.com and ns2.logica.com yields good info, but Logica also uses MarkMonitor as a NS and looking at shared domains there is pretty useless. We cover filters in subsequent sections – keep reading!

 

Transform settings, slider values [Back to Top]

Transforms can optionally be passed extra information. Slider value (how many results to return) as well as transform settings can be specified:

run("transformname",slider:N)
//will run transform and <= N number of results will be returned

Let’s look an example:

run("paterva.v2.MXrecordToDomain_SharedMX",slider:255)

Transform settings can we specified like so:

run("transform", "setting_name":"value")
//will run transform with certain transform settings

As an example:

run("paterva.v2.DomainToDocument_SE","engine":"google",slider:50)


The setting’s actual name (e.g. not the display name) can be found in the transform manager:




Filters »