> Total Length: 52 > Identification: 0xb82b > Time to live: 118 > Sequence number: 1409168989 > Header length: 32 bytes > .... ..1. = Syn: Set > Window size: 55808 > Options: (12 bytes) > Maximum segment size: 1460 bytes > NOP > Window scale: 2 (multiply by 4) > NOP > NOP > SACK permitted > From May 21 I received about 120 packets like this one: > Every packet is identical to each other, except for TTL field, which vary > from 102 and 108, and IP-ID, always set to 58793 except a couple of times. > This kind of SYN packet doesn't belong to any known TCP/IP stack. There are > a lot of field in common with the packet you have captured, first of all the > tcp windows size, but also the tcp options worth a look. Both are peculiar. > I think that are crafted by the same tool. Please forgive my rambling below - I'm all hyped up because I've been looking at something similar and it looks like something big is happening under our noses. I'm getting the same types of packets to a router - since May 17. Also at a gradually increasing pace - they started about 1 per day and now they are 40 seconds to 40 minutes apart. I attributed them to some lame trojan probe and did not realize they were related to this thread until I reviewed new detailed captures when the pace started getting bothersome. The behavior of mine is identical to yours - TTLs vary 106-112, even on probes that come a few seconds apart. The overwhelming majority of the probes come from one address (not the same address as yours and not a known portscanner or proxy). The very reliable and trustworthy admin of the source address says the packets did not come from his system, but is continuing to do full packet capture anyway to make sure. ID on mine from the primary source is always 0xfb6f. Sequence is always 2773619225. Mine have identical options to yours including WS: 2. The SYNs do not have data (other than that probably encoded within the TCP/IP headers). Nothing has followed the SYNs. These packets are obviously crafted, and the main source addresses (at least in my case) are probably spoofed. I can't check the true hops to my apparent main source because it is not a public system and traffic to it is dropped while still several hops away from it. Mine are primarily sport 14921 and all dport 8247. I get occasional probes from variable source ports from addresses different from the primary prober. I did a factory reset on the router, reloaded firmware, set a new password - the probes stopped for over 6 hours before starting up again. I don't know what the * that means. There are a few other fishy source and dest combinations coming now but they are still far apart and I don't have full captures to know if they are related. My working hypothesis is that the primary probe source is completely spoofed and is some sort of homing signal for a complex trojan. The oddball probes are probably not spoofed and are possibly the agents of the actual abusers. The "agents" have all been dialup or cable modem systems (probably owned), except the primary prober that is spoofing the address of a very large semi-government agency. Now, since multiple sources are involved and the pace is building over several weeks, I'd say we have some sort of botnet. Since the primary probing address is spoofed and is appearing to probe at random intervals with varying TTLs, I'd say multiple systems may be spoofing the primary address. This may be the botnet membership announcement, and since the TTLs vary only a little bit the sources may be from the same /16 or so address range as the target - again typical of botnet probes. More hypothesis: Each target is assigned a unique combination of source port, dest port, ID, and Sequence. So this post probably contains all the info necessary to identify my system. This is looking a lot like the Q-like traffic that was common late last year. A Q-based trojan would not need the TCP handshake to complete because instructions are coded into the SYN (or any other type of packet). The destination port does not even need to be open. The interesting thing to me is that nobody has reported to the lists I read about finding a wild Q-based trojan in files on their system AFAIK, but many people have logged traffic that looks like it is similar to Q probes. Others have suggested that there may be a memory-resident Q-like trojan in the wild that is listening for these packets, but I have not heard of any packet captures of such a beast. My paranoid side says that nobody has seen the trojan because it's built into Windows or WMP or adware or something else with closed source code that is on lots of systems. Maybe it's designed to help digital rights management monitoring or something, and is now being abused by unintended parties. I also can't help but wonder if this traffic might be related to the stateless Code Red middle packets being logged widely and some Code Red infections that people are reporting inside hardened systems. A Q-like trojan could possibly have been triggered by the packets to start sending Code Red packets even though IIS had been hardened. Maybe someone who has had this happen could review their logs and compare sequence and IDs on packets from the source they believe compromised them with a stateless 2nd packet only of Code Red. If those sequence and IDs correlate with other anomolous packets, that might establish a link. CodeRed.F has always seemed to me to have overly robust propagation. AV and IIS hardening are much more prevalent than when the nearly identical CodeRed.C was released, but I've logged far more CodeRed.F attacks than I ever got from C. Maybe it has sometimes been dropped onto systems through means other than IIS overflows, and is being used to hide more serious compromises that occurred before the CR infection. OK, enough wild-eyed rambling for now. ---------------------------------------------------------------------------- ----------------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Mon Jun 09 2003 - 09:15:09 PDT