1:40991 MALWARE-CNC Linux.DDoS.D93 outbound connection

I previously wrote about documentation-less snort rules. Below is my attempt to fill in some of those gaps.

Whomever created this DDoS snort alert didn't include documentation.

(1:40991) MALWARE-CNC Linux.DDoS.D93 outbound connection
alert tcp $HOME_NET any -> $EXTERNAL_NET 31337 (msg:"MALWARE-CNC Linux.DDoS.D93 outbound connection"; flow:to_server; content:"|4E 0F 42 07 27|"; depth:5; dsize:25; metadata:impact_flag red, policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:url,www.virustotal.com/en/file/2c017c94d9f40cba9a20e92c7c636e98de15c599bf004fa06508d701ab9e3068/analysis/; classtype:trojan-activity; sid:40991; rev:1; ) v:1; )

If I had to guess I think it's related to this article on Linux DDoS 93 or something similar which stated.

Crooks are hijacking devices running Linux-based operating systems and use them to launch DDoS attacks at their behest. Dr.Web security researchers say the trojan seems to infect Linux machines via the Shellshock vulnerability, still unpatched in a large number of devices.

The virus total link in the alert above has hits for Linux.DDoS.93 , Linux.DDOS.Flood.W , etc.

More about neonprimetime

• neonprimetime pastebin
• neonprimetime virustotal
• @neonprimetime twitter
• neonprimetime reddit

Top Blogs of all-time

1. pagerank botnet sql injection walk-thru
2. DOM XSS 101 Walk-Through
3. An Invoice email and a Hot mess of Java

Top Github Contributions

1. Qualys Scantronitor 2.0

Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Sample 2013 NTP Reflection Vulnerability

I see this request a lot. It's an old one and pretty simple to explain.

User Datagram Protocol, Src Port: 42024 (42024), Dst Port: 123 (123)
Network Time Protocol (NTP Version 2, private)
   Flags: 0x17, Response bit: Request, Version number: NTP Version 2, Mode: reserved for private use
   Auth, sequence: 23
   Implementation: XNTPD (3)
   Request code: MON_GETLIST_1 (42)
   0000 .... = Err: No error (0x00)
   .... 0000 0000 0000 = Number of data items: 0
   0000 .... = Reserved: 0x00
   .... 0000 0000 0000 = Size of data item: 0x0000


I believe it's a scan looking for an NTP reflection vulnerability that could be used then for a DDoS attack. At a high level here's how I understand it. The attacker sends a request to port 123 for a "mon_getlist" request and if the server is running NTP and is vulnerable the server returns a list of the last X number of IPs that have connected to it. Why is that an issue? Well, first off, the request is small (size wise, there is nothing to this packet, very tinY) but the response is HUGE, it could respond with hundred's of ip addresses and the packets can get very large. The other issue is that in this protocol source ips can be spoofed and thus the attacker can send a packet from 1 ip address, but spoof the source as another ip address (their victim) and what will happen is the attacker sends a bunch of tiny small NTP requests, but since the source is spoofed, the vulnerable NTP server sends a bunch of HUGE responses back to the spoofed ip address , who ends up being the victim. The victim will get all these huge packets sent to them and their servers will be overwhelmed and crash or cause a Denial of Service. The fix appears that you should disable this "mon_getlist" feature as it's not needed. Here's a few better links that explain this attack in more detail. [1] [2] [3]

More about neonprimetime

• neonprimetime pastebin
• neonprimetime virustotal
• @neonprimetime twitter
• neonprimetime reddit

Top Blogs of all-time

1. pagerank botnet sql injection walk-thru
2. DOM XSS 101 Walk-Through
3. An Invoice email and a Hot mess of Java

Top Github Contributions

1. Qualys Scantronitor 2.0

Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.