Too Much, Too Fast...Part II

Above and far below might be the type of topology or map you may want to look at if you had a million or so Conficker machines and you were considering where to store your next payload so that it would remain:

(1) well-hidden

(2) ever-present

The first column (also the X axis above) is the count of the number of times this particular memory size is stored on my machine. The second column (in KB and Y axis above) is the memory size itself. The last print column are those Windows modules at that particular size. This is the type of topology that would help lay out the battlefield for the Botnet Generals. It would help answer questions like:

(1) Where should/could our armies live?

(2) How much space or resources will we have for them?

(3) Who will house them? What dll will be called the most frequently with what access?

Any administrative access to Win 7 or Win2008 would have Powershell/WinRM waiting to be configured. Thus this type of surveillance of Windows desktop could be done on a very large scale quickly and dynamically. And the analysis could be granular: per region, per industry, per subnet, etc.

[Powershell]

$Global:ps = ps

$ps_count = $ps.count

write "Process Count = $ps_count"

$Global:all_modules = 0..$ps_count |%{$ps[$_].Modules} | Select Size,ModuleName,FileName,FileVersion

$Global:all_modules_memory = $all_modules | Select -property ModuleName,Size | Sort -property Size

$all_modules_memory | sort -Descending -property Size | group -property Size

[partial dump]:

....

