Tuesday, February 9, 2016

SILICA NG

SILICA – Mapping access points (looking for Rogue APs)


We are happy to announce a new and exciting feature of SILICA that will be available with the 7.24 release (shortly!).

If you are in charge of protecting the wireless networks of a business, you often worry about rogue access points -  that is an AP that has been installed on your secure network without authorization.

SILICA's new AP Mapping is a feature that allows you to quickly and easily make a map of where the APs near you are placed. This feature not only is useful for finding rogue APs, but can also aid in detecting holes in wireless coverage, and also detect possible fake access points (access points external to the network that want to attack your wireless stations).

The user interface for the data entry part of this feature is simple. It consists of a map (or optionally you can just eyeball it on the blank canvas, which is what I always do) and buttons to control the beacon's capture and to determine the current location.

The user can record paths as he moves around the office, control the current wireless channel, view intermediate results, undo paths (useful after a miss-click on the map), and save the results to file. It takes about 30 seconds to figure out - after which you are merrily wandering your office with your SILICA laptop in hand mapping out every AP you can see.

You can make your maps in MS Paint or use Google Maps for high quality renditions. Or just start with a blank area (this still works).

The results section of this feature is rich in features. There are three basic map types that are produced, using the magic of math:

1) The Heatmap. This map is based on the estimated signal power of the access point that is most powerful in each location.




2) The AP Zones map. This map is based on what are the zones of influence of the more powerful access points. The zone of influence is the zone where one access point is the most powerful one.



3) The captured data map. This map show the signal power of access points in each location according to the beacon captures without interpolation or estimation. The user interface allows you to view this map for each access point, both for the average signal power and for the maximum signal power.



For the first two of the map types, the algorithm that SILICA uses to estimate the access points location and power are critical. There are various factors that influence the strength of the signal when received by the SILICA card: distance from the access point, obstacles that cause reflection or diffraction, relative angle of the AP's and SILICA's antennas, and interference from other sources. This means that the algorithm has to handle a very noisy signal, so we use a relatively simple algorithm to estimate the access point parameters - and also why it is best if you have more than just three or four points in your walk-path.

The first step is estimating the access point position, for this a number (at least 10) of the most powerful signals are averaged and the position and power are taken as the center of the signal.
To calculate the rate of power loss with the distance from the center, a linear approximation is used, using the least square regression method.

Finding out the zone of influence of each access point is more involved. A naive algorithm would be to calculate the estimated power for each access point and for each pixel of the map, and selecting the most powerful signal for each location, but this doesn't scale. What SIILCA uses is a divide-and-conquer method to find out the zones of each access point. This way, the graphs are quickly generated, even for high-resolution maps with many access points.

Example graph of how the map is divided in zones by the divide-and-conquer algorithm:


We hope everyone likes the new feature! More interesting updates are on the way, and if you want to ask questions about getting a SILICA, just email sales@immunityinc.com!


Tuesday, January 5, 2016

The Danger of "Other" on the iPhone

This is what it looks like when your whole organization just got compromised because you sat down at StarBucks for second.


So there's a lot of different ways to configure your email on the iPhone. Some of them are more dangerous than others. It took us a long time to track this down - because on wireless penetration tests we'd often get passwords using SILICA, and I never got to ask how that happened to the user. Many users don't feel like letting a penetration tester rummage through their phone settings.

One of these options is not like the other! Ok it is. Wait.

Literally a year went by and every time we got a password I asked the testers "HOW IS THIS HAPPENING?!?".

Here is the testing methodology which gets you a password every time:

  • Start SILICA
  • Add "attwifi" in the AP window
  • Right click attwifi and select AP->Service Impersonation
  • Wait about 30 minutes or less
  • Enjoy your new password!

I couldn't figure out why this worked so well. But now I know: Many people use IMAPS (even with Gmail), and to set that up they go to "other" as many web pages suggest you do, and they input all their information and ostensibly it is secure. The following images show what you probably have:



So what happens then is you, the user of the iPhone, will connect to AT&T wifi, and when you check your mail a little popup message will appear. It will offer you the option to "Continue". If you click that very natural button, SILICA will steal your password. It's just that simple. If you have your email configured any other way, then it won't even give you that option. Instead, it fails silently and securely, without giving anyone your password.

