The Nightmare Before Charlie Brown’s Christmas – Answers and Winners

| January 26, 2011


Hello, challenge fans!  Ed Skoudis and Yori “Skellington” Kvitchko here, with our announcement of the answers and winners from the holiday hacker challenge The Nightmare Before Charlie Brown’s Christmas.  In past challenges, we typically showed our answers first, followed by the winner announcement.  But, we know that everyone instantly jumps down to the winners first (we can tell this using the Metasploit-based tracking software we clandestinely installed on each of your systems while you read our packet captures – JUST KIDDING!).  So, in a topsy-turvy fashion for a change of pace, we’ll first announce the winners, and then provide our answers to the challenge.

As usual, this year’s competition was intense, with some of the smartest and most clever folks we’ve ever seen participating.  Also, many of you had a nice scent as well (we can tell via the new Meterpreter smell-o-matic script included in the payload of our tracking software; thanks for coding that one up, Carlos).  Our respondents included tried-and-true experts who have worked through many challenges in the past, intermixed with freshly minted newbies impressively building their skills, and everyone in between.  Many people commented that the challenge really helped get them engaged in VoIP attack analysis for the first time, which is one of the primary reasons we write these darned things.  Even if you didn’t win, we do hope that your had fun and learned some valuable lessons about VoIP (in)security.

–Ed Skoudis Challenge Master
Author of Counter Hack Reloaded, Co-Founder, InGuardians, SANS Instructor

Active Image
Active Image

Discuss in Forums {mos_smf_discuss:December 2010 – The Nightmare Before Charlie Browns Christmas}


By Ed Skoudis & Yori Kvitchko

Answers & Winners

Winners & Answers

Honorable Mentions

Given how intense the competition was, those who received an honorable mention truly deserve special praise!  Judging is difficult when we have so many great answers, but we really worked hard to analyze every aspect of the submitted entries.  A hearty “Job Well Done” to the following folks:

Mark Hillick: Your answers were all really good, and you especially shined in your answer to Question #5 (the open-ended one, which always stumps many folks).

Mark Baggett: You always do top-notch work, my friend! Your command-line kung fu and awesome Scapy-ness were fantastic.

Delhayne: You nailed every question correctly, and obviously know your stuff.  While your answers weren’t as detailed as our first place winner, you really did great.

Theodore Reed: You did an AWESOME job of identifying many of the subtleties of the attack! You were a very close second place.

Technical Winner

And that leaves us with our ultimate winner, the grand champion, the king of the hill, the top dog, the prima donna, the man with the plan…. Drum roll please…

Ron Bowes

Ron, who was supported in this feat by his happy team of hax0rs (Mak Kolybabi, Andrew Orr, and Russ Tait Milne) at their newly commissioned hackerspace named SkullSpace Winnipeg in the frozen tundra of Canada.  SkullSpace sounds like the kind of place where Jack Skellington would feel much at home.  Your analysis identified a huge number of fun points of the attack, and is a must-read for any participant in the challenge to learn about different ways of approaching the problem.  Our hats are off to you!

Creative Winner

We always love the creative entries to the contest, because they give people a chance to shine not only technically, but also from a story telling, quirky, and fun perspective.  We typically have more people throw in an attempt on the creative side, but our relatively few entries here still tickled our fancy.  A creative honorable mention goes to Jeffrey Harris, who did a great job responding in rhyming verse.

But, the best creative answer came from… Cue the trumpet fanfare…

Patrick Thomas

His rhyming lyrical madness was truly inspired, and made us laugh out loud several times.  Mixing in solid technical analysis with masterful rhyming (and a bit of lewd humor), this answer rocks!  Check out this verse, describing the commands Jack ran at the onset of the challenge:

He sent on the network a simple request
for DHCP details: an IP, DNS.
Then to Metasploit he flew like a flash,
he su-did to root and ran it from bash.

Su-did!  How could you not love an answer with the past-tense of sudo?  And, it just gets better from there.  Great work, Patrick!

Random Draw Winner

