Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC: ACK-SYNs from ICS IPs - SANS Internet Storm Center SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
since the beginning of December I'm seeing a lot of blocked ACK-SYNs on my Sophos UTM firewall every day, which come all from IPs from this list:
As far as I can see I have no system which is try to establish a connection to one of this IP addresses.

The source port is always TCP/80 and the destination port is always TCP/28987. Mostly the "attack" begins around 04:00a.m. CET and ends around 05:00p.m CET, but sometimes it's going on the whole day.
Here's an example from my log:

2016:12:19-04:08:53 jasnet ulogd[19766]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="xx:xx:xx:xx:xx:xx" dstmac="yy:yy:yy:yy:yy:yy" srcip="" dstip="SOPHOS_UTM" proto="6" length="44" tos="0x00" prec="0x00" ttl="51" srcport="80" dstport="28987" tcpflags="ACK SYN"

I guess it's nothing bad, but I would like to understand what's going on.

Thank you,

2 Posts
It looks like someone is spoofing your address to make these connections. This is a common technique to either DDoS these targets, or DDoS you with the reply traffic. Some devices will flood a network with SYN-ACKs if you don't reply with a Reset (try to configure your firewall to not just drop the packets, but to send a reset back. this may reduce the attack volume) Johannes

4478 Posts
ISC Handler
Thank you for your fast reply.

I will try to force an IP change. Hope it will help.

2 Posts
Did you consider setting syn-cookies if available on this device ? JL

1 Posts
As I work in Co-Sharing Work place. T do blogging and writing. But when i try to reach more sites of blog or articles, some show we don't allow 2 account on same IP and some times they show your IP is blocklisted. I mailed them but they didn't respond. Any solution for this. Maybe other colleagues in this working place done something terrible on these sites. but is there anyway by that i can Get one new unique ip by that i can access those sites. thenortonsetup

1 Posts
I wrote a long and detailed reply yesterday and again today, but neither make it through. Attempt #3...

It is similar to Mirai. We have been seeing that pattern of SynAcks also since 18th/September - first seen from CloudFlare (CF):

Timestamp (UTC) Action I/F SrcIP [:Port] -> DstIP[:Port] Proto [Flags]
2016-09-18 07:56:59 block in on wan from -> MyIP:32840 tcp flags:SA
2016-09-18 08:03:42 block in on wan from -> MyIP:32840 tcp flags:SA
2016-09-18 08:14:57 block in on wan from -> MyIP:32840 tcp flags:SA
Found: 3 Displayed: 3
First seen: 2016-09-18 07:56:59 Active: 0:17:58
Last seen : 2016-09-18 08:14:57 ( 121 days, 14:22:46 ago )

1) We made *no* outbound connections to that CF IP at that time.
2) The destination port on our side (32840) was extremely common for exactly this pattern of SynAck behaviour (Found 3,848 messages)
3) Obviously they are reflected SA's from someone else spoofing our IP - given point (1) above and the very unlikely proposition that CF would be performing this type of behaviour intentionally.

Volume started very low:
35 from 18-31st September (23 of which arrived on 2 separate days on 21st and 23rd),
29 in October (25 on the last day of the month) and then it ramped up significantly to...
1194 in November and
2590 in December.

Then it stopped using port 32840 and switched to random ports (maybe they saw your post;) - but the ack# remains static.

Up until 1 Nov this is the breakdown:

Value % Count 39.06% 25 <- GoDady hosted site 7.81% 5 4.69% 3 4.69% 3 <- First seen from here. 4.69% 3 4.69% 3 4.69% 3 3.13% 2 3.13% 2 3.13% 2 1.56% 1 1.56% 1 1.56% 1 1.56% 1 1.56% 1 1.56% 1 1.56% 1 1.56% 1 1.56% 1 1.56% 1 1.56% 1 1.56% 1 1.56% 1

We labelled it MiraiV2, because if you examine the acknowledgement number you may notice a very interesting pattern.

The Ack# can be calculated directly from _our_ IP address with this formula:
SynAck Ack# = ( (o1 - 1) << 24) + (o2 << 16) + (o3 << 8) + o4

Note: o1.o2.o3.o4 is our IP address, not the source IP.

We would expect a MiraiV1 SynAck response from a spoofed packet to have Ack# = Mirai + 1, not (o1 -1)...

[Mirai version 1 is simply seq # (o1 << 24) + (o2 << 16) + (o3 << 8) + o4, as detailed at line 225 in mirai/bot/scanner.c in github's copy]

Hence we believe this traffic serves 2 purposes:
1) (D)DoS the web server at target1 (CF in this case) using our spoofed IP address with the intention of also...
2) ...(D)DoS'ing the real IP owner (us) with SA traffic. Why else would the Ack be pre-calculated from your IP address?

Perhaps a 3rd purpose is to distract both parties (CF and us) so as to hide their real intent/location for a longer period.

If you calculate the ack from your IP, you can create a suricata/snort rule for it thus:

alert tcp any any -> any any (ack=( (o1 - 1) << 24) + (o2 << 16) + (o3 << 8) + o4; msg:"MiraiV2 scan";....)

Contrast that with the MiraiV1 rule:
alert tcp any any -> any any (seq=( o1 << 24) + (o2 << 16) + (o3 << 8) + o4; msg:"MiraiV1 scan";....)

FYI we have noted the following other variants, each using slightly modified sequence or acknowledgement numbers calculated directly from our IP:

Version Calculated Seq/Ack #
v1 (o1 << 24) + (o2 << 16) + (o3 << 8) + o4
v2 ( (o1 - 1) << 24) + (o2 << 16) + (o3 << 8) + o4
v3 ( (o1 - 1) << 24) + (o2 << 16) + ((o3 - 64) << 8) + o4
v4 ( (o1 - 12) << 24) + (o2 << 16) + (o3 << 8) + o4
v5 (o4 << 24) + (o2 << 16) + (o3 << 8) + o4

(I doubt my alignment will carry through - apologies for non-alignment but outside my control)

Most recently we have witnessed a more adventurous manipulation:
v6 ( bitflip( (v1 >> 16 ) + 1 ) << 16

We have seen many more where the lowest 16 bits were all 0, a very unlikely scenario for most TCP stacks, and clearly a calculated value.

We live in interesting times.


3 Posts

Sign Up for Free or Log In to start participating in the conversation!