63 712 {@{ModuleName=ntdll.dll; Size=712}, @{ModuleName=ntdll.dll; Size=712}, @{ModuleName=ntdll.dll; Size=712}, @{ModuleName=ntdll.dll; Size=712}

13 704 {@{ModuleName=SXS.DLL; Size=704}, @{ModuleName=SXS.DLL; Size=704}, @{ModuleName=SXS.DLL; Size=704}, @{ModuleName=SXS.DLL; Size=704}...}

1 680 {@{ModuleName=xpsp3res.dll; Size=680}}

1 676 {@{ModuleName=TzShell.dll; Size=676}}

1 672 {@{ModuleName=swg.dll; Size=672}}

2 656 {@{ModuleName=RASDLG.dll; Size=656}, @{ModuleName=localedata_others.dll; Size=656}}

3 652 {@{ModuleName=MSVCR90.dll; Size=652}, @{ModuleName=MSVCR90.dll; Size=652}, @{ModuleName=MSVCR90.dll; Size=652}}

2 644 {@{ModuleName=chartmodelmi.dll; Size=644}, @{ModuleName=Microsoft.PowerShell.ConsoleHost.ni.dll; Size=644}}

1 636 {@{ModuleName=SavNeutralRes.dll; Size=636}}

1 632 {@{ModuleName=localedata_euro.dll; Size=632}}

1 624 {@{ModuleName=System.Transactions.ni.dll; Size=624}}

67 620 {@{ModuleName=ADVAPI32.dll; Size=620}, @{ModuleName=MSVCR80.dll; Size=620}, @{ModuleName=ADVAPI32.dll; Size=620}, @{ModuleName=ADVAPI32.dll

30 616 {@{ModuleName=comctl32.dll; Size=616}, @{ModuleName=comctl32.dll; Size=616}, @{ModuleName=comctl32.dll; Size=616}, @{ModuleName=comctl32.dl

2 604 {@{ModuleName=stlport_vc7145.dll; Size=604}, @{ModuleName=stlport_vc7145.dll; Size=604}}

21 596 {@{ModuleName=CRYPT32.dll; Size=596}, @{ModuleName=CRYPT32.dll; Size=596}, @{ModuleName=CRYPT32.dll; Size=596}, @{ModuleName=CRYPT32.dll; S

63 584 {@{ModuleName=RPCRT4.dll; Size=584}, @{ModuleName=RPCRT4.dll; Size=584}, @{ModuleName=RPCRT4.dll; Size=584}, @{ModuleName=RPCRT4.dll; Size=

63 580 {@{ModuleName=USER32.dll; Size=580}, @{ModuleName=USER32.dll; Size=580}, @{ModuleName=USER32.dll; Size=580}, @{ModuleName=USER32.dll; Size=

1 576 {@{ModuleName=QuickTimeMPEG4Authoring.qtx; Size=576}}

1 572 {@{ModuleName=QuickTimeEffects.qtx; Size=572}}

1 564 {@{ModuleName=diasymreader.dll; Size=564}}

2 560 {@{ModuleName=wzcsvc.dll; Size=560}, @{ModuleName=printui.dll; Size=560}}

46 556 {@{ModuleName=OLEAUT32.dll; Size=556}, @{ModuleName=OLEAUT32.dll; Size=556}, @{ModuleName=OLEAUT32.dll; Size=556}, @{ModuleName=OLEAUT32.dl

3 544 {@{ModuleName=shdoclc.dll; Size=544}, @{ModuleName=libdb42.dll; Size=544}, @{ModuleName=shdoclc.dll; Size=544}}

1 532 {@{ModuleName=wbemcore.dll; Size=532}}

2 528 {@{ModuleName=xcrmi.dll; Size=528}, @{ModuleName=dopdfui5.dll; Size=528}}

1 520 {@{ModuleName=HPQTOA~1.EXE; Size=520}}

2 516 {@{ModuleName=evtsys.exe; Size=516}, @{ModuleName=winlogon.exe; Size=516}}

4 512 {@{ModuleName=tlmi.dll; Size=512}, @{ModuleName=CRYPTUI.dll; Size=512}, @{ModuleName=CRYPTUI.dll; Size=512}, @{ModuleName=CRYPTUI.dll; Size

31 508 {@{ModuleName=CLBCATQ.DLL; Size=508}, @{ModuleName=CLBCATQ.DLL; Size=508}, @{ModuleName=CLBCATQ.DLL; Size=508}, @{ModuleName=CLBCATQ.DLL; S

....

Too Much, Too Fast

At some point, the software industry will have to come to terms with the fact that it grew too fast, created too many rapid application development vehicles and expanded code into Operating Systems that just cannot fundamentally withstand concerted attacks from hackers, organized crime, nation state terrrorists, etc. Ultimately, the best defense against intrusion, worms, buffer overflow attempts, etc will be to 'native sentinel' programs that can 'electric fence' every loaded feed, hook, interface, binary,library against suspicious behavior. Current processor memory/development may allow for such sentries. Indeed 'DEP' (Data Execution Protection) could be termed a 'native sentinel' program. However, in many ways there is just too much going on inside a modern OS to be well-protected.This is some Powershell output from my Windows laptop. Notice:

(1) How may modules are (2701) in use by a limited number of applications (64) and

(2) How many modules (515 unique out of 2701 total) are being shared in multiple applications

$ps = ps

$count = $ps.count

$count

64

$all_modules = 0..$count |%{$ps[$_].Modules} | Select BaseAddress,EntryPointAddress,Size,ModuleName,ModuleMemorySize,GetLifetimeService,FileName,FileVersion,Company,Description

$all_modules.count

2701

$unique_all_modules = $all_modules | Select -property ModuleName | Sort -Unique -property ModuleName

$unique_all_modules.count

515

We have a similar situation with Linux (no XWin running here), although notice the process to module count ratio (86:1583) is a little lower than my windows box(64:2701) [As if the two could be realistically compared ;-)]:

ps awx | wc -l

86

/usr/sbin/lsof | wc -l

1583

...

Now look at my OpenBSD box (no Xwin running here either):

# ps -la | wc -l

20

# fstat | wc -l

183

....

Part of "proactive security" employed by creators of OpenBSD are the careful decisions:

(1) to run as few default services as possible

(2) not to support every application on the planet

There's not too much more to say on this type of logic: "The smaller your garden, the more carefully you can attend to each plant." Albeit, one does have to grow enough to feed your family!

PolyMorphic Multifunctional Spyware/Malware/Distribution Ware...

I have been writing scripts like those (far) below to parse my Firewall's syslogd output and wondering if there is some other, better way to understand the significance of my logs. Ultimately, I would like a little more information like: What causes the Firewall to behave as it does? Perhaps I am requesting a Firewall application log. For example, unidirectional SIPs are obviously blocked, but how does it know to continue bi-directional conversations across the WAN initiated from the LAN?  Sometimes I see an immediate block, other times I see a one packet delay.  Watching my firewall work drives home the point that the classic "firewall as perimeter defense" relinquishes control over what data escapes my network, especially if I do not employ host firewalls with bidirectional blocking capacity. 

And maybe even not then. The persistence of the current breed of spyware/malware/distribution ware (e.g. Conficker) is such that it can initiate web conversations on hidden, broken or validated channels (e.g register new domains) and then plunder host information from 'command and control' nodes once an internal node has established a validated external connection. Later the spyware/malware/distribution ware engages in 'polymorphic mutation' and updates itself to protect against updates in security products designed to detect it. The most notorious of such spyware/malware/distribution ware to date would be Conficker C. This is from http://mtc.sri.com/Conficker/addendumC/index.html:

"We present an analysis of Conficker Variant C, which emerged on the Internet at roughly 6 p.m. (PST) on 4 March 2009.  This variant incorporates significant new functionality, including a new domain generation algorithm and a new peer-to-peer file sharing service.   Absent from our discussion has been any reference to the well-known attack propagation vectors (RCP buffer overflow, USB, and NetBios Scans) that have allowed C's predecessors to saturate so much of the Internet.  Although not present in C, these attack propagation services are but one peer upload away from any C infected host, and may appear at any time. C is, in fact, a robust and secure distribution utility for distributing malicious content and binaries to millions of computers across the Internet.   This utility incorporates a potent arsenal of methods to defend itself from security products, updates, and diagnosis tools.  It further demonstrates the rapid development pace at which Conficker's authors are maintaining their current foothold on a large number of Internet-connected hosts.  Further, if organized into a coordinated offensive weapon, this multimillion-node botnet poses a serious and dire threat to the Internet."

I really don't think anyone has a clue of what to do about polymorphic, multifunctional spyware/malware/distribution-ware like this in terms of either prevention, detection, and perhaps removal. In fact, Conficker and other malware present a unique set of conundrums: Not just how do we detect this type of malware or how do we secure what we have already lost but how do we keep a multimillion node botnet from destroying the rest of the internet?  While the spyware/malware/distribution ware designers have propagated their creation throughout the universe, the rest of us are twiddling our fingers writing ditzy shell scripts in hopes they will tell us something about our Firewall's behaviour:

# more NotBlockedUniqLocation.sh                                                                                   

grep Dest message* | awk -F":" '{print $2$3$4 ":" "DIP:"$7":"}' | grep -v -f not_search.txt | grep -v [localhost] | awk -F":" '{print $3}' > NotBlocked.txt

for i in `cat NotBlocked.txt | sort -nr | uniq`; do echo $i `geoiplookup -f /usr/local/share/GeoIP/GeoLiteCity.dat $i | awk -F" " '{print $6 $7 $8 $9 }'`;done

# more BlockedUniqLocation.sh     

grep Blocked message* | awk -F":" '{print $2$3$4 ":" $6":"}' | grep -v -f not_search.txt | awk -F":" '{print $2}' > Blocked.txt

for i in `cat Blocked.txt | sort -nr | uniq`; do echo $i `geoiplookup -f /usr/local/share/GeoIP/GeoLiteCity.dat $i | awk -F" " '{print $6 $7 $8 $9}'`;done

# ./NotBlockedUniqLocation.sh 

222.172.105.109 CN,07,Zhongshan,(null),

217.109.17.57 FR,A8,Paris,(null),

216.73.87.115 US,NY,NewYork,

216.34.207.74 US,CA,WestlakeVillage,

216.34.181.91 US,CA,MountainView,

216.34.181.71 US,CA,MountainView,

216.34.181.60 US,CA,MountainView,

216.34.181.59 US,CA,MountainView,

216.34.181.40 US,CA,MountainView,

216.168.46.76 US,WA,Seattle,98168,

216.168.46.72 US,WA,Seattle,98168,

212.58.226.143 GB,P9,Maidenhead,(null),

212.58.226.142 GB,P9,Maidenhead,(null),

212.58.226.139 GB,P9,Maidenhead,(null),

209.66.102.82 US,CA,Berkeley,94709,

209.66.102.50 US,CA,Berkeley,94709,

...

# ./BlockedUniqLocation.sh                                                                                         

222.172.105.109 CN,07,Zhongshan,(null),

217.109.17.57 FR,A8,Paris,(null),

216.34.181.71 US,CA,MountainView,

216.34.181.60 US,CA,MountainView,

216.168.46.76 US,WA,Seattle,98168,

209.66.102.82 US,CA,Berkeley,94709,

209.66.102.50 US,CA,Berkeley,94709,

206.51.224.187 US,FL,Tampa,33602,

204.121.6.51 US,NM,LosAlamos,

203.146.189.74 TH,40,Bangkok,(null),

202.99.11.99 CN,22,Beijing,(null),

202.12.29.13 AU,04,Brisbane,(null),

199.93.55.126 US,(null),(null),(null),

199.43.0.144 US,(null),(null),(null),

199.212.0.43 CA,ON,Toronto,(null),

195.97.20.4 GR,35,Athens,(null),

192.149.252.44 US,(null),(null),(null),

168.75.68.60 US,MA,Andover,01810,

...

Viisualizing SIPs over time,port,IP range

Being able to quickly visualize Source IP Addresses over time and port and IP range is significant. The following utilities help:

• mergecap
  
• ipsumdump
  
• pcregrep
  
• gnuplot
  

Mergecap is part of the Wireshark distribution.  It merges pcap files quickly and with little fanfare. Ipsumdump is a brilliant piece of software by UCLA prof Eddie Kohler. It is based on his "Click" router development which provides functional replacement for pcap code. Gnuplot is indispensable as part of the *Nix toolkit.What I want to do here is:

(1) merge two weeks of tcpdump captures into one pcap file

(2) filter out some common ports (e.g. noise)

(3) meaningfully analyze SIP behavior

The examples below are simple and straightforward. I expect to explore this software more.

[Here I filter out some common 'noisy' internal traffic:]

more no_search.txt

 514

 520

 137

 138

 67

[Now I merge a couple weeks of pcap files and then columnize them with ipsumdump:]

mergecap -w May22-Jun4.cap May*2009 Jun012009

ipsumdump -r --no-headers -qtsSdDpO May22-Jun4.cap | pcregrep -v -f no_search.txt | sort -n -k 2  | more

....

1243564232.633833 110.8.212.14 3232 192.168.0.12 12712 U -

1243819790.146836 113.12.190.38 41300 192.168.0.12 1434 U -

1243962105.530513 113.12.190.38 40074 192.168.0.12 1434 U -

1243948162.113607 114.44.118.145 2522 192.168.0.12 25 T mss1440;sackok

1243948162.891020 114.44.118.145 2522 192.168.0.12 25 T mss1440;sackok

1243948163.661370 114.44.118.145 2522 192.168.0.12 25 T mss1440;sackok

1242915720.575869 114.45.61.61 4121 192.168.0.12 25 T mss1440;sackok

1242915727.208449 114.45.61.61 4121 192.168.0.12 25 T mss1440;sackok

1243948165.160091 115.150.202.176 1358 192.168.0.12 12712 U -

1243580800.176250 115.30.142.186 46453 192.168.0.12 1434 U -

.....

[Now I re-ordered one SIP I want to explore more closely:]

grep 121.15.245.215 out.dat 121.15.245.215.dat

sort -nr 121.15.245.215.dat > 121.15.245.215.graph.dat

1243935815.497855 121.15.245.215 12200 192.168.0.12 8000 T .

1243896403.852720 121.15.245.215 12200 192.168.0.12 3128 T .

1243786852.873342 121.15.245.215 12200 192.168.0.12 8000 T .

1243786749.219621 121.15.245.215 12200 192.168.0.12 3128 T .

1243751923.943017 121.15.245.215 12200 192.168.0.12 8000 T .

1243751811.136522 121.15.245.215 12200 192.168.0.12 3128 T .

1243702801.387269 121.15.245.215 12200 192.168.0.12 8000 T .

1243702687.231474 121.15.245.215 12200 192.168.0.12 3128 T .

1243678638.723457 121.15.245.215 12200 192.168.0.12 7212 T .

....

[Then I plot that SIP's activity over time:]

gnuplot> set terminal dumb

Terminal type set to 'dumb'

Options are 'feed  79 24'

gnuplot> plot "121.15.245.215.graph.dat" using 1 with lines

     1.244e+09 ++-------+-------+--------+--------+--------+-------+-------++

               **       +       + "121.15.245.215.graph.dat" using 1 ****** +

               | *                                                          |

    1.2438e+09 ++ *                                                        ++

               |  *******                                                   |

               |         *******                                            |

               |                *********                                   |

    1.2436e+09 ++                        ****                              ++

               |                             *******                        |

               |                                    *                       |

    1.2434e+09 ++                                   *                      ++

               |                                    *                       |

               |                                    *                       |

    1.2432e+09 ++                                    *                     ++

               |                                     *                      |

               |                                     *                      |

               |                                     **                     |

     1.243e+09 ++                                      *******             ++

               |                                              **            |

               +        +       +        +        +        +    **********  +

    1.2428e+09 ++-------+-------+--------+--------+--------+-------+-------++

               0        5       10       15       20       25      30       35

[Here, the SIPs behaviour makes me more interested in plotting per port...]

grep 218.103.62.150 out.dat > 218.103.62.150.dat

more 218.103.62.150.dat 

1242901282.013137 218.103.62.150 55248 192.168.0.12 19899 T mss1394;sackok

1242901282.670295 218.103.62.150 55248 192.168.0.12 19899 T mss1394;sackok

1242901283.342359 218.103.62.150 55248 192.168.0.12 19899 T mss1394;sackok

1242901284.902925 218.103.62.150 55254 192.168.0.12 17337 T mss1394;sackok

1242901285.542566 218.103.62.150 55254 192.168.0.12 17337 T mss1394;sackok

1242901286.151354 218.103.62.150 55254 192.168.0.12 17337 T mss1394;sackok

1242901287.088508 218.103.62.150 55257 192.168.0.12 17681 T mss1394;sackok

1242901287.664895 218.103.62.150 55257 192.168.0.12 17681 T mss1394;sackok

1242901288.291307 218.103.62.150 55257 192.168.0.12 17681 T mss1394;sackok

...

gnuplot

gnuplot> set terminal dumb

gnuplot> plot "218.103.62.150.dat" using 5:1 with points

    1.2429e+09 ++------+------+-------+-------+------+-------+------+------++

               +       +      +       "218.103.62.150.dat" using 5:1+  A    +

               A                                                            |

    1.2429e+09 ++                                                          ++

               |                                                            |

               |                                                            |

               |                                                            |

    1.2429e+09 ++                                                          ++

               |                                                  A         |

               |                                                  A         |

    1.2429e+09 ++                          AA                              ++

               A          A                 A                               |

               | A                       AA                               A |

    1.2429e+09 ++A                                                        A++

               |       A A        A        A                                |

               |                                                            |

               |    A                                                       |

    1.2429e+09 A+                                                          ++

               |                                                            |

               +       +      +       +  AA  A+      +       +      +       +

    1.2429e+09 ++------+------+-------+------A+------+-------+------+------++

               0      5000  10000   15000   20000  25000   30000  35000   40000

National Cyber Security Review II

So I read as below from the 100 documents submitted for the National 60 day Cyber Security Review:

cat pdf.all.txt | wc

11596  327837 2232007

It took me two days - with copious breaks and diversions. The number of federal agencies that responded to, have something to do with, have developed cyber security standards, or assure compliance of those standards is mind-numbing. I hardly know where to start to discuss all the players and their efforts. And actually, I don't think the federal government does either. It was not untypical to read a line like this:

"There are currently several cyber collaboration centers that interact across the Federal Government space to help disseminate information on security threats, including the U.S. Computer Emergency Readiness Team (US-CERT), National Cybersecurity Center, Joint Task Force- Global Network Operations, the National Cyber Investigative Joint Task Force, the Intelligence Community Incident Response Center, the National Security Agency Threat Operations Center, and the Defense Cyber Crime Center. The exact interactions and roles of each, however, remain unclear."

I sensed confusion (even desperation), an overlap of responsibility, a lack of cohesion in development of cyber strategies and turf wars. In short, with exceptions, the only items not missing are $$$ and ideas. A lot of roadmaps  were proposed and a limited amount of security architecture was described with some interesting exceptions. I suspect that the outcome of this review will serve President Barack Obama's purposes exactly. We have the talent and the resources to become a cyber secure nation. Turf wars, in-fighting, lack of cohesive strategies and lack of prioritization of threat vectors has fragmented the national approach to cyber security.  The 60 day review puts all levels of bureacrats on watch.  What could shake out  of this is the predominance of the most brilliant and most resillient of the national cyber warrior agencies for a cohesive national cyber security strategy.  How this will happen,I do not know. But I would put a bet on NIST, NSA, DOD and CERT re-organization and leadership in this area based on what I read. There may need to be increased standards and federal scrutiny of private critical infrastructures.Occasionally, the documents contained something technically pragmatic and brilliant such as this comment:

Jeff Brown, CISO, Raytheon Company:    

"In today's cyber security environment there is one inescapable truth.  There is no way to  prevent a determined intruder from getting into a network so long as one allows email and  web surfing ­and no business today can long survive without these two bedrocks of the  information age.    The reasons for this are simple.  The vast majority of our Information Assurance  architectures rely on patching and configuration control for protection, the consistent  application of which has thus far proven elusive over large enterprises.  It also relies on  signatures for both protection and detection which, by definition, will not stop the first wave of  the increasing volume of zero day attacks we are seeing today.  Therefore, when you must let  the attack vector (an email or a web address) past your perimeter to the desktop, you are  virtually guaranteed to have successful penetrations. Raytheon believes the best way to address this new reality is to recognize that attackers  will get into your network and expand our defensive actions to detect, disrupt, and deny  attacker's command and control (C2) communications back out to the network.  It is an  acknowledgement of the fact that there are fewer, or perhaps relatively noisier, ways to get out  of a network than to get into it.  Such a strategy focuses on identifying the web sites and IP  addresses that attackers use to communicate with malicious code already infiltrated onto our  computers.  While some of these sites are legitimate sites which have been compromised, the  majority are usually new domains registered by attackers solely for the purposes of command  and control.  There is little danger of unintended consequences from blocking these web sites  and their associated IP addresses for outbound traffic.  Where they are legitimate sites, the  benefit of protecting the enterprise far outweighs any inconvenience there might be if an  employee needs to legitimately go to that site.  Raytheon has had success with this strategy,  but it requires a significant investment, unaffordable to most small and medium size entities  and many larger ones.  One of the corollaries of recognizing that networks can always be penetrated is a shift in  how we measure ourselves.  Measuring ourselves against how many intrusions occur becomes  a far less interesting.  What counts, instead is the intruder's dwell time in our network, or how  long an intruder has had access.  It's more important to recognize how successful the  penetrations were versus how many penetrations occurred."

So Raytheon is practically solving security with a novel approach - one that doesn't sacrifice utility for security. Based on a recent and comprehensive report from Verizon's business unit, Raytheon may be singular in its success. When we switched phone services to Verizon, I had no I idea I would be joining a phone network that boasts an incredibly talented cyber research division.  Verizon's 2009 Data Breach Investigations Report http://www.verizonbusiness.com/products/security/risk/databreach/ is a must read.  The book fits with Misha Glenny's (2008,2009) "McMafia: A Journey Through the Global Criminal Underworld".  Verizon found that "91% of all compromised records were attributed to organized criminal groups". 

Below are some significant quotes from this report (http://www.verizonbusiness.com/products/security/risk/databreach/):

[/STARTQUOTING]

"2008 will likely be remembered as a tumultuous year for corporations and consumers alike. Fear, uncertainty, and doubt seized global financial markets; corporate giants toppled with alarming regularity; and many who previously lived in abundance found providing for just the essentials to be difficult. Among the headlines of economic woes came reports of some of the largest data breaches in history. These events served as a reminder that, in addition to our markets, the safety and security of our information could not be assumed either.

The 2009 Data Breach Investigations Report (DBIR) covers this chaotic period in history from the viewpoint of our forensic investigators. The 90 confirmed breaches within our 2008 caseload encompass an astounding 285 million compromised records. These records have a compelling story to tell, and the pages of this report are dedicated to relaying it. As with last year, our goal is that the data and analysis presented in this report prove helpful to the planning and security efforts of our readers. Below are a few highlights from the report:

....

Some attackers simply repacked existing malware so as to make its signature undetectable by antivirus software (AV) scanners. Others leveraged existing malicious code, but modified it for additional functionality or tailored it to the victim’s environment. Most common in 2008, however, was malware that had (apparently) been created for the attack(s) entirely from scratch. In a rather sobering statistic, 85 percent of the 285 million records breached in the year were harvested by custom-created malware. It is possible that the code preexisted yet went unrecognized by the experts and tools at ICSA Labs, but this matters little to the overall point. More to the point is that, besides being more capable and better adapted, most malware used for the purpose of compromising data is not detectable by modern AV. Unfortunately, many organizations rely on AV as the primary means of malware prevention and detection. AV is certainly a foundational control, but the continuing evolution of malware leaves security programs built solely upon AV for combating malware unstable at best.

....

On the whole, organizations discovered breaches slightly quicker in 2008. However, lest we confuse “quicker” with “quickly,” this statement needs some additional context.Breaches still go undiscovered and uncontained for weeks or months in 75 percent of cases. It is doubtful that any chief security officer anywhere would call this “quick”. "

[/ENDQUOTING]

The report makes clear the general picture of what "cyberwarfare" is today: Organized crime systematically plundering finanicial records for profit without being noticed. A number of current articles confirm this:

http://www.wired.com/threatlevel/2009/04/pins/

http://www.washingtonpost.com/wp-dyn/content/article/2009/04/15/AR2009041501196.html?sid=ST2009041501334

Interesting commentary on Verizons findings can be found at their blog: http://securityblog.verizonbusiness.com/.  

I think I will spend tommorrow and the next day writing code....my capacity for integrating the amount of disparate federal offices concerned with cyber security has reached its limit.

The National Cyber Security Effort

Inside the last three months, I have restarted my network security business: RMF Network Security (www.rmfnetworksecurity.com). I have been in research mode and I am still in some type of stealth mode, as I think about the implications of restarting a consulting business in the ever dangerous and now crime-ridden world of network security. The last time I did this, I didn't do enough "product development" and research in advance of my marketing efforts.  

However, the last year of network security 'awareness' may change my need to do extensive marketing. Our President has just announced the results of the sixty day Cyber Security Review. More than 100 source papers were consulted. See my initial analysis below. I started this obscure blog with the idea that I could use the motivation of internet publishing to gauge my re-education and business progress. Inside the first month, I have had the same extensive (web interest) in my blog from American military, military-industrial complex, telecom, educational institutions that I had with my Powershell Blog (also network centric),  but this time with lots of added hits now from Russia, China, ex-Eastern bloc and Brazil IP addresses. Interestingly, 'researchers' are mostly finding their way to my blog by googling IP addresses from my script dumps!

Apparently, my visitors are either expressing interest in the same Source Internet Protocol Addresses I am logging (SIPs) simultaneously or (worse case), those SIPs are looking at me while I discuss them.   The network security business has changed since I last participated in developing IDS systems with NAI and Hiverworld. Things are bigger, badder and scarier - more criminal and nation-state oriented simultaneously. Firewalls and IPS software are being pushed beyond their intended capacities and organized crime and nation-state terrorists have become systemized at IPS evasion, spamming, botnets, bot herding,  inserting key stroke loggers, malware, etc. "Cyberwarfare" has a new and significant government interest. Here are some reads I have found lately to prepare myself for changes in the field:

    * "The Shadow Government" (James Bamford)  This book documents the build-out in the cyber capacities of the National Security Agency in the last 8 years. Among other discussions it documents  how the NSA has purchased industrial strengthcontext searching software from select software companies to analyze traffic from top network access points across all U.S. telecoms.  This apparently is the book that broke the "warrantless wiretapping" scandal a year or so back.

    * "McMafia" Misha Glenny discusses in detail recruitment the young and poor as cyber hackers for nation state terrorists and criminal organizations in Russia, Brazil, China, ex-Eastern Bloc nations and elsewhere.  He also discusses world crime and world crime sophistication to date. A downright terrifying read. Apparently, the average computer in the U.S. is seen as a potential botnet member by most of the world's criminal syndicates/hackers.

    * FOIA from Wired Magazine on the FBI's CIPAV spyware : http://www.wired.com/threatlevel/2009/04/get-your-fbi-sp Also a very inetersting read...Criminals use spyware and so does our government...Surprise!

I had some difficultly searching all the 100 assorted papers on line at http://www.whitehouse.gov/cyberreview/documents/ and resorted to mixing Cygwin and cmd.exe shells to do so. I did an initial context search, which admittedly lost papers and data at each command line.  In any event, the papers may prove interesting reading yet, although they appear at first glance more policy oriented than technical.

[from cmd.exe or Cygwin]

lynx -source http://www.whitehouse.gov/cyberreview/documents/ | grep pdf | gawk -F\" '{print $4}' > source.txt

[from cmd.exe]

for /f "delims==" %i in (source.txt) do wget "%i"

[from cmd.exe or Cygwin]

ls -1 *.pdf > source2.txt

[from cmd.exe]

@(for /f "delims==" %i in (source2.txt) do pdftotext -f 1 -l 1500 "%i" pdf.txt && cat pdf.txt >> pdf.all.txt)

[from Cygwin]

for i in `cat file`; do echo `pcregrep -w -i -c $i pdf.all.txt` `echo $i` >> context1.txt;done

[from Cygwin]

$ cat context1.txt | sort -nr

499 Infrastructure

215 Services

194 Financial

53 criminal

52 crime

45 organized

45 loss

41 spam

39 malware

27 losses

24 Firewalls

20 botnets

16 Firewall

15 tax

14 organize

14 crimes

14 China

12 botnet

9 Russia

7 Linux

6 Windows

5 IDS

4 trojans

4 bot

4 IPS

3 bots

2 trojan

2 Israel

2 India

1 IE

1 France

1 Firefox

1 Apple

0 tcpdump

0 syslogd

0 sysklogd

0 spamming

0 keyloggers

0 keylogger

0 key-strokes

0 key-stroke

0 evasion

0 Snort

0 QNX

0 Opera

0 OpenBSD

0 Chrome

0 Bulgaria

0 Brazil

0 BRIC

If you are interested and have the time, let me know if you find my blog approachable, and what interests you think would most drive your businesses and professions to read and think about network security.  I think I am gearing up to producing some white papers tailored to many audience types: business, personal, home user, etc.  The goal is to generate interest for consulting contracts. 

Homegrown tcpdump/snort analysis

I have written a script which parses snort and/or tcpdump text files to display significant information for Source and Destination IPs and ports.This script allows for some flexibility in filtering ports and ultimately produces separate files for each query and summary statistics as shown below. Tcptrace does similar work but I thought I would contribute something homegrown before I started looking in depth at existing tcp/IDS trace analysis tools.

## bash or ksh script to sort IP addresses from tcpdump or snort text output
## version 0.1 May 23 2009
## requires one argument: file name consisting of text dump of snort or tcpdump output
## requires pcregrep, awk,nmap services file, geoiplookup

/* rest of script here: http://www.rmfdevelopment.com/UnixShellScripts/LocateIP.sh.txt */

[some sample output:]
......Summary Statistics........
248 unique Source IP/ port pairs
190 unique source addresses
155 unique source ports
125 unique Destination IP/port pairs
6 unique destination addresses
124 unique destination ports
42 Source ports recognized by nmap services file
38 Destination ports recognized by nmap services file
190 Source cities recognized by GeoLiteCity.dat

[some sample files produced]
# ls -1 uniq*
uniqDIP.txt
uniqDIPPorts.txt
uniqDestIPs.txt
uniqIPs.txt
uniqSIP.txt
uniqSIPPorts.txt
uniqSourceIPs.txt

Host Protection: Working with Microsoft's Firewall

Both network and host protection are recommended. Each OS has native firewall host protection:

OpenBSD: pf

FreeBSD: pfsense

Fedora Cora: iptables with SELinux

Windows XP,2003,2008,Vista,7 : Windows Firewall (ICF)

Microsoft's native firewall on XP SP3 can be told to log all incoming and outgoing packets up to a maximum log size of 32676 bytes(2^15). It will turn over twice before rewriting the old log file name.  A full examination of the Firewall's configuration is beyond the scope of this post.  A regedt32 query of StandardProfiles and DomainProfiles for all Control Sets for all globally open ports and authorized applications is recommended as is a manual exploration of the appropriate regedt32 keys. (Netsh commands are available for all Firewalled Windows. Please see http://support.microsoft.com/kb/947709 . Powershell can also be used to configure Microsoft's Firewall. ):   

regquery HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\AuthorizedApplications\List | findstr Enabled

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List | findstr Enabled

A sample partial result would be: 

reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List | findstr Enabled

    139:TCP     REG_SZ  139:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22004

    445:TCP     REG_SZ  445:TCP:LocalSubNet:Enabled:@xpsp2res.dll,-22005

    137:UDP     REG_SZ  137:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22001

    138:UDP     REG_SZ  138:UDP:LocalSubNet:Enabled:@xpsp2res.dll,-22002

    53:UDP      REG_SZ  53:UDP:LocalSubNet:Enabled:DNS-UDP

    53:TCP      REG_SZ  53:TCP:LocalSubNet:Enabled:DNS

    500:UDP     REG_SZ  500:UDP:*:Enabled:@xpsp2res.dll,-22017

The pfirewall.log gives a considerable amount of information as such:

more pfirewall.log

#Version: 1.5

#Software: Microsoft Windows Firewall

#Time Format: Local

#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2009-04-23 10:24:55 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:56 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 138 138 202 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 78 - - - - - - - RECEIVE

2009-04-23 10:24:57 DROP UDP 192.168.0.4 192.168.0.255 137 137 96 - - - - - - - RECEIVE

....

Using Cygwin's Bash client and gawk, a list of src and dst ports can be obtained: 

cat /cygdrive/D/pfirewall.log | awk -F" " '{print $7}' | sort -nr | uniq -c | sort -nr | more

cat /cygdrive/D/pfirewall.log | awk -F" " '{print $8}' | sort -nr | uniq -c | sort -nr | more

Gawk's conditional logic coupled with pcregrep quick searching helps us print the frequency of a destination IP and accompanying port(s) for a specified source IP:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | sort -nr | more

  16138 192.168.0.1:53

    902 192.168.0.1:80

    446 74.125.242.24:80

    359 65.214.57.165:80

    304 216.73.87.115:80

    272 85.13.200.108:110

    247 70.32.92.85:80

    240 216.73.87.152:80

    215 75.101.163.8:80

    208 68.142.93.133:80

    203 74.125.127.191:80

    201 128.111.41.37:80

....

Now we choose to sort by the frequency of one specific dst port for each dst IP from the specified (local) source IP:

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | pcregrep ':443' | sort -nr

    113 74.125.53.147:443

     92 74.125.53.83:443

     78 208.235.248.150:443

     50 208.75.76.32:443

     46 74.125.127.103:443

     30 74.125.53.97:443

     24 74.125.127.120:443

     23 65.55.157.60:443

     22 96.6.248.124:443

     21 74.125.53.99:443

...

For example, I was surprised to find all the foreign addresses that my local computer asked NBNS queries of: 

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $6 ":" $8}' | sort -nr | uniq -c | pcregrep ':137' | sort -nr

  42 192.168.0.4:137

  39 192.168.0.6:137

  36 192.168.0.2:137

  16 192.168.0.9:137

  15 206.51.224.187:137

  14 208.117.252.85:137

  14 192.168.0.1:137

  13 206.72.124.93:137

  11 74.125.103.33:137

  10 64.94.107.20:137

  10 64.236.79.54:137

  10 206.191.161.8:137

...

The dates and times of those queries could be found with: 

cat /cygdrive/D/pfirewall.log | pcregrep OPEN | awk -F" " '{if ($5=="192.168.0.8") print $1 ":" $4 ":" $6 ":" $8}' | pcregrep ':137' | sort -nr | more

2009-05-14:UDP:192.168.0.4:137

2009-05-14:UDP:192.168.0.4:137

2009-05-06:UDP:75.52.124.131:137

2009-05-06:UDP:74.125.103.28:137

2009-05-06:UDP:69.64.6.21:137

2009-05-06:UDP:66.35.45.202:137

2009-05-06:UDP:66.35.45.202:137

2009-05-06:UDP:66.35.45.202:137

2009-05-06:UDP:66.35.45.201:137

2009-05-06:UDP:66.35.45.201:137

2009-05-06:UDP:66.35.45.201:137

2009-05-06:UDP:65.55.52.84:137

2009-05-06:UDP:65.55.52.148:137

2009-05-06:UDP:65.55.185.61:137

2009-05-06:UDP:65.55.185.29:137

2009-05-06:UDP:65.55.184.189:137

2009-05-06:UDP:65.173.218.69:137

2009-05-06:UDP:65.173.218.69:137

2009-05-06:UDP:64.94.107.16:137

2009-05-06:UDP:64.236.115.52:137

2009-05-06:UDP:4.71.104.187:137

....

These two commands are also recommended:

C:\WINDOWS\system32\drivers\etc>net config server

C:\WINDOWS\system32\drivers\etc>net config workstation

Bash 4.0,awk,geoiplookup and pcregrep are fast

Bash 4.0,awk,geoiplookup and pcregrep make a powerfully fast search team.  Here I find out how many sockets pairs are in my Snort dump: 

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | wc -l                   

     372 

Then I find out how many uniqe SIPs are in those socket pairs:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | uniq | sort -nr | wc -l

     226 

Then I find my top ten Source IP Addresses:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep TTL | awk -F":" '{print $1}' | sort | uniq -c | sort -nr | head -n 10

  

  62 218.103.62.150

  15 222.215.230.49

  14 221.195.73.68

  11 121.15.245.215

  10 119.161.130.75

   8 209.85.163.126

   8 125.65.165.139

   7 66.35.46.195

   7 209.85.201.125

   6 64.106.128.150

....

Then I determine what source ports my top SIP (foreign address) has initiated connections to:

bash-4.0# snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep 218.103.62.150 | awk -F":" '{print $3}'| awk -F" " '{print $1}' | sort -n | uniq

113

160

1433

1434

2967

5554

6429

7212

12712

16896

17337

17681

17919

18448

18487

18488

18649

18932

19899

33436

38507

Next I find what are the top source ports for my top ten SIPs: 

bash-4.0# for i in `cat temp.txt`; do echo $i && snort -qdevX -r May12085154PDT2009.1242143514 | pcregrep $i | awk -F":" '{print $3}'| awk -F" " '{print $1}' | sort | uniq -c | sort -nr; done

218.103.62.150

   3 6429

   3 5554

   3 38507

   3 33436

   3 2967

   3 19899

   3 18932

   3 18649

   3 18488

   3 18487

   3 18448

   3 17919

   3 17681

   3 17337

   3 16896

   3 160

   3 1434

   3 1433

   3 12712

   3 113

   2 7212

222.215.230.49

   6 7212

   6 3128

   3 8000

221.195.73.68

   7 8000

   7 7212

121.15.245.215

   7 3128

   4 8000

119.161.130.75

  10 2967

209.85.163.126

   8 33137

125.65.165.139

   4 8000

   4 3128

66.35.46.195

   7 33436

209.85.201.125

   3 18205

   3 18184

   1 18077

64.106.128.150

   6 33442

Last, I retrieve those top ten SIP city locations:

bash-4.0# for i in `cat temp.txt`; do echo $i `snort -qdevX -r May12085154PDT2009.1242143514 | geoiplookup $i -f /usr/local/share/GeoIP/GeoLiteCity.dat` ;done

218.103.62.150 GeoIP City Edition, Rev 1: HK, 00, Kowloon, (null), 22.316700, 114.183296, 0, 0

222.215.230.49 GeoIP City Edition, Rev 1: CN, 32, Chengdu, (null), 30.666700, 104.066597, 0, 0

221.195.73.68 GeoIP City Edition, Rev 1: CN, 10, Hebei, (null), 39.889702, 115.275002, 0, 0

121.15.245.215 GeoIP City Edition, Rev 1: CN, 30, Jiangmen, (null), 22.583300, 113.083298, 0, 0

119.161.130.75 GeoIP City Edition, Rev 1: CN, 19, Chaoyang, (null), 41.570301, 120.458603, 0, 0

209.85.163.126 GeoIP City Edition, Rev 1: US, CA, Mountain View, 94043, 37.419201, -122.057404, 807, 650

125.65.165.139 GeoIP City Edition, Rev 1: CN, 32, Chengdu, (null), 30.666700, 104.066597, 0, 0

66.35.46.195 GeoIP City Edition, Rev 1: US, CO, Denver, 80216, 39.785000, -104.941498, 751, 303

209.85.201.125 GeoIP City Edition, Rev 1: US, CA, Mountain View, 94043, 37.419201, -122.057404, 807, 650

64.106.128.150 GeoIP City Edition, Rev 1: US, NJ, Hoboken, 07030, 40.745800, -74.032097, 501, 201

Understanding an attack

Snort can be run in daemon mode, with a configuration file that logs on certain alerts only. For demonstration, we can run Snort in 'packet dump' mode (-dev) for a day or so while using BPF filters for our own needs:

/usr/local/bin/snort -devX -i xl0 -L $(date "+%b%e%H%M%S%Z%Y") 'port not(domain or whois or http or https or syslog or ntp or smtp or 137 or 139)' and 'not(broadcast or icmp or igmp or arp)'

After some awkward awk statements and some ditzy KSH work, we have a list of ports others who are seeking our network seem interested in:

snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | awk -F"->" '{print $1 ":" $2 ":" $3}' | awk -F":" '{print $4}' | awk -F" " '{print $1}' | sort -nr | uniq -c | sort -nr

14 2967
6 8000
6 5900
6 3128
6 22
5 23
5 1434
5 12712
4 7212
4 4899
4 1433
1 8080
1 7209
1 65535
1 56017
1 3306
1 23803
1 21
1 19756
1 19696
1 1024

snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | awk -F"->" '{print $1 ":" $2 ":" $3}' | awk -F":" '{print $4}' | awk -F" " '{print $1}' | sort | uniq | sort -nr >> ports.txt

for i in `cat ports.txt`; do grep -w $i /usr/local/share/nmap/nmap-services;done

http-proxy 8080/tcp # Common HTTP proxy/second web server port
http-alt 8000/tcp # A common alternative http port
vnc 5900/tcp # Virtual Network Computer display
radmin 4899/tcp # Radmin (www.radmin.com) remote PC control software
mysql 3306/tcp # mySQL
squid-http 3128/tcp #
symantec-av 2967/udp # Symantec AntiVirus (rtvscan.exe)
ms-sql-m 1434/tcp # Microsoft-SQL-Monitor
ms-sql-m 1434/udp # Microsoft-SQL-Monitor
ms-sql-s 1433/tcp # Microsoft-SQL-Server
ms-sql-s 1433/udp # Microsoft-SQL-Server
kdm 1024/tcp # K Display Manager (KDE version of xdm)
telnet 23/tcp #
telnet 23/udp #
ssh 22/tcp # Secure Shell Login
ssh 22/udp # Secure Shell Login
ftp 21/tcp # File Transfer [Control]
ftp 21/udp # File Transfer [Control]

Nmap services file helps explain much here, but why the large interest in a Symantec AntiVirus port? It turns out others have noticed this recently as well and are asking for input:

http://isc.sans.org/diary.html?storyid=6319.
http://msmvps.com/blogs/harrywaldron/archive/2006/11/27/new-botnet-impacts-symantec-client-port-2967-on-unpatched-pcs.aspx
http://www.offensivecomputing.net/?q=node/403

Is this a new or mutated trojan? worm? remote exploit? Multiple addresses are interested in connecting to us on this port:

# snort -vdeX -r May12085154PDT2009.1242143514 | grep TTL: | grep 2967 | sort -nr | uniq -c | sort -nr

3 218.75.95.242:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:256 IpLen:20 DgmLen:40
2 119.161.130.75:6000 -> 192.168.0.12:2967 TCP TTL:99 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 61.191.63.8:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 61.145.62.75:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 60.173.12.60:6000 -> 192.168.0.12:2967 TCP TTL:106 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 60.172.229.11:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:65419 IpLen:20 DgmLen:40
1 60.172.229.11:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:42349 IpLen:20 DgmLen:40
1 222.186.26.93:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.140.174.105:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.14.156.149:6000 -> 192.168.0.12:2967 TCP TTL:102 TOS:0x20 ID:256 IpLen:20 DgmLen:40
1 121.14.156.148:6000 -> 192.168.0.12:2967 TCP TTL:103 TOS:0x20 ID:256 IpLen:20 DgmLen:40

But the packet looks like a simple connection attempt to a remote port. A buffer overflow in Symantec AntiVirus port?

218.75.95.242:6000 -> 192.168.0.12:2967 TCP TTL:105 TOS:0x20 ID:256 IpLen:20 DgmLen:40
******S* Seq: 0x60B40000 Ack: 0x0 Win: 0x4000 TcpLen: 20
0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E
0x0010: 00 28 01 00 00 00 69 06 55 BE DA 4B 5F F2 C0 A8 .(....i.U..K_...
0x0020: 00 0C 17 70 0B 97 60 B4 00 00 00 00 00 00 50 02 ...p..`.......P.
0x0030: 40 00 F1 34 00 00 00 00 00 00 00 00 @..4........

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

05/13-12:59:50.507559 0:9:5B:0:F3:DA -> 0:60:97:30:6B:C4 type:0x800 len:0x3C
121.140.174.105:6000 -> 192.168.0.12:2967 TCP TTL:107 TOS:0x20 ID:256 IpLen:20 DgmLen:40
******S* Seq: 0x4260000 Ack: 0x0 Win: 0x4000 TcpLen: 20
0x0000: 00 60 97 30 6B C4 00 09 5B 00 F3 DA 08 00 45 20 .`.0k...[.....E
0x0010: 00 28 01 00 00 00 6B 06 66 06 79 8C AE 69 C0 A8 .(....k.f.y..i..
0x0020: 00 0C 17 70 0B 97 04 26 00 00 00 00 00 00 50 02 ...p...&......P.
0x0030: 40 00 60 0B 00 00 00 00 00 00 00 00 @.`.........