One of the reasons companies buy SILICA is for repeatable testability. Everyone can follow that simple methodology and test all the executive team's phones. It either works or it doesn't. It took a while to figure out what was happening, but without this, I wouldn't have realized what a severe issue it was, since the phones around the office are configured securely! :)







Thursday, September 17, 2015

Mobile applications instrumentation and reverse engineering, no-jailbreak style


With the advent of instrumentation frameworks such as Frida (1), mobile application assessment methodology has become increasingly sophisticated. Modern Enterprise environments almost always include a mobile device component and when performing a security assessment for the Enterprise, having the ability to rapidly introspect mobile applications is hugely beneficial to an assessment team.

Most Enterprise mobile applications are essentially just web service specific browser implementations in the sense that the application heavily interacts with a, often obscured, back-end web API.

Because the developers have in their heads an implicit assumption that only they are going to be peeking under the covers of their application, they often miss the subtle things that can be done with their API or the data they are sending to the mobile device.

So as a penetration tester, you can ask yourself these questions:


What data is available to the user of the application that could be used in a sensitive way. Is there geolocation data for other users? Is there information sent to the mobile device that is not displayed, but is highly interesting and can be correlated with other data to reveal something sensitive?

How much of the application's security is client side and not enforced by the server? This used to be common in web applications, but in mobile applications it is now a huge problem. Remember all the old bugs where you could set a price to -1 dollars and get something for free...
What rate limits are set on authentication attempts, if any?


Are there any input injection vulnerabilities in the back-end servers? Can I send weird data to another mobile device that confuses it?


These are all questions that you would ask in any web application assessment, but now, you want to ask them in the mobile world. And of course, these questions cannot be answered by automated static analysis, so exposing this to a human is a key feature of any toolset.

Having the ability to take an existing application and instrumenting it to interact with its back-end service in controlled ways hugely increases the ability to determine API semantics and attack surface scope without having to jump through a lot of code analysis hoops. It also allows you to quickly change the behavior of an existing application in an effort to make the back-end service perform actions it was never intended to perform or return data that was not intended to be visible to the end user.

Normally dealing with such analysis on mobile OSes can be frustrating as usually one would rely on the availability of public jailbreaks in order to jailbreak the device and then bypass the restrictions imposed by the mobile OS itself on outside application instrumentation. This is specifically true for iOS. But being too low level is a huge problem! You want to interact with the application the way the developers do - using the objects and functions they created!

As such, our consulting team has a reoccurring need to fully instrument and alter the runtime behavior of a given mobile application on iOS, but without having to rely on jailbreaks. This spawned the development of BLACKBUCK: a jailbreak agnostic iOS application instrumentation framework which we use to perform our mobile assessments (as you know if you are a customer :).

BLACKBUCK


BLACKBUCK builds on top of a variety of existing analysis frameworks. It currently links frida-gum, capstone and a ctypes bridging framework that allows us to interact with Objective-C directly from Python. BLACKBUCK is essentially an iOS injectable dylib that provides a runtime Python-based bridge into the iOS application's runtime internals including its Objective-C objects and methods.

BLACKBUCK currently only supports iOS. For BLACKBUCK delivery on non-jailbroken iOS we use a second Immunity tool which we called JOEY.

JOEY



The way you generally modify an iOS mobile application without relying on a jailbreak is to first obtain a valid certificate from Apple, then modify the target mobile app Mach-O binary so that it loads a custom dynamic library, re-sign and re-package everything, and then re-install the app to the device.

This is the general modus operandi for non-AppStore apps. Such as apps that are given to you by e.g. the Enterprise customer you are performing an assessment for and which lack the usual AppStore encryption layer. For AppStore based apps, you would first dump the decrypted application from memory and then proceed just as you would with a non-AppStore app.

JOEY automates the non-AppStore scenario, since there are already tools available to perform the memory dump rebuild for AppStore apps, JOEY currently does not include such functionality. It is, however, on the docket for a future release.

JOEY is written in PyQT and as such JOEY's front-end can run on anything that can run Python and the QT framework. The JOEY back-end has to run on Mac OS X which is where the actual code signing occurs.

The way JOEY works is very simple: you pass the original IPA package, the dylib you want to inject, and provide a destination path for the re-signed package. JOEY will then build the repackaged application it for you that includes your custom dylib.




BLACKBUCK IN ACTION


BLACKBUCK is written in Python and provides an API to interact with all the frameworks we rely on, which means we can directly access a lot of the features that are normally internal to e.g. Frida.

