- •Network Intrusion Detection, Third Edition
- •Table of Contents
- •Copyright
- •About the Authors
- •About the Technical Reviewers
- •Acknowledgments
- •Tell Us What You Think
- •Introduction
- •Chapter 1. IP Concepts
- •Layers
- •Data Flow
- •Packaging (Beyond Paper or Plastic)
- •Bits, Bytes, and Packets
- •Encapsulation Revisited
- •Interpretation of the Layers
- •Addresses
- •Physical Addresses, Media Access Controller Addresses
- •Logical Addresses, IP Addresses
- •Subnet Masks
- •Service Ports
- •IP Protocols
- •Domain Name System
- •Routing: How You Get There from Here
- •Summary
- •Chapter 2. Introduction to TCPdump and TCP
- •TCPdump
- •TCPdump Behavior
- •Filters
- •Binary Collection
- •TCPdump Output
- •Absolute and Relative Sequence Numbers
- •Dumping in Hexadecimal
- •Introduction to TCP
- •Establishing a TCP Connection
- •Server and Client Ports
- •Connection Termination
- •The Graceful Method
- •The Abrupt Method
- •Data Transfer
- •What's the Bottom Line?
- •TCP Gone Awry
- •An ACK Scan
- •A Telnet Scan?
- •TCP Session Hijacking
- •Summary
- •Chapter 3. Fragmentation
- •Theory of Fragmentation
- •All Aboard the Fragment Train
- •The Fragment Dining Car
- •The Fragment Caboose
- •Viewing Fragmentation Using TCPdump
- •Fragmentation and Packet-Filtering Devices
- •The Don't Fragment Flag
- •Malicious Fragmentation
- •TCP Header Fragments
- •Teardrop
- •Summary
- •Chapter 4. ICMP
- •ICMP Theory
- •Why Do You Need ICMP?
- •Where Does ICMP Fit In?
- •Understanding ICMP
- •Summary of ICMP Theory
- •Mapping Techniques
- •Tireless Mapper
- •Efficient Mapper
- •Clever Mapper
- •Cerebral Mapper
- •Summary of Mapping
- •Normal ICMP Activity
- •Host Unreachable
- •Port Unreachable
- •Admin Prohibited
- •Need to Frag
- •Time Exceeded In-Transit
- •Embedded Information in ICMP Error Messages
- •Summary of Normal ICMP
- •Malicious ICMP Activity
- •Smurf Attack
- •Tribe Flood Network
- •WinFreeze
- •Loki
- •Unsolicited ICMP Echo Replies
- •Theory 1: Spoofing
- •Theory 2: TFN
- •Theory 3: Loki
- •Summary of Malicious ICMP Traffic
- •To Block or Not to Block
- •Unrequited ICMP Echo Requests
- •Kiss traceroute Goodbye
- •Silence of the LANs
- •Broken Path MTU Discovery
- •Summary
- •Chapter 5. Stimulus and Response
- •The Expected
- •Request for Comments
- •TCP Stimulus-Response
- •Destination Host Listens on Requested Port
- •Destination Host Not Listening on Requested Port
- •Destination Host Doesn't Exist
- •Destination Port Blocked
- •Destination Port Blocked, Router Doesn't Respond
- •UDP Stimulus-Response
- •Destination Host Listening on Requested Port
- •Destination Host Not Listening on Requested Port
- •Windows tracert
- •TCPdump of tracert
- •Protocol Benders
- •Active FTP
- •Passive FTP
- •UNIX Traceroute
- •Summary of Expected Behavior and Protocol Benders
- •Abnormal Stimuli
- •Evasion Stimulus, Lack of Response
- •Evil Stimulus, Fatal Response
- •No Stimulus, All Response
- •Unconventional Stimulus, Operating System Identifying Response
- •Bogus "Reserved" TCP Flags
- •Anomalous TCP Flag Combinations
- •No TCP Flags
- •Summary of Abnormal Stimuli
- •Summary
- •Chapter 6. DNS
- •Back to Basics: DNS Theory
- •The Structure of DNS
- •Steppin' Out on the Internet
- •DNS Resolution Process
- •TCPdump Output of Resolution
- •Strange TCPdump Notation
- •Caching: Been There, Done That
- •Reverse Lookups
- •Master and Slave Name Servers
- •Zone Transfers
- •Summary of DNS Theory
- •Using DNS for Reconnaissance
- •The nslookup Command
- •Name That Name Server
- •HINFO: Snooping for Details
- •List Zone Map Information
- •Tainting DNS Responses
- •A Weak Link
- •Cache Poisoning
- •Summary
- •Part II: Traffic Analysis
- •Chapter 7. Packet Dissection Using TCPdump
- •Why Learn to Do Packet Dissection?
- •Sidestep DNS Queries
- •Normal Query
- •Evasive Query
- •Introduction to Packet Dissection Using TCPdump
- •Where Does the IP Stop and the Embedded Protocol Begin?
- •Other Length Fields
- •The IP Datagram Length
- •Increasing the Snaplen
- •Dissecting the Whole Packet
- •Freeware Tools for Packet Dissection
- •Ethereal
- •tcpshow
- •Summary
- •Chapter 8. Examining IP Header Fields
- •Insertion and Evasion Attacks
- •Insertion Attacks
- •Evasion Attacks
- •IP Header Fields
- •IP Version Number
- •Protocol Number
- •The Don't Fragment (DF) Flag
- •The More Fragments (MF) Flag
- •Mapping Using Incomplete Fragments
- •IP Numbers
- •IP Identification Number
- •Time to Live (TTL)
- •Looking at the IP ID and TTL Values Together to Discover Spoofing
- •IP Checksums
- •Summary
- •Chapter 9. Examining Embedded Protocol Header Fields
- •Ports
- •TCP Checksums
- •TCP Sequence Numbers
- •Acknowledgement Numbers
- •TCP Flags
- •TCP Corruption
- •ECN Flag Bits
- •Operating System Fingerprinting
- •Retransmissions
- •Using Retransmissions Against a Hostile Host—LaBrea Tarpit Version 1
- •TCP Window Size
- •LaBrea Version 2
- •Ports
- •UDP Port Scanning
- •UDP Length Field
- •ICMP
- •Type and Code
- •Identification and Sequence Numbers
- •Misuse of ICMP Identification and Sequence Numbers
- •Summary
- •Chapter 10. Real-World Analysis
- •You've Been Hacked!
- •Netbus Scan
- •How Slow Can you Go?
- •RingZero Worm
- •Summary
- •Chapter 11. Mystery Traffic
- •The Event in a Nutshell
- •The Traffic
- •DDoS or Scan
- •Source Hosts
- •Destination Hosts
- •Scanning Rates
- •Fingerprinting Participant Hosts
- •Arriving TTL Values
- •TCP Window Size
- •TCP Options
- •TCP Retries
- •Summary
- •Part III: Filters/Rules for Network Monitoring
- •Chapter 12. Writing TCPdump Filters
- •The Mechanics of Writing TCPdump Filters
- •Bit Masking
- •Preserving and Discarding Individual Bits
- •Creating the Mask
- •Putting It All Together
- •TCPdump IP Filters
- •Detecting Traffic to the Broadcast Addresses
- •Detecting Fragmentation
- •TCPdump UDP Filters
- •TCPdump TCP Filters
- •Filters for Examining TCP Flags
- •Detecting Data on SYN Connections
- •Summary
- •Chapter 13. Introduction to Snort and Snort Rules
- •An Overview of Running Snort
- •Snort Rules
- •Snort Rule Anatomy
- •Rule Header Fields
- •The Action Field
- •The Protocol Field
- •The Source and Destination IP Address Fields
- •The Source and Destination Port Field
- •Direction Indicator
- •Summary
- •Chapter 14. Snort Rules - Part II
- •Format of Snort Options
- •Rule Options
- •Msg Option
- •Logto Option
- •Ttl Option
- •Id Option
- •Dsize Option
- •Sequence Option
- •Acknowledgement Option
- •Itype and Icode Options
- •Flags Option
- •Content Option
- •Offset Option
- •Depth Option
- •Nocase Option
- •Regex Option
- •Session Option
- •Resp Option
- •Tag Option
- •Putting It All Together
- •Summary
- •Part IV: Intrusion Infrastructure
- •Chapter 15. Mitnick Attack
- •Exploiting TCP
- •IP Weaknesses
- •SYN Flooding
- •Covering His Tracks
- •Identifying Trust Relationships
- •Examining Network Traces
- •Setting Up the System Compromise?
- •Detecting the Mitnick Attack
- •Trust Relationship
- •Port Scan
- •Host Scan
- •Connections to Dangerous Ports
- •TCP Wrappers
- •Tripwire
- •Preventing the Mitnick Attack
- •Summary
- •Chapter 16. Architectural Issues
- •Events of Interest
- •Limits to Observation
- •Human Factors Limit Detects
- •Limitations Caused by the Analyst
- •Limitations Caused by the CIRTs
- •Severity
- •Criticality
- •Lethality
- •Countermeasures
- •Calculating Severity
- •Scanning for Trojans
- •Analysis
- •Severity
- •Host Scan Against FTP
- •Analysis
- •Severity
- •Sensor Placement
- •Outside Firewall
- •Sensors Inside Firewall
- •Both Inside and Outside Firewall
- •Analyst Console
- •Faster Console
- •False Positive Management
- •Display Filters
- •Mark as Analyzed
- •Drill Down
- •Correlation
- •Better Reporting
- •Event-Detection Reports
- •Weekly/Monthly Summary Reports
- •Summary
- •Chapter 17. Organizational Issues
- •Organizational Security Model
- •Security Policy
- •Industry Practice for Due Care
- •Security Infrastructure
- •Implementing Priority Countermeasures
- •Periodic Reviews
- •Implementing Incident Handling
- •Defining Risk
- •Risk
- •Accepting the Risk
- •Trojan Version
- •Malicious Connections
- •Mitigating or Reducing the Risk
- •Network Attack
- •Snatch and Run
- •Transferring the Risk
- •Defining the Threat
- •Recognition of Uncertainty
- •Risk Management Is Dollar Driven
- •How Risky Is a Risk?
- •Quantitative Risk Assessment
- •Qualitative Risk Assessments
- •Why They Don't Work
- •Summary
- •Chapter 18. Automated and Manual Response
- •Automated Response
- •Architectural Issues
- •Response at the Internet Connection
- •Internal Firewalls
- •Host-Based Defenses
- •Throttling
- •Drop Connection
- •Shun
- •Proactive Shunning
- •Islanding
- •Reset
- •Honeypot
- •Proxy System
- •Empty System
- •Honeypot Summary
- •Manual Response
- •Containment
- •Freeze the Scene
- •Sample Fax Form
- •On-Site Containment
- •Site Survey
- •System Containment
- •Hot Search
- •Eradication
- •Recovery
- •Lessons Learned
- •Summary
- •Chapter 19. Business Case for Intrusion Detection
- •Part One: Management Issues
- •Bang for the Buck
- •The Expenditure Is Finite
- •Technology Used to Destabilize
- •Network Impacts
- •IDS Behavioral Modification
- •The Policy
- •Part of a Larger Strategy
- •Part Two: Threats and Vulnerabilities
- •Threat Assessment and Analysis
- •Threat Vectors
- •Threat Determination
- •Asset Identification
- •Valuation
- •Vulnerability Analysis
- •Risk Evaluation
- •Part Three: Tradeoffs and Recommended Solution
- •Identify What Is in Place
- •Identify Your Recommendations
- •Identify Options for Countermeasures
- •Cost-Benefit Analysis
- •Follow-On Steps
- •Repeat the Executive Summary
- •Summary
- •Chapter 20. Future Directions
- •Increasing Threat
- •Improved Targeting
- •How the Threat Will Be Manifested
- •Defending Against the Threat
- •Skills Versus Tools
- •Analysts Skill Set
- •Improved Tools
- •Defense in Depth
- •Emerging Techniques
- •Virus Industry Revisited
- •Smart Auditors
- •Summary
- •Part V: Appendixes
- •Appendix A. Exploits and Scans to Apply Exploits
- •False Positives
- •All Response, No Stimulus
- •Scan or Response?
- •SYN Floods
- •Valid SYN Flood
- •False Positive SYN Flood
- •Back Orifice?
- •IMAP Exploits
- •10143 Signature Source Port IMAP
- •111 Signature IMAP
- •Source Port 0, SYN and FIN Set
- •Source Port 65535 and SYN FIN Set
- •DNS Zone Followed by 0, SYN FIN Targeting NFS
- •Scans to Apply Exploits
- •mscan
- •Son of mscan
- •Access Builder?
- •Single Exploit, Portmap
- •rexec
- •Targeting SGI Systems?
- •Discard
- •Weird Web Scans
- •IP-Proto-191
- •Summary
- •Appendix B. Denial of Service
- •Brute-Force Denial-of-Service Traces
- •Smurf
- •Directed Broadcast
- •Echo-Chargen
- •Elegant Kills
- •Teardrop
- •Land Attack
- •We're Doomed
- •nmap
- •Distributed Denial-of-Service Attacks
- •Intro to DDoS
- •DDoS Software
- •Trinoo
- •Stacheldraht
- •Summary
- •Appendix C. Detection of Intelligence Gathering
- •Network and Host Mapping
- •Host Scan Using UDP Echo Requests
- •Netmask-Based Broadcasts
- •Port Scan
- •Scanning for a Particular Port
- •Complex Script, Possible Compromise
- •"Random" Port Scan
- •Database Correlation Report
- •SNMP/ICMP
- •FTP Bounce
- •NetBIOS-Specific Traces
- •A Visit from a Web Server
- •Null Session
- •Stealth Attacks
- •Explicit Stealth Mapping Techniques
- •FIN Scan
- •Inverse Mapping
- •Answers to Domain Queries
- •Answers to Domain Queries, Part 2
- •Fragments, Just Fragments
- •Measuring Response Time
- •Echo Requests
- •Actual DNS Queries
- •Probe on UDP Port 33434
- •3DNS to TCP Port 53
- •Worms as Information Gatherers
- •Pretty Park Worm
- •RingZero
- •Summary
As previously noted, the 0 source port and the SF flag sets are a signature for a common IMAP exploit. This attack directed at NFS almost certainly shares code with that exploit. These code branches help to identify attackers who write, modify, or compile code as opposed to those who can run only existing exploits. What apparently has happened is that the attacker has bolted a different exploit onto an older delivery system.
Say what? Well, we make the case later that at least some part of what we are dealing with is warfare. In weapons, one often separates the warhead from the delivery system. For instance:
∙Archers could use one tip for firing into infantry and a different arrowhead for launching flaming arrows at castles.
∙Catapults could throw rocks to bust walls or dissuade charges, but could also throw flaming missiles if that was what was needed.
∙Modern cruise missiles can carry conventional weapons and slip in the enemy's bedroom window (or so the Gulf War footage would have us believe) or they can carry nuclear warheads.
In each of these cases, a delivery system can fire multiple exploits (I mean warheads). You should not be surprised to see the same principle in information warfare. The arrowhead in the following trace is the NFS port, 2049. The signature of the delivery mechanism (source port 0 and SYN/FIN set) is shown in bold:
12:11:48 prober.21945 > ns1.net.53: SF 1666526414:1666526414(0) win 512 12:11:49 prober.21951 > ns2.net.53: SF 11997410:211997410(0) win 512
12:36:54 prober.0 > relay.net.2049: SF 3256287232:3256287232(0) win 512 12:37:03 prober.0 > web.net.2049: SF 3256287232:3256287232(0) win 512 12:37:05 prober.0 > relay2.net.2049: SF 3256287232:3256287232(0) win 512
This pattern has continued. One classic sighting was in February 2000; posters to GIAC were reporting source port 0, SF set to TCP port 109, the POP2 service. This pattern has most recently mutated to reflexive source and destination ports—for example, source port 109, SF set to destination port 109. A final note about the preceding trace: This individual is probably a rookie. If you hit a site with an exploit and do not get in, it is far wiser to move to a different IP address before trying again. Using the same IP address twice increases your risk of a knock on the door from federal agents. That said, this was the first time we saw the code branch to the NFS exploit. There are no easy answers. And, it is still going on. In December 2001, we picked up an attack against secure shell (TCP 22), source port 22, destination port 22, SF set.
Scans to Apply Exploits
This final section discusses a number of interesting patterns that, with the exception of discard and IP-191, tend to use well-known vulnerable ports. One challenge you face when sorting out the exploit tools from the scan tools is that because most sites use their firewall or filtering
router to block risky ports, it becomes difficult to collect information. With TCP-based attacks, for instance, the three-way handshake never completes because the connection is blocked, which makes it all but impossible to know the intention of the attacker.
The first trace examined here is the mscan pattern, a favorite tool of attackers.
mscan
The following trace is representative of one of a very common attack pattern, mscan. The multiscan exploit code is widely available and does not indicate an "eleet" or well-connected attacker. That said, it gets its fair share of system compromises, because it scans for vulnerabilities present in a large number of systems connected to the Internet:
06:13:23.188197 bad.guy.org.6479 |
> target.mynetwork.com.23: |
S |
06:13:28.071161 bad.guy.org.15799 |
> target.mynetwork.com.80: |
S |
06:13:33.107599 bad.guy.org.25467 |
> target.mynetwork.com.143: S |
|
06:13:38.068035 bad.guy.org.3861 |
> target.mynetwork.com.53: |
S |
06:13:43.271220 bad.guy.org.14296 |
> target.mynetwork.com.110: S |
|
06:13:47.831695 bad.guy.org.943 |
> target.mynetwork.com.111: S |
|
AL-98.01 AusCERT Alert multiscan (mscan) Tool 20 July 1998,
ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-98.01.mscan:
"AusCERT has received reports indicating a recent and substantial increase in network scanning activity. It is believed that intruders are using a new tool called 'Multiscan' or 'mscan'. This tool enables the user to scan whole domains and complete ranges of IP addresses to discover wellknown vulnerabilities in the following services: statd nfs cgi-bin Programs ('handler', 'phf' & 'cgitest,' for example) X, POP3, IMAP, Domain Name Servers, finger."
So, you ask, "What is a scanner doing in the exploit chapter?" Sue me! The exploits for telnet, Web, IMAP, DNS, POP3, and Portmap are so numerous and so well known I thought it was appropriate.
Son of mscan
Of course, if one attacker has mscan, another has to do it one better. The following trace was first seen in November 1998. We can learn some things from this trace. The scan rate is on the order of 10 packets per second. That is no record, but it is fast. We would certainly hope our intrusion-detection system's port scan detect code would take note of 10 SYN packets to different ports on the same system in one second!
What are all those ports? Throughout the book, I use the Internet Assigned Numbers Authority
(IANA) paper on ports (ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers) for services 1024 and below.
Above 1024 is a mess, and we work through these ports carefully. If you have an Internet connection, you might want to download a copy of the port listing now. Another excellent source of information is an /etc/services file from a UNIX computer, the best being the one that ships with FreeBSD. However, I am learning more and more to use Google (www.google.com).You simply type port 12345 or whatever and then read the discussions. Everyone knows 12345 is Netbus, but I didn't know that it is also a license manager. Nor did I know that Trend Micro uses this as a listening port. I would have never known about this if I had not queried Google. If you don't have access to one, or the time to go get one, refer to the service names at the beginning
of each line for this trace:
Echo20:50:19.872769 prober.1454 > mail.relay.7: S 7460483:7460483(0) win 8192 (DF)
Discard20:50:19.881293 prober.1455 > mail.relay.9: S 7460502:7460502(0) win 8192 (DF)
Quote of the Day20:50:19.916488 prober.1456 > mail.relay.17: S 7460545:7460545(0) win 8192 (DF)
Daytime20:50:19.983115 prober.1457 > mail.relay.13: S 7460592:7460592(0) win 8192 (DF)
Chargen20:50:20.026572 prober.1458 > mail.relay.19: S 7460646:7460646(0) win 8192 (DF)
FTP20:50:20.118159 prober.1459 > mail.relay.21: S 7460745:7460745(0) win 8192 (DF)
Telnet20:50:20.215007 prober.1460 > mail.relay.23: S 7460845:7460845(0) win 8192 (DF)
Time20:50:20.415433 prober.1462 > mail.relay.37: S 7461008:7461008(0) win 8192 (DF)
DNS20:50:20.475574 prober.1463 > mail.relay.53: S 7461095:7461095(0) win 8192 (DF)
Gopher20:50:20.616177 prober.1464 > mail.relay.70: S 7461209:7461209(0) win 8192 (DF)
Finger20:50:20.675549 prober.1465 > mail.relay.79: S 7461295:7461295(0) win 8192 (DF)
HTTP20:50:20.766639 prober.1466 > mail.relay.80: S 7461396:7461396(0) win 8192 (DF)
TSMUX20:50:20.869773 prober.1467 > mail.relay.106: S 7461494:7461494(0) win 8192 (DF)
POP220:50:20.983764 prober.1468 > mail.relay.109: S 7461608:7461608(0) win 8192 (DF)
POP3-20:50:21.040400 prober.1469 > mail.relay.110: S 7461645:7461645(0) win 8192 (DF)
Portmap20:50:21.125914 prober.1470 > mail.relay.111: S 7461746:7461746(0) win 8192 (DF)
NNTP20:50:21.224194 prober.1471 > mail.relay.119: S 7461846:7461846(0) win 8192 (DF)
NetBIOS20:50:21.325783 prober.1472 > mail.relay.139: S 7461955:7461955(0) win 8192 (DF)
SMUX20:50:21.415527 prober.1473 > mail.relay.199: S 7462046:7462046(0) win 8192 (DF)
REXEC20:50:21.483920 prober.1474 > mail.relay.512: S 7462096:7462096(0) win 8192 (DF)
RLOGIN20:50:21.543247 prober.1475 > mail.relay.513: S 7462194:7462194(0) win 8192 (DF)
RSHELL20:50:21.577268 prober.1476 > mail.relay.514: S 7462199:7462199(0) win 8192 (DF)
PRINTER20:50:21.581449 prober.1477 > mail.relay.515: S 7462203:7462203(0) win 8192 (DF)
UUCP20:50:21.615331 prober.1478 > mail.relay.540: S 7462205:7462205(0) win 8192 (DF)
What is the (DF) at the end of each line in the trace? That is the spiffy Don't Fragment flag. The packets in this trace are supposed to arrive in one parcel or be thrown away.
Having examined the preceding trace, what operating system is being targeted? Most likely, UNIX is the target, because many of these services do not normally run on other operating systems. Of course, if the only answer back from the scan were port 139, the attacker would guess he had detected a Windows box. Could the 139 port be targeted at UNIX, even though 139 is normally associated with Windows systems? Yes, SAMBA allows UNIX systems to "speak" NetBIOS, and there are SAMBA exploits as well.
Broad-brush scans such as these are one reason I recommend the following:
∙Turn off any service you are not actively using and wrap services you need with TCP Wrappers configured to deny all and only allow those with whom you want to communicate.
∙Firewalls should be configured to block everything not needed to conduct an organization's business.
One last thing before moving on—did you notice the packet that was out of sequence? Notice how as time increases various fields, such as source ports and destination ports, also increase. Now on the fourth line down, one of the destination ports is out of sequence. No big deal; on the Internet, packets can arrive out of order. Now, check its source port. Interesting! This could potentially be a signature that enables us to identify this pattern.
Access Builder?
Look at one more multiscan. This is typical of several that appeared in the December 1998/January 1999 time frame. Note that the scan targets Back Orifice (actually, it targets 31337; to target Back Orifice, this should be UDP) and Netbus. One of the interesting things about this scan is that it hits the same machine on the same port twice. Also, note the attempt to access port 888. This port has an official meaning: It is 3Com's Access Builder and is also used for a database:
13:05:02.437871 scanner.2577 >
192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:02.442739 scanner.2578 >
192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF) 13:05:03.071918 scanner.2578 >
192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF) 13:05:03.079767 scanner.2577 >
192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:03.680841 scanner.2577 >
192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:04.274991 scanner.2578 >
192.168.1.1.telnet: S 922736:922736(0) win 8192 (DF) 13:05:04.278967 scanner.2577 >
192.168.1.1.888: S 922735:922735(0) win 8192 (DF) 13:05:05.391873 scanner.2575 >
192.168.1.1.12345: S 922734:922734(0) win 8192 (DF) 13:05:05.392074 scanner.2576 >
192.168.1.1.31337: S 922734:922734(0) win 8192 (DF) 13:05:06.079211 scanner.2575 >
192.168.1.1.12345: S 922734:922734(0) win 8192 (DF)