Re: Unknown attack, possible trojan?

[Jason Falciola <falciola () us ibm com>]

Some initial thoughts based on a quick look at the data.  Someone please 
correct me if I'm off base.

 - Someone could be performing a SYN Flood against the webserver at 209.11.84.ZZZ and spoofing the address of 
213.51.XXX.YYY.
 - Someone could be performing a reflexive attack against 213.51.XXX.YYY by sending SYN packets to 209.11.84.ZZZ and 
then you would get the SYN-ACKs back.
 - However, the fact that the source MAC addresses vary and the traffic 
never left the VLAN make me think that the target of the attack is 213.51.XXX.YYY, and this is originating within your 
IP space.  The source 
IP would be spoofed and the webserver at 209.11.84.ZZZ would never have 
actually been involved.  I'm betting the source MAC addresses and varying TTLs are also spoofed in an attempt to avoid 
detection.
- Multicast destination MAC addresses were likely used to amplify the 
attack.
- These packets are clearly crafted.  The question is what's generating 
them.  I'm not sure at this point.  A colleague mentioned bang.c, but I 
haven't tested that in the lab yet and am not overly familiar with its 
capabilities.

Anyone else have ideas?

Jason Falciola
Information Security Analyst
IBM Managed Security Services
falciola () us ibm com





"Arjan Hulsebos" <ahulsebos () wolfpack nl>
03/11/2003 04:33 AM

 
        To:     <incidents () securityfocus com>
        cc: 
        Subject:        Unknown attack, possible trojan?



Hello list,

We're operating a broadband cable internet network. We received a 
complaint
from a subscriber concerning odd traffic he'd captured. As it turned out,
he'd captured a DoS attack on another subscriber. Analysis of the dump
showed the following:

- Large amounts of packets were sent from a single ip address (not 
belonging
to our AS) to the victim's ip address.
- Multiple source ethernet MAC addresses were used (17 in the dump the
subscriber sent us).
- Multiple destination MAC addresses were used, but most (7 out of 9) were
multicast ethernet addresses.
- Source and destination ports remained the same, while the SYN and ACK 
bits
were set.
- Both sequence numbers were equal to one another, and remained the same
throughout the dump.
- The TTL varied between 32 and 59. This is odd, as it's all in a switched
environment. The router's ethernet address was never seen as a source MAC
address, hence the traffic never left the VLAN.
- The identity field in the IP header was the same (10803) for all 
packets.

As this spew of packets also hit the router (and died there in an ACL), I
checked other routers in our network, and did see the same sort of packets
hit the ACLs in various other locations. Comparing them, it turned out 
that
port 80 was always involved, either as a destination port or as a source
port. I've included some lines from the tcpdump.

Does anyone recognize this? I couldn't find any clue in Google...

Thanks,

Arjan H

Not even a clue-by-four would work with this clown.
________________________________
dr. Arjan Hulsebos
Security Engineer
Essent Kabelcom West, a.k.a. @Home Benelux
1042 AX Amsterdam
Email: arjanh () corp home nl
Tel:   +31 20 88 55 407
Mob:   +31 6 21 548 777

==== < tcpdump > =====

20:21:35.872464 0:50:fc:fe:74:a4 1:0:5e:33:e8:58 0800 60: 209.11.84.ZZZ.80 
>
213.51.XXX.YYY.63089: S [tcp sum ok]
  1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 
56,
id 10803, len 44)
20:21:35.872851 0:50:7f:4:15:70 0:6:52:50:94:8 0800 60: 209.11.84.ZZZ.80 >
213.51.XXX.YYY.63089: S [tcp sum ok]
  1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 
55,
id 10803, len 44)
20:21:35.880167 0:10:a7:3:81:bd 1:0:5e:33:94:1 0800 60: 209.11.84.ZZZ.80 >
213.51.XXX.YYY.63089: S [tcp sum ok]
  1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 
53,
id 10803, len 44)
20:21:35.880551 0:50:7f:4:15:70 0:6:52:50:94:8 0800 60: 209.11.84.ZZZ.80 >
213.51.XXX.YYY.63089: S [tcp sum ok]
  1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 
52,
id 10803, len 44)
20:21:35.887731 0:10:a7:3:81:bd 1:0:5e:33:94:1 0800 60: 209.11.84.ZZZ.80 >
213.51.XXX.YYY.63089: S [tcp sum ok]
  1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 
54,
id 10803, len 44)
20:21:35.888114 0:50:7f:4:15:70 0:6:52:50:94:8 0800 60: 209.11.84.ZZZ.80 >
213.51.XXX.YYY.63089: S [tcp sum ok]
  1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 
53,
id 10803, len 44)
20:21:35.895208 0:4:61:43:fb:cf 1:0:5e:33:ea:1 0800 60: 209.11.84.ZZZ.80 >
213.51.XXX.YYY.63089: S [tcp sum ok]
  1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 
55,
id 10803, len 44)
20:21:35.895598 0:50:7f:4:15:70 0:6:52:50:94:8 0800 60: 209.11.84.ZZZ.80 >
213.51.XXX.YYY.63089: S [tcp sum ok]
  1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 
54,
id 10803, len 44)
20:21:35.902707 0:0:c5:5d:d:41 1:0:5e:33:e8:58 0800 60: 209.11.84.ZZZ.80 >
213.51.XXX.YYY.63089: S [tcp sum ok]
  1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 
53,
id 10803, len 44)
20:21:35.903093 0:50:7f:4:15:70 0:6:52:50:94:8 0800 60: 209.11.84.ZZZ.80 >
213.51.XXX.YYY.63089: S [tcp sum ok]
  1224440169:1224440169(0) ack 2340024064 win 6144 <mss 1460> (DF) (ttl 
52,
id 10803, len 44)






----------------------------------------------------------------------------

<Pre>Lose another weekend managing your IDS?
Take back your personal time.
15-day free trial of StillSecure Border Guard.</Pre>
<A href="http://www.securityfocus.com/stillsecure";> http://www.securityfocus.com/stillsecure </A>