And now, for the much coveted position of random draw winner.  We threw all the entries to the challenge in a pot, from the lowly ones that said, “Burp… what’s a Christmas hacking challenge?” all the way to detailed treatises on the finer geopolitical implications of VoIP exploitation, and everything in between, including solid answers, bizarre twisted responses, photoshopped pictures of Yori with small cuddly animals, and more. We took this multi-faceted melange, and asked Python to choose for us a winner:

$ python
>>> import random
>>> random.randint(1,300)

And that number maps to the answer submitted by… insert kazoo razzle-dazzle here… Kevin “sandcrawler” White.

Don Donzal, genial host of, will contact each winner about how to claim their prizes.

So, there you have it!  Congrats to all our winners, and thank you to everyone who participated for their hard work.  We’ll be brewing up another challenge for the 2011 holiday season, and maybe, just maybe, have a challenge or two for you before then.

Thanks again, everyone.


You can go now.


No seriously, we’re done.  Go home.


Now, please.


Go. Home.

What?  We forgot something?  Oh yeah!  Our answers.  We were just testing you.  Thankfully, you passed.  Why, of course, we prepared answers for you, and were hoping you’d ask.  So, without further adieu, here are our answers to the challenge (be sure to check out Ron Bowes’ winning technical answers as well for a complementary approach).

Our answers are organized along the phases Jack Skellington used in mounting his attack, which was audio-recorded in the Secret Room of CHC Imperial Headquarters by Yori and my kids (Joshua and Jessica) playing the roles of Jack Skellington, Charlie Brown, and Lucy, respectively. 

It all begins with Jack’s initial reconnaissance, where we provided you with the commands he used at the onset of the challenge.

Phase 1 – Reconnaissance

# dhclient

Running this command, Jack obtains an IP address, netmask, and default gateway (which was the same as the DHCP server) from the DHCP server.

Router IP:
Router MAC: 00:50:56:10:10:01

# ifconfig

Here, Jack examines the IP address and netmask of his own machine to determine the settings he received via DHCP. From Lucy’s contract left behind on the desk, he knows he’s on the same subnet as the VoIP server, so he can start scanning this subnet to locate his initial target, the VoIP server.

Jack IP:
Jack MAC: 00:50:56:10:10:55

# msfconsole
msf > use auxiliary/scanner/sip/options
msf > set RHOSTS
msf > run

Now, Jack uses Metasploit’s SIP Options Scanner module to search the target subnet identified in the previous step. This module sends a SIP OPTIONS request to the target server, and looks for a response which would identify a VoIP server that accepts SIP. Jack finds the VoIP server and determines its version:

Server Version: Asterisk PBX
Voip Server IP:
Voip Server MAC:  00:50:56:10:10:77

msf > use auxiliary/scanner/sip/enumerator
msf > set RHOSTS
msf > set MINEXT 1000
msf > set MAXEXT 1100
msf > run

Next, jack uses Metasploit’s SIP Enumerator Scanner module to scan the target VoIP server for valid extensions.  This module sends SIP REGISTER requests to the target server and listens for a response. In the case of a SIP 401 (Unauthorized) response, a user exists but requires authentication. In the case of a SIP 404 (Not Found) response, no such user exists. Using the differences between these two responses, this module iterates through a list of numerical extensions checking which are valid.  Jack finds five valid extensions:

SIP Extensions: 1001, 1002, 1003, 1004, 1005 @

At this point, we’ve plumb run out of commands embedded in the challenge prose itself.  For our analysis going forward, we’ll have to use our wits, the packet capture, and the log file to figure out what’s going on.  We’ll start out each section by citing the source evidence for the given step (the pcap file and the log file), as well as any filters we use to focus our attention.  We’ll start by attempting to determine the lay of the land – devising a network layout so we can figure out where the various players sit, including where the sniffer itself is running.

Analysis – Network Layout

Source: nbcbc.pcap
Wireshark Filter: arp

Using the above Wireshark display filter, we can see all ARP traffic in the packet capture. It is quickly visible that the traffic includes broadcast messages from unique MAC addresses assigned to both the 10.10.10 and 10.11.11 subnets. The only way for both of these subnets (with corresponding MAC addresses) to appear in this packet capture is for the packets to have been recorded at a point in between the two subnets, perhaps merging the results captured on two interfaces of the device, one on each subnet.  Two interfaces of the device?  Sounds like a router.  The router is the most likely location of the sniffer.