As mentioned previously we also have the ability to interact with Objective-C code directly from Python. This Python layer allows you to implement an Objective-C class entirely in Python, hook Objective-C methods with Python methods, and so on and so forth.

Currently you can interact with BLACKBUCK either by uploading Python modules to have them executed or imported, or by accessing the BLACKBUCK web interface.

BLACKBUCK web interface

The BLACKBUCK web interface is very useful and allows us to interact with and control our hijacked application via BLACKBUCK. You could also use the alternate interaction method (file upload) to upload a Python module and then import it into the runtime session to start inspecting and influencing the application.

So now that you have a basic idea of what BLACKBUCK is, let's have a look at a demo:



1. Frida - http://www.frida.re

Friday, June 12, 2015

Look for DUQU2 across all time and space!

If you are running El Jefe than you can just use the below script to test for any possible Duqu2 infections that have occured across your network for all time (assuming they didn't recompile specifically for you, which is very possible).

Any user of El Jefe can run this script by putting it inside the eljefe/webapp/scripts folder. Of course, if you get a hit, you can examine the machines that were infected much more closely in the GUI itself.

Happy "Hunting" :)







---CUT HERE---






import sys
import os

if "." not in sys.path: sys.path.append(".")
if "../" not in sys.path: sys.path.append("../")
if "../../" not in sys.path: sys.path.append("../../")
os.environ["DJANGO_SETTINGS_MODULE"] = "webapp.settings"

from home.models import binaries

evil_md5 = [
'14712103ddf9f6e77fa5c9a3288bd5ee',
'e8eaec1f021a564b82b824af1dbe6c4d',
'3fde1bbf3330e0bd0952077a390cef72',
'2751e4b50a08eb11a84d03f8eb580a4e',
'e8eaec1f021a564b82b824af1dbe6c4d',
'520cd9ee4395ee85ccbe073a00649602',
'acbf2d1f8a419528814b2efa9284ea8b',
'a6b2ac3ee683be6fbbbab0fa12d88f73',
'966953034b7d7501906d8b4cd3f90f6b',
'4b26441166f23bcced22cc0f8588b3dd',
'cf4a8212034fb2335dc069382fba1fb1',
'050fbef5c814b2981fa61b7fc6820cbd',
'0A566B1616C8AFEEF214372B1A0580C7',
'0EECD17C6C215B358B7B872B74BFD800',
'4541E850A228EB69FD0F0E924624B245',
'94C4EF91DFCD0C53A96FDC387F9F9C35',
'B4AC366E24204D821376653279CBAD86',
'E8D6B4DADB96DDB58775E6C85B10B6CC',
'0a566b1616c8afeef214372b1a0580c7',
'94c4ef91dfcd0c53a96fdc387f9f9c35',
'e8d6b4dadb96ddb58775e6c85b10b6cc',
'b4ac366e24204d821376653279cbad86',
'4541e850a228eb69fd0f0e924624b245',
'0eecd17c6c215b358b7b872b74bfd800',
'9749d38ae9b9ddd81b50aad679ee87ec',
'3d83b077d32c422d6c7016b5083b9fc2',
'C9A31EA148232B201FE7CB7DB5C75F5E',
'9749d38ae9b9ddd81b50aad679ee87ec',
'4c804ef67168e90da2c3da58b60c3d16',
'856a13fcae0407d83499fc9c3dd791ba',
'92aa68425401ffedcfba4235584ad487',
'c9a31ea148232b201fe7cb7db5c75f5e',
'f60968908f03372d586e71d87fe795cd',
'3d83b077d32c422d6c7016b5083b9fc2',
'bdb562994724a35a1ec5b9e85b8e054f',
'164aa9cd56d900341535551464af43b7',
'66a7e49ef0ebf10fb54621861c6dbfff',
'dccffd4d2fc6a602bea8fdc1fa613dd4',
'a0a976215f619a33bf7f52e85539a513',
'a1d2a954388775513b3c7d95ab2c9067',
'3B51F48378A26F664BF26B32496BD72A',
'4c804ef67168e90da2c3da58b60c3d16',
'f5ee03fed0133bb06d4cc52b0232fec0',
'9a9e77d2b7792fbbddcd7ce05a4eb26e',
"107403e1259427355757b70b4d820997",
"653e375d6455850fd76453dc5d713257",
"c03ca7ea50a52e9e7d1f3ff17e68f7da",
"45a7b2c4792803da5c79d61982e3ed38",
"9fce104aab41e80236b073f4db54910d",
"83b37e8df59051ee623da1c310fb4e8c",
"8d80ba2dce3bd625babc25858b55375d",
"af2b0ee182d9f48c293a80f762171d40",
"4a9f5b4f549f43d4f96136c81a043631",
"d4b3ef7b4d1c4b64c5146f02eab830a8",
"ef460a40c5d399942ae32c23e63a8d10",
"c80cd91848515b7973145a574440ca12",
"9bc2aa9eb49c938eb47660b087654b9c",
"75f0cda10d65f0865f92e9b7cd6a56de",
"4e69bf01720ae8c13c48943d1f512d8e",
"79fe76fc991a2f36e318c710e6684cca",
"aa6fcf2594393784f4602f9d1d8cbaa0",
"3af67c17dc76bcb7c7eb53b3e164a969",
"e4bb017843c538cc821162a4ef64d833",
"2684c847218745d2809d8c1c40588491",
"7d6fe14a4817d1eae16b926cd6af00b4",
"57090c92892406afe6207b6eefe44ce6",
"a6fd9fc574c4a2b592c82892e5aff77d",
"9daf29a0dd6eccec1093bef3fa3ec4f9",
"45a416431dadda14361eff64fa52afde",
"0c07e033975168de1ed461786a1bd4b7",
"05cfbb2cef37ac1f3cded2a54663e0c4",
"442d72f42e391c988e0fcda73488636a",
"0e51ef79713229c6df6ed567214e4bcb",
"ea05fd5e14bbb68be30d51d213f84f3d",
"bcae43d8f2d4f5b67a84da218aeddd0e",
"069701725a8fa9ab47a130e7e9879211",
"6ab58775a586249dcc608efa47e5eabf",
"9f5457c2514e3bcb61c4b6a14a507336",
"941b051d857cdafb4c2d04f6246cd7ac",
"d00fd4059c855d6c22a1d0a993d784af",
"5ffbf53cc0fa2c61b1cd8d48a57d976a",
"c81285c9763795df3b24ba1db002b352",
"934d5d68f0632531844fcd9180fa65f2",
"cee6703d62a6f334ecb9a43a2db904cd",
"dd5013f4537e7dcf3579ab125bbb48e3",
"4d8efdac702af5ff0c9edaad5401f567",
"b507fac3b8b94f7b0c6aedafd3a72cbe",
"d612393cda4228df8d43678171e273da",
"9a11b52ceee6f2fb1fa7f4fb5fee3c49",
"f4743b2df3c3e02dfbbd742475236033",
"8d2421d5518c16e392fbe9e2ef88419d",
"be04a3abec6f06761004053f13eed1b8",
"e09bad51cf748abdc1913367770a7a83",
"d5ce8c7456e444ef939a42be8e00a31c",
"dbe43f68bfb0e670cdcb4ede143db1ef",
"725b02ca7cfb061bfafccee3c15672c2",
"cb5cf3dbcadc6bae90830a6735ac2419",
"8f8054da6c80a2785d8c913ba1ea0a64",
"24ca17f51e73037aeb708ae96a4a939f",
"f624119e06773f4c88607f46fae3ebba",
"6edf091a408c33d7e9dd1e0341a3e19e",
"0d63aadacfdd57754b903af3a60627b8",
"2d54a71c7d4cd203dbdfcecd7329fc23",
"d1ec90731409c24c8fbdc5d1b39703bc",
"147126b7328ac42b0bfd6470ef809360",
"39b36b47e7afd8d7866ffe6466b2eb0a",
"2cf6ee0a02b34d2257d92b4c1501d61e",
"0d7156f407f57f92ba3aaa19bc3ef304",
"9e2add724fbe409429bdb0e212cdcc5e",
"f2e5987ab9db1c2f79a298636e1a87d2",
"f3d2dfa10cf1c7fc07bc76be98c1c008",
"52944779ddbbb31db9730b9971aeda06",
"6f967c2029844a9ba85de9fcb2c02b62",
"427168da8d933e125e43c50060d8ddd8",
"4bc2f1fa6d3bd027157f8b74dcee1910",
"2aedf87c810d05796cac4f8f92ffe9f0",
"0a9c596cace74595abbc630600c16827",
"5b64ea57526948dc9d2f9b59ead21181",
"13eaed09d79557b95daf74c845f2b957",
"8c52ffd05e83528cabae0ebd2e22b4f0",
"c96b80c1faa5986e5185ca0f1eefe7e4",
"de8eaa4b7960cc99b63eb0d4fef6b02b",
"b2f46de730bdd975094890dbea10184c",
"390d3abb7e34470a788b8972630d8583",
"823431ce0530d924fb96d3ca72685b07",
"f2c520cf776a69cf03bbfb4965de569f",
"efb33147c3ba73e1dd0ce6665a3257e4",
"9f430a2a8f74d37b5f488fb1eb001222",
"7a3041f198e1678c77efb3e8d628b6dd",
"2137d67f22aae1dc4b88f6d3269e991d",
"fb367a128574cb35c29099ebcec4635c",
"53a94a60f56591042c597b0078b127f9",
"1f17e12478cbec4e602426e37ab850bc",
"7b99589452f1852ec24d9a2320e18ddc",
"8dc6da7c18a59775ecd6522b5a4300b3",
"4623ac239145f8c8a1c4ab39f6bee2b0",
"9b13e9893cd890c6ac58b094582c2f82",
"01ee87ba582da9c38b1e9c27e97d9d2c",
"6ca125f46d1b443eca20574dd8695fba",
"9cf0bf3d7a4f9655205b3cc1a50fe1e7",
]

binaries_hashes = set([b.binary_md5 for b in binaries.objects.all()])
filtered_hashes = list(set(evil_md5))
print 'Found %d binaries' % len(binaries_hashes)
print 'Tesing against %d duqu md5 hashes' % len(filtered_hashes)

for md5_hash in list(set(filtered_hashes)):
    if md5_hash in binaries_hashes:
        print 'Found hash %s' % md5_hash

Friday, March 6, 2015

CANVAS - Psexec & Kerberos credentials

With the recent release of MS14-068 it became quite clear that a PSEXEC (sysinternals) module would be a fine addition in CANVAS. We wrote and released in CANVAS 6.99 a quite simple yet rather effective one with a couple of fine features.

1. PSEXEC and its basics

First of all let us remember how the original SysInternals tool works. A remote command (be it interactive or not) is executed following this procedure:

  • The PSEXEC client extracts out of its own binary a Windows service (PSEXESVC.exe) and uses the current user token (or alternate credentials) to store it in one of the writable SMB shares of the target, usually ADMIN$.
  • The client then uses the DCE/RPC API associated with the SVCCTL named pipe to create a Windows service associated with PSEXESVC.exe. This obviously requires ADMIN privileges on the remote host.
    • The client remotely starts the service.
    • Once started this service creates a control pipe (\PSEXESVC) on the target.
  • The client remotely opens this pipe using the SMB API. It reads and writes on it following an internal protocol.
    • An internal cookie is used to ensure that both the client and the server are using a same version of the protocol (this is mandatory in case the Windows service would be left running on the target). 
    • The service gets the knowledge of various options requested by the client such as the command to execute, if the command should be run with lower privileges, etc.
  • The service creates 3 named pipes and starts a new process whose STDIN, STDOUT and STDERR file descriptors may be redirected to the 3 aforementioned pipes.
  • The client connects to the 3 pipes using the SMB API and initiates a read polling on STDOUT/STDERR pipes. If necessary (CMD.exe), it will also write to the STDIN pipe.
  • When the new process' life is over, the service may be stopped and destroyed.
  • The service binary may be removed from the share.
That said, people usually either use PSEXEC to:
  • Execute a command (RCE)
  • Start CMD.exe (interactive shell)
For obvious reasons, in a security context such as a penetration test they rarely use the Desktop interaction feature.

2. Our PSEXEC module

2.1. Implementation of the RCE/interactive shell features

We chose to keep the original PSEXEC named pipes polling model to implement the RCE functionality in our module. This was not strictly mandatory as other ways to do this exist. MSF for example relies on the redirection of the standard output in a file which is later downloaded using SMB. We decided to use named pipes in order to anticipate future needs (and avoid leaving files on disk in the event of a disconnection, which is slightly better OSPEC). On the other hand, we decided to use a traditional MOSDEF connect back to mimic the interactive shell. This is exactly what was implemented in our MS14-068 exploit.

Both methods have their pros and cons:
  • The RCE only requires a client connection to the 445 TCP port. However the pipe management is not 100% perfect and side effects may sometimes be observed with the current version. 
  • The MOSDEF shell is quite powerful (it includes the RCE and interactive shell abilities) but may not be possible if egress filtering is used. While you might eventually be able to disable the Windows firewall of your target using the RCE, there is nothing you could do against an external equipment.
Note: The choice between both of them is done by filling the "cmd" parameter. If "mosdef" is specified, then the MOSDEF connect back is used otherwise what ever command is specified will be executed (if possible).

2.2. The authentication in SMB


This module provides two ways to authenticate the user:
  • Using NTLMSSP (login + password)
  • Using Kerberos (login + password + domain OR login + domain + credential file)

The NTLMSSP authentication may use the plaintext password or the NTLM hash of the password. This is the so called pass-the-hash technique as shown below:

Computing the NTLM hash

Using the NTLM hash in the CLI

The Kerberos authentication is used in two cases:

  • Implicitly as a fallback method if the NTLMSSP fails (this can happen with domain policies enforced) but only if the user had also specified the domain FQDN (which is not mandatory with NTLMSSP).
  • Explicitly if we have Kerberos credentials (potentially retrieved using post-intrusion tools) and we intend to use them. We decided that these credentials would always be stored in a UNIX ccache file because we had done the effort to write an API for MS14-068. 
To illustrate the situation, let's generate artificial ADMIN credentials (basically the TGT of the domain administrator) using kinit in the IMMU4.COM domain:

Artificially generating a Kerberos TGT
We can then fill the appropriate field in CANVAS to specify these credentials:

Using a Kerberos credential file to compromise the target
And we finally get our node popping:

Target is owned!

2.3. Upload and execution of a specific binary

In a few cases, you may want to run your own binary on the target. Our module will take care of both the upload and the execution of this specific binary. It will basically be seen as a specific RCE.

Several options may be specified either on the command line or using the GUI:
  • The command and argument to execute (cmd)
  • The local directory in which is stored the binary to upload (local_upl)
  • The directory in which should be stored the binary once uploaded (remote_path_upl)
For example, suppose the user is running this command:

$ python exploits/psexec/psexec.py -t 192.168.0.1 -p 445 -Ocmd:"mybinary mybinaryargument" -Ouser:administrator -Odomain:IMMU2.COM -Okrb5_ccache:/tmp/krb5cc_1000 -Olocal_upl:/tmp/BABAR -Oremote_path_upl:"C:\\"

Then /tmp/BABAR will be uploaded in C:\\ as mybinary.exe (the .exe suffix being automatically added) and executed from this directory.

3. Stealing credentials using "kerberos_ticket_export"

We wrote a command module that allows us to detect the presence of kerberos credentials on both Windows and Unix targets. This module is used to list the credentials that are associated with a compromised account under which is running the MOSDEF callback:
  • If the node is a Linux/BSD system, all the Kerberos tools will be using standard MIT libraries which store credentials in specific directories (for example /tmp/krb5cc_%{uid} on Ubuntu/FreeBSD).
  • If the node is Windows we use LsaCallAuthenticationPackage() in a MOSDEF-C payload.
Here is a little demo:



We also wrote a similar module to actually extract the tickets and convert them (if necessary) to ccache files. This is where PSEXEC comes to play. Both modules are quite similar:
  • Exporting credentials on Unix systems basically means copying a file that we can immediately reuse. The ccache file may include a TGT but also one of several TGS.
  • On Windows systems, we are (currently) limited to TGT extraction. Basically we keep using LsaCallAuthenticationPackage but with different parameters. This may allow you to extract the TGT and the associated session key. In a couple of circumstances and for security reasons that we may explain in another blogpost, the session key cannot always be retrieved in which case the TGT is useless. Once the TGT, the session key, and other parameters are extracted, we use our ccache API to build and store the tickets locally (in a session directory).
The following screenshot illustrates the ticket extraction:

Ticket is extracted and saved (oops small typo in the module code :P)

And the subsequent use of PSEXEC to own a new node:

The previous relative path is specified (although cut by the GUI here)

4. Last words

The Kerberos ticket modules are currently in an early stage of development. There is lots of room for improvement including full 64 bits support, corner case situations and privileged account related tricks. As for the PSEXEC module itself, we may add a couple of features such as a "runas" option.