Backscatter Detected

Recently I posted a conclusion to my backscatter investigation, where people were reporting backscatter from SYN and other DoS attacks to SANS ISC. When you monitor your own cable modem it's not common to see this sort of traffic unless you go explicitly looking for it. Today however I saw the following using Sguil.

Count:2 Event#1.204541 2007-03-20 18:04:19
BLEEDING-EDGE DROP Known Bot C&C Server Traffic (group 1)
69.143.202.28 -> 193.109.122.67
IPVer=4 hlen=5 tos=0 dlen=40 ID=2644 flags=2 offset=0 ttl=64 chksum=58655
Protocol: 6 sport=1024 -> dport=6667

Seq=2934031229 Ack=0 Off=5 Res=0 Flags=*****R** Win=0 urp=54297 chksum=0
Payload:
None.

What got my attention at first was an alert indicating my host (possibly some box behind my NAT gateway) appeared to initiate a connection to port 6667 TCP (IRC) on an IP that was a "Known Bot" IP for command and control. Looking at the packet data in the alert and seeing the RST flag, I guessed this wasn't a problem. Still, I wanted to know why one of my boxes would send a RST. Could that be some sort of phone-home method designed to elude uber-packet monkeys? (Conspiracy theory hat on!)

I decided to query for session data to see if I could find any other sessions involving 193.109.122.67 (ede.nl.eu.undernet.org):

------------------------------------------------------------------------
Sensor:cel433 Session ID:5044069116374886360
Start Time:2007-03-20 18:04:19 End Time:2007-03-20 18:04:19
193.109.122.67:6667 -> 69.143.202.28:1024
Source Packets:1 Bytes:0
Dest Packets:1 Bytes:0
------------------------------------------------------------------------
Sensor:cel433 Session ID:5044103368738397945
Start Time:2007-03-20 20:17:14 End Time:2007-03-20 20:17:14
193.109.122.67:6667 -> 69.143.202.28:3072
Source Packets:1 Bytes:0
Dest Packets:1 Bytes:0

All I found were the two sessions indicated by the aggregated Snort alerts. Notice the session data shows the source and destination each sent one packet. Interesting. One of the nice aspects of SANCP is that it can report a summary of the TCP flags seen during a session. That information is shown below.

This shows the source sent a SYN ACK and the dest sent a RST. The RST caused the alert. The SYN ACK triggered the RST.

Finally we can look at the full content:

14:04:19.731091 IP 193.109.122.67.6667 > 69.143.202.28.1024:
 S 4257997451:4257997451(0) ack 2934031229 win 2048 
14:04:19.731429 IP 69.143.202.28.1024 > 193.109.122.67.6667:
 R 2934031229:2934031229(0) win 0

This doesn't tell us anything we didn't already know, but it's nice to see exactly what happened on the wire. Remember that if we weren't collecting independent, content-neutral, non-alert-triggered full content data, we wouldn't have the first SYN ACK packet. That is the key to knowing this is a backscatter event. Some unknown party spoofed my IP, 69.143.202.28, and SYN flooded 192.109.122.67 on port 6667 TCP. The SYN ACK was sent back to me, and my NAT gateway replied with a RST. Simple -- and no conspiracy. Hat off.

Comments

Anonymous said…
Hi Richard,

Our network received this alert as well yesterday with identical characteristics. After inspecting the rule, I became worried at the thought of one of our hosts generating the traffic, however it was the gateway sending the RST that triggered the alert.

inuk-x
9:34 AM
Anonymous said…
This comment has been removed by a blog administrator.
7:17 AM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti...
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technica...
Read more