Additionally, we notice that every non-gratuitous ARP reply is either going to or from, further corrborating the evidence that the packet capture was taken at the router. Similarly, we could have used Wireshark’s endpoints view (located under Statistics -> Endpoints) to see all the machines and their corresponding MAC addresses listed in one place.  Ahhh… Wireshark… is there nothing you can’t do?

Source: messages.dat (focused on password guessing failures)

We notice, in the log file, a large number of registrations with wrong passwords in a short amount of time. From this, we can conclude that Jack performed password guessing against various extensions.  Jack performed a password guessing attempt from against There is no evidence of such an attack in the pcap file, which again confirms that the packet capture was created at the router. Looking at the rest of the IP Addresses and ARP requests in the packet capture we can develop the following network inventory:   Router (Packet Capture Here)  VoIP Server – <==>   Jack –

This inventory is important because it tells us that we will not see packets going from Jack to the VoIP server and vice-versa, because they go across that local LAN, which is a switched subnet.  Linus is running a passive sniffer on the router.

Phase 2 – Infiltration

Source: messages.dat (focused on password guessing failures)

To perform the password guessing attack, Jack could have relied on numerous tools.  One of the most convenient is svcrack, a tool which is part of the sipviscious suite (  Jack runs password guessing attempts against all five of the valid extensions he found in the SIP Enumerator scan. Jack could have run it as follows:

# –externalip -u 1001 -d password_list
# –externalip -u 1002 -d password_list
# –externalip -u 1003 -d password_list
# –externalip -u 1004 -d password_list
# –externalip -u 1005 -d password_list

The -u option allows Jack to specify which extension he is running password guessing attempts against, while the –externalip tells the VoIP server at where to send responses.

Instead of svcrack, this attack could have just as easily been performed using the SIP protocol option available in the THC Hydra password guessing tool (

Once he successfully determines a password for an extension, Jack registers softphone software running on his laptop as one of those extensions.  Just one of the many available softphones available in Linux, Jack happened to use Linphone ( to register himself as extension 1005.

# linphone

It is interesting to note that there is no mention of extension 1005 in the VoIP server’s log file. This appears to be an anomaly with the way that Linphone registers itself. Specifically, it appears that Linphone does not appear to check for an available voicemail box, while the alternate softphone used by the legitimate users in the challenge does.  Any way, extension 1005 is now Jack.

Analysis – Reconnaissance and Infiltration

Source: messages.dat, nbcbc.pcap
Wireshark Filter: sip.Request-Line contains "SUBSCRIBE sip:1001" or sip.Request-Line contains "SUBSCRIBE sip:1004"

Examining the messages.dat log file from the VoIP server, we see that before Jack’s attempts at password cracking, there were two subscriptions from extensions 1001 and 1004. Using the above Wireshark filter, we can find three such matching subscriptions of which only the last two match our messages.dat log file (implying the log file was started after the first subscribe by 1001).



0s – SUBSCRIBE sip:1001  
15s – SUBSCRIBE sip:1004 20:44:00 – SIP subscribe 1004
60s – SUBSCRIBE sip:1001 20:44:46 – SIP subscribe 1001

By aligning the above data from the packet capture with the log entries in messages.dat, we can see that the packet capture began recording at 20:43:45 (fifteen seconds before the SIP subscription request for extension 1004). Using this timeframe as a baseline, we can proceed to correlate all the data between messages.dat and the packet capture file.

Wireshark Filter: bootp

Looking at the packet capture, we can see that extension 1001 is at IP Address and extension 1004 is at IP Address The last activity by either of these appears at 66s in the packet capture, essentially at the same time as Jack’s DHCP request.  With this information, we can safely assume that anything happening with extensions 1001 and 1004 happened prior to and completely separate from Jack’s activities.  We were being playful with this initial conversation, having two adults in the Charlie Brown universe talk with each other using the “Bwah-Bway” sound.  We did this to help establish the fact that the VoIP server was used by other people, and not just the kids in the challenge.

Wireshark Filter: eth.addr == 00:50:56:10:10:55

The previous section allowed us to find Jack’s initial DHCP exchange, which told us when he started his activities and also gave us his MAC address of 00:50:56:10:10:55.  This MAC address information allows us to continue our analysis by filtering for his MAC address.

First, the packets between 65.8s and 66.9s show us Jack’s DHCP request.

Then, we see Jack’s SIP Options scan hitting the router at 71.6s. This scan begins with an ARP scan which, when it encounters a valid response, sends a SIP OPTIONS request to the discovered machine.

Finally, we see the remainder of the SIP OPTIONS scan’s ARP requests lasting until 81.6s, followed by a long pause in activity.

Using our time correlation from before, we can see that the SIP Enumerator scan begins at 20:45:10 log time which corresponds to 85s packet capture time. This is followed by the password guessing attempt at 20:45:22.  We can hone in on this activity in the log file by running:

# egrep -o ‘Registration from .+ Wrong password’ messages.dat | sort | uniq -c

The above command uses egrep to find lines in the file which contain segments of text starting with ‘Reg…’ and ending with ‘…password’ and a wild card in between. Then only the text matching the pattern (-o) is outputted to standard out and piped into sort and uniq to be displayed as unique lines and counted (- c). This command line kung fu tells us that 106 attempts were made against the first four extensions (1001, 1002, 1003, 1004) while only 20 attempts were made against 1005. Although it is not an entirely safe guess, later evidence in the form of activity from extension 1005 allows us to deduce that Jack correctly guessed the password to extension 1005 on his 21st attempt. None of this is visible in our packet capture due to the network layout discussed previously, hence the relatively long pause seen in the pcap file.  Even though the router didn’t see this activity, it was duly recorded for us in the VoIP server logs.  The two forms of evidence complement each other quite often (as in this case), and at other times corroborate each other.

Phase 3 – Exploitation

Once Jack had determined a password for a VoIP account, he had everything he needed to put his plan into motion. First, Jack needed to find the right phone call to snoop on.  To accomplish this, he had to get access to the network traffic going to and from the VoIP server. The packet captures show a significant number of gratuitous ARPs, approximately every two seconds, an indication of a possible ARP cache poisoning attack to sniff in a switched environment.

Jack’s plan was to arp cache poison both the router and the VoIP server into thinking that the other was located at Jack’s MAC address. To prevent a denial of service, Jack had to enable IP forwarding on his Linux box using the following echo command so traffic could freely flow through his machine to its intended destination allowing him to view it in the process.

# echo 1 > /proc/sys/net/ipv4/ip_forward

The arpspoof tool from Dug Song’s dsniff suite ( performs ARP cache poisoning to redirect the flow of traffic across a subnet in a switched environment.  Jack could have run it as follows:

# arpspoof -i eth0 -t &
# arpspoof -i eth0 -t &

This tool requires an interface on which to perform the attack (-i) followed by the target we wish to poison (-t [IP Address]) and finally the destination IP Address whose traffic we wish to redirect to ourselves. Arpspoof sends a gratuitous ARP response to the target machine every 2 seconds, telling the target that the provided IP address is actually at the MAC address of the machine running the attack. That’s exactly what we see in the packet captures, so it is very likely Jack used arpspoof, or another tool with very similar properties (the 2-second interval is very telling).  Jack poisons both the router ( and the VoIP Server ( telling both of them that traffic going to the other should instead go to Jack’s machine which he will then forward to the intended target after having a chance to sniff the traffic. Because Jack poisons both targets, he can get full-duplex sniffing and see both sides of their conversation to each other.

Alternatively, Jack could have also used Ettercap ( to accomplish the same effect, although with a different network traffic pattern.  Or, if he had used a Windows machine instead of the Linux box described in the challenge, Jack could have used the ARP-Poisoned-Routing capabilities of the Cain tool.

Next, Jack took advantage of his new man-in-the-middle position by looking for and automatically recording any VoIP calls going to and from the VoIP server.

Rtpbreak ( is a tool which detects any rtp streams (including VoIP calls) on the network and outputs each individual stream to a .raw and .pcap file in the specified directory.  Jack could use rtpbreak to record in promiscuious mode (-m) on interface eth0 (-i) without recording pcap files (-W) and dumping all output to the /tmp/rtp directory (-d).

# rtpbreak -i eth0 -m -W -d /tmp/rtp &

Jack prefers tools which are simpler and versatile so he chose to use rtpbreak, although there are many other alternatives. The raw sound format is important because it allows Jack to perform some command line kung fu for live eavesdropping on the call. In addition, rtpbreak also displays the IP addresses and ports used in the rtp stream, helpful information for the next phase of the attack.

A SIP VoIP call consists of two separate portions, the SIP exchange to set up and tear down the call, and an RTP stream of voice data in between. To correlate the RTP streams with actual phone calls and extensions, Jack could use tshark magic to output relevant SIP traffic as follows:

# tshark -i eth0 -f "udp port 5060" -R "sip.Request-Line contains INVITE" -T fields -e sip.From -e sip.To -e sip.Call-ID

Tshark ( is an excellent command-line analogue to Wireshark which allows Jack to filter for udp port 5060 (-f "udp port 5060") and then only display SIP packets which contain INVITE (phone call initiation) in the Request-Line portion of the protocol (-R). Finally, Jack tells tshark to output only the From, To, and Call-ID fields of the SIP protocol which in combination with the rtpbreak output gives him everything he needs to know about all VoIP calls going across the network.

With these two tools running, Jack eventually sees the following output from rtpbreak and tshark respectively:

open di /tmp/rtp/rtp.0.0.txt
 ! [rtp0] detected: pt=0(g711U) =>
open di /tmp/rtp/rtp.0.1.txt
 ! [rtp1] detected: pt=0(g711U) =>
open di /tmp/rtp/rtp.0.2.txt
 ! [rtp2] detected: pt=0(g711U) =>
 * [rtp2] probable reverse RTP stream: [rtp1]
open di /tmp/rtp/rtp.0.3.txt
 ! [rtp3] detected: pt=0(g711U) =>
 * [rtp3] probable reverse RTP stream: [rtp0]

From: <sip:1003@>
To: <sip:1002@>

From: "Theatre" <sip:1003@>
To: <sip:1002@;rinstance=08ab0af51d049ed3>
Call-ID: 7a49bc9901ced1030951385b5c460b5d @

[duplicates removed and slightly reformatted to improve readability]

Examining the output Jack sees the following two rtp streams and respective SIP endpoints:

Ext 1002 – <=> – rtp.0.0.txt and rtp.0.3.txt
Ext 1003 – <=> – rtp.0.1.txt and rtp.0.2.txt
Initial Call-ID:  MTg2OGJmNDE4MWExNzQwM2VhYjFkNGQyMDdmN2QwZGU.

This output gives Jack all the information he will eventually need to perform each step of his attack.

To listen to this call in real time, Jack takes advantage of the fact that rtpbreak outputs the above rtpstreams in raw format with file names corresponding to the name of the .txt log file. To listen in live, Jack needs both sides of the conversation which he can get from either ( rtp.0.0.raw and rtp.0.3.raw ) or ( rtp.0.1.raw and rtp.0.2.raw).  Rtpbreak continually outputs to these raw files so Jack uses the following bit of command line kung fu to tail and play the audio being written to these files as it comes in:

# play -q -t ul <(tail -f -c 0 rtp.0.1.raw) &
# play -q -t ul <(tail -f -c 0 rtp.0.2.raw) &

The play tool is part of SoX ( and allows us to play sound files of a variety of formats. Here Jack is telling the play tool to run in quiet mode (-q) and to use the ulaw sound format which is commonly used for VoIP calls. Then we use a bit of Linux command line redirection trickery to take the output of the tail command, put it into a temporary file descriptor, and pass the file descriptor as input to the play command. In this case we’re using the tail command to follow the end of the file continuously (-f) starting from the last 0 bytes of the file (-c 0) and using the raw sound files from the previous step as input.

Although the above technique is most aligned with Jack’s preference of using basic command-line tools and combining them together, he could have much more easily used the GUI interface of the wonderful UCSniff tool ( by Jason Ostrum and the gang at VIPER Lab) to live eavesdrop on the call. This method proves much simpler and easier to set up, but obscures some of the understanding of the separate RTP and SIP mechanisms behind each VoIP call, as UCSniff magically handles a lot of that stuff behind the scenes. Additionally, other tools such as the wonderfully named VOMIT ( by Niels Provos), which requires a tcpdump output file, and voipong ( could have been used to dump the audio of the VoIP calls and listen to them at a later time.

Analysis – VoIP Calls

Source: nbcbc.pcap

When we left off in our analysis, Jack had just finished scanning and password cracking which we couldn’t see in the packet capture because of the sniffer’s location on the router. What we did see was a long pause at 81s until traffic again picks up at 170s with gratuitous ARPs telling the router that (VoIP server) is at 00:50:56:10:10:55 (Jack’s MAC address). Here we see Jack beginning his ARP cache poisoning attack and although we do not know if he is also poisoning the VoIP server, whether or not Jack has half-duplex or full-duplex sniffing should not affect our analysis. These gratuitous ARPs will continue throughout the packet capture as Jack continues to poison the router, sending ARPs every 2 seconds, so we can filter them out with by applying the Wireshark filter "! arp".

Next up, between 189s and 205s in the packet capture, we see extensions 1002 and 1003 registering themselves with the VoIP server from IP Addresses and respectively. Using our previous time correlation, we can see that this corresponds to 20:46:54 and 20:47:10 in the message.dat log file where these registration attempts are logged. Looking at the rest of the log file tells us that extensions 1002 and 1003 continued to re-register themselves every one and then two minutes implying an automated keep-alive process given the exactness of the time intervals. This represents the end of the log file and means we must continue the rest of our analysis using only the packet capture.

Finally, at 214s we see the SIP INVITE from extension 1002 to extension 1003 which triggers the output from rtpbreak and tshark that we saw in Jack’s Phase 3. What follows, except for a few exceptions, is a series of VoIP calls (SIP requests and corresponding RTP streams) which are more easily analysed using Wireshark’s VoIP calls module [ Telephony -> VoIP Calls ].

In Wireshark’s VoIP Calls interface we see five separate "calls". The first two "calls" actually represent two ends of a single call identifiable by the identical start and stop time and the identical From/To SIP extensions. The same is true for the third and fourth "calls". Remembering the time analysis we’ve done so far we can build the following timeline.

 VoIP Call 1 – Extension 1004 calls extension 1001
 Jack joins the network and begins sniffing
 VoIP Call 2 – Extension 1003 calls extension 1002
 VoIP Call 3 – Extension 1003 calls extension 1002 ! (the connection to is not completed, but a call happens)

We can listen to any of the three calls by selecting both (or one) of their streams and hitting the "Player" button, then checking "Use RTP timestamp" and hitting "Decode". This opens up the VoIP RTP Player interface allowing us to select which of the two RTP streams we wish to listen to and hitting play to listen to them all the way through. Looking at the three calls individually here is what we find:

VoIP Call 1:

The first call, the one that happens before Jack has entered the network, appears to be a conversation between two of the adults in the Charlie Brown world. If we look at the caller ID field, we can see that one of the phones (1004) being used is actually Lucy’s phone. One of the adults may have happened upon the phone at the psychiatrist’s desk and used it as an opportunity to chat about the day’s events to another adult.

VoIP Call 2:

Here’s where things get more interesting. If we select both parts of VoIP call 2 and decode them, we hear a conversation happening between Lucy (1003), who according to her Caller ID appears to be at the Theatre, and Charlie Brown (1002). It appears to be a normal conversation until approximately 40 seconds into the conversation (!!! at the 260s mark in the packet capture as shown in the RTP player timeline) when there appears to be an extra sound stream only visible on one side of the conversation. Specifically, it appears that Jack Skellington is inserting his voice into only Charlie Brown’s side of the conversation telling him to stay home for Christmas. Not only do we notice that the inserted sound is only on one side of the conversation (going to Charlie Brown, not to Lucy), but we also take note that the entire call is still active for both sides meaning neither party has been disconnected.


VoIP Call 3:

In the third VoIP call, we hear Lucy acting as if she has called back Charlie Brown but instead has gotten Jack Skellington on the other line who pretends to be Charlie Brown and tells Lucy about the "true meaning of Christmas". We notice two anomalies in this phone call. The first is the fact that Lucy was calling Charlie Brown back, thinking that she had successfully reached him. The second is the lack of a matching set of RTP streams for Jack’s extension. If we remember our network layout analysis, we can safely assume that the only other place this second RTP stream could be going to where we could not see it in the packet capture is Jack’s machine at  Remember, Jack is on the same subnet as the VoIP server, so this traffic flow from his machine to the VoIP server is invisible to the sniffer running on the router.

With this information in mind, we can begin to make some guesses of what Jack might have done and then, in our final analysis, verify our guesses:

 First, Jack seems to have, without interrupting the call in any way, injected sound into one side of the conversation between 1003 (Lucy) and 1002 (Charlie Brown)
 Second, Jack seems to have redirected Lucy to his own extension (likely 1005 from our password guessing analysis) when she was trying to call back 1002 (Charlie Brown)

Phase 4 – Manipulation

Once Jack found the phone call he was looking for and began listening in real-time, he got Charlie Brown and Lucy right where he wanted them. First, Jack must have recorded a special message for Charlie Brown.

Rec is another tool which is part of SoX, which allows users to record a multitude of audio formats and specify exact parameters for their encoding.

# rec -1 -r 8000 -c 1 message.wav

In this case Jack is using settings typical for VoIP traffic by encoding with one byte (-1) at an 8000 Hz sampling rate (-r 8000) with a single channel (-c 1).

After recording his message, Jack used a tool called rtpinsertsound ( to override any sound coming from Lucy with a message of his choice.

# rtpinsertsound -a -A 12280 -b -B 59300 -f 1 -j 50 message.wav

This tool works by injecting RTP traffic with the same UDP source IP address (-a), source port (-A), destination IP (-b) and desintation port (-B) as an existing RTP stream and sending packets with an ID number incremented by 1 (-f 1) causing the receiving application to ignore the "older" packets and effectively writing over the existing stream with a wav file of the attacker’s choice.

Jack wisely remembered the port numbers given to him by the output of the rtpbreak tool in Phase 3 and therefore had all the information he needed to run the rtpinsertsound tool. Rtpmixsound, another tool from the same developers, would have been a worse choice in this scenario because it allows both the existing stream and the "mixed" stream to be heard on top of each other, effectively sending a mixed message which Jack did not want.

To prevent Lucy or Charlie brown from saying anything further on the call, as well as setting up his next attack, Jack uses the teardown tool (also from to send a gratuitous SIP GOODBYE to extension 1002 ending the call.

# teardown eth0 1002 MTg2OGJmNDE4MWExNzQwM2VhYjFkNGQyMDdmN2QwZGU. "" ""

The teardown tool takes seven parameters:

eth0 – The interface on which to send the packets
1002 – The target user/extension – The IP address of the target’s domain (VoIP server) – The IP address of the target (Explained below)
MTg2… – Call-ID
"" – From Tag (optional in this case)
"" – To Tag (optional in this case)

Remembering his tshark output, Jack was able to extract all the necessary information for this tool as well. If we look at the tshark output ourselves, we can see that in the case of the call we are tearing down and for the SIP protocol, extension 1002 is located at because extension 1003 has to go through the VoIP server to eventually reach extension 1002.

From: <sip:1003@>
To: <sip:1002@>

Finally, Jack runs a the redirectpoison tool (also from This tool detects any invites from the provided IP address

on the specified port and immediately sends a spoofed SIP 301 REDIRECT pointing to the extension of Jack’s choice (1005) effectively redirecting the call to Jack’s extension without the caller’s knowledge.

# redirectpoison eth0 5060 "<sip:1005@>"

Jack uses this tool, correctly assuming that Lucy will try to call Charlie Brown back after the hang-up, to redirect Lucy to his own extension where he can safely pretend to be Charlie Brown and teach her the "true meaning of Christmas" thereby completing his attack.

Analysis – VoIP Hacks

Source: nbcbc.pcap

Leaving off with our guesses unconfirmed, let’s see if we can use the evidence in the pcap file to determine whether they were right. Beginning with the first anomaly of "inserted sound" we remember that in the RTP Player interface, the insertion appears to have started at approximately the 260s mark in the packet capture.

Wireshark Filter: rtp and ip.src == and ip.dst ==

Because we could see in the RTP Player strange packets were occuring in the rtp stream going from to, we can use the above Wireshark filter to see only those packets. Now that we have the filter in place, the first noticable anomaly is that at exactly the 260s mark in the packet capture, there begins a pattern of duplicate sequence numbers coming from

Moving a bit further into the pattern of duplicates, we begin to see that one of the two packets with the different sequence numbers starts to have differing payloads as well. It appears that we’ve found our inserted packet culprit. Upon even deeper analysis, we find the final piece of evidence which clearly indicates foul play: differing TTL values for the duplicate sequence number packets. This gives us the final piece of evidence to identify that packets are being inserted, from a different source, with a spoofed IP address and port, with a different rtp payload, one hop closer to the target. Analysis of the IP TTL field comes in handy in many attacks, including this one!  Here we see the evidence we need to confirm our guess about inserted sound, in this case performed by the rtpinsertsound tool described in Jack’s Phase 4. (See images on next page).

Wireshark Filter: sip.Request-Line contains BYE

Although it would take an impecable attention to detail to notice, Jack’s use of the teardown tool in Phase 4 is noticable using the above Wireshark filter. The five remaining packets shown to us represent the three calls in the packet capture file. The first is a normal call between 1001 and 1004, the adults in the Charlie Brown universe having their Bwah-Bway chat. The second is the call we are investigating between 1002 and 1003, and finally is the one-sided (due to network layout) call between 1003 and 1005. Since we cannot see both sides of the third call, we can safely ignore it and compare the first two calls. Doing so, we see an anomaly in the packets. Namely a SIP BYE request is first sent from the VoIP server to and then a full 6 seconds later, sends a SIP BYE request with an error code (10061, RTP stream closed) back to the server.

Although it would take some guessing, it could be deduced that a request to close the connection was sent to the server without us seeing it and the server then responded with a confirmation to, effectively tearing down the connection. Following that, tries to tear down the connection after its RTP stream was unexpectedly closed and after a significant timeout. This uncharacteristic order of operations is at least enough to tell us that something went wrong with this call, again corroborating evidence of Jack’s trickery.



Wireshark Filter: sip

The final anomaly for us to investigate is the sudden redirection of the third VoIP call from Lucy to Charlie Brown which according to Wireshark’s VoIP Calls interface began at approximately 323s. Filtering for just SIP we see two suspicious SIP 301 packets telling to redirect its call to extension 1005. Our suspicion is further confirmed by looking at the TTL of the packets and finding that it is 126 and 127, a value completely different from the 63 of every other SIP packet sent from the VoIP server. This confirms our suspicion that it was Jack who planted the redirects forcing Lucy to instead redirect her call to his own captured extension allowing him to plant the seeds of his evil plot.

Jack’s Plan, in Summary

Jack employed a series of VoIP attack tools to try to spread the message of materialism and commercialism among the children of the Charlie Brown Universe.  In effect, our challenge here fits into the back story of the Charlie Brown Christmas special.  It explains why Charlie Brown is so depressed at the outset of the video (because Jack injected a message into his conversation with Lucy saying that nobody liked him).  Jack did this to sideline Charlie Brown and prevent him from interfering with Jack’s plan.  It further shows the source of the children’s greedy view of Christmas.  In fact, when Lucy and the kids at the theater attempt to call Charlie Brown back, Jack redirects their call to himself and answers with the phrases “Money! Money! Money!”, “Real Estate!”, etc.  These very phrases were parroted by the children later in the Charlie Brown video itself.  Jack clearly made an impression.

This concludes the writeup of our answers.  Thank you to everyone who participated.  We sincerely hope you enjoyed the challenge and we’ll see you again next year! Merry Christmas! Ho ho ho ho mua ha ha ha haaaa!

–Yori and Ed.

Category: Skillz

Comments are closed.