What’s the cloud good for?

One of the challenges facings DVLabs today is the ability to have complete network data from attacking and compromised hosts from non-customer networks. To solve this problem, a honeypot infrastructure with instances running in various cloud infrastructures was created. Allowing passive collection of information about suspicious hosts and comparing attacks across geographic regions in a wide-open network setting are the main reasons for choosing cloud services. The data collected can then be to add more entries to our RepDV IP reputation system and assist in the collection of live malware samples. There are many options for running a honeypot, but mwcollectd’s feature set and python module support made it the most attractive option for our purposes. The two features that most interested us were the SMB / MS-RPC emulation that provide enough interaction with the attacker to allow them to fully establish MS-RPC and SMB sessions and then send their attack and shellcode analysis on the stream through libemu.

Where are these connections coming from?

Over the last few months the honeypots have collected a large amount of data from our honeypot systems and one honeypot will be the focus of this post. This system saw a total of 36,000 TCP connection attempts from 6600 unique IPs and averaged approximately 700 connections/day. The country of origin for the source addresses encompassed a large number of countries with Russia and United States having the most connection attempts.

Destination Port Data

Conficker still going strong on port 445

The honeypot saw traffic on 99 distinct ports, but two-thirds of the connections were over port 445. Shellcode detection said there was shellcode in 21% of the streams over port 445. The majority of the streams with shellcode were attempting to spread Conficker by exploiting the MS08-067 SMB vulnerability.

The data collected from the honeypot shows that Conficker is still extremely prevalent and the data collected on filter 6545 (login required) on ThreatLinQ reinforces the data collected from the honeypot. The source countries for filter 6545 graphic above shows that the sources are not as evenly distributed as the data seen from the honeypots. This is likely due to the IPS network being significantly larger and seeing a more complete picture than the honeypot network is currently seeing. Infected Conficker hosts exhibited interesting behavior if the user-agent of the retriever was not set to a valid Internet Explorer 7 or previous user-agent for Windows XP. These hosts would send junk data at slow speeds and time the connections out. Modifying mwcollectd to use this user-agent caused a sharp increase in the number of Conficker A/B/C binaries collected.

Other Ports

Attempts at authentication bypass and open proxy scanning comprised the majority of the hits on HTTP-related ports. The authentication bypass attempts appeared to be targeting insecure installations of PHPMyAdmin. None of the RDP connection attempts appeared to originate from hosts infected with the Morto RDP worm, they were mostly simple attempts to login as Administrator with an empty username and password (filter 11659). These attempts were similar to many of the MS-SQL hits that attempted to login as sa with an empty password. This is covered by filter 1397, but is not on by default because of the potential for false positives due to organizations intentionally using this configuration.

Malware Collection

The honeypots have also collected a large number of malware samples using mwcollect’s binary retrieval modules. These modules look for URLs for standard protocols when shellcode is detected in a stream and then attempt to retrieve them. A total of 17 unique Brambul.A samples were collected, but were mostly the same binary - including one sample that matched across 11 hosts. Conficker was by far the largest malware family collected with 89 unique samples across 210 total hits with one sample being matched 24 times. Using the collected samples and packet captures from the honeypots, the filters produced to provide coverage have been verified to protect against all the variants collected.

Conclusion

The cloud, just like any computer network, can be a dangerous place if you’re not careful. If you want to run sensitive systems in the cloud consider moving to a managed service level that will by default add firewall rules to restrict port access and provide better monitoring of access.

We are currently expanding our network and integrating the data we are collecting from our honeypot network into our RepDV IP Reputation service to increase customer protection from the suspicious hosts seen attempting connections to our honeypots. We will also use this data to supplement the data currently used in our semi-annual Cyber Security Risk Report. As we expand our network to encompass more widespread geographic locations we expect to continue to receive more interesting data that will continue to increase the protection we offer our customers.