Storm Worm – Go away, we’re not home
Posted by jeremy on October 5th, 2008
In the last few weeks I have received several requests for information regarding the Storm Worm. So today I thought I would perform an analysis in my lab on the last Storm Binary (postcard.exe) I retrieved using my Storm Binary Tracking scripts dated “2008-09-18 18:42:28″ just to see if I could possibly find the answers to some of the questions many of you have asked. To be perfectly honest and clear I have not seen any spam, DDOS attacks, or Fast Flux domain activity related to the Storm Worm since mid September, so I too am curious as to what has happened to this menace.
During execution of the postcard.exe binary a binary named neos.exe was installed into the “%WINDIR%” accompanied by it’s normal p2p peer configuration file named crock+mock.config. Immediately following the installation of this new binary the neos.exe process was started, and I was greeted by the normal Storm Worm network traffic to include the p2p udp traffic. This p2p udp traffic demonstrates how resilient the Storm Worm Trojan really is in that I haven’t seen a new binary in almost a month and yet I was communicating with a few hundred Storm Worm infected hosts. Being curious to how many peers were listed in the crock+mock.config file I ran my perl decode script used to extract peers from the configuration file which extracted a total of 848 IPs. The entire peer list can be seen here: peers.txt. I also submitted the IPs to the whois.cymru.com server to get ASN and country data which can be seen here: peers_asn.txt. As you can see from the peer files almost half of the hosts reside in the US, 348 to be exact, and that most of the hosts reside on large residential ISP network segments. So far these stats line right up with everything we have seen associated with the Storm Worm characteristics in the past, which to me is odd since there hasn’t been a new Storm Worm campaign in over a month.
Since it was more of the same for the Storm Worm network configuration statistics I thought I would also check my Storm p2p decryption script to see if the Overnet protocol was still being encrypted with the same xor key. Sure enough my script decoded the udp p2p traffic and nothing was new here either as I still saw the same old Overnet/eDonkey commands being issued such as Publicize, Publicize ACK, Connect, Connect Reply, IP Query, IP Query Answer, Identify, Identify Reply, Search Info, and Search End. Since the crock+mock.config script provided me with 848 IPs of peers I decided to see just how many Overnet peers I was actually communicating with during my lab run. Here is a list of all 1,441 peers that sent me some type of Overnet traffic: overnet_peers.txt and here is the results of my bulk submission to the cymru.com whois server: overnet_peers_asn.txt. As you can see the US lead the way once again with 353 infected hosts, and RU trailing right behind with 114 infected hosts.
The next thing I noticed in the network traffic was DNS queries for the domain name policy-studies.cn, which is where an old root kit was stored in a past campaign. This domain name has long been shut down, so I decided to run a faux DNS server script to give my infected lab machine an A record to see what would happen. After reconfiguring my infected host to perform DNS lookups using my faux DNS server the neos.exe process started requesting a file named getbackup.php. The getbackup.php file was the same rootkit file request seen over a month ago, so I assume this DNS request and file retrieval is hard coded in the neos.exe binary and is not something that was passed to it in a parameter via the Storm p2p network or the TCP control network.
Taking a look at the TCP traffic is where things really got interesting. Several of the TCP servers were answering my requests with the following reply: “Go away, we’re not home”. This to me was just plain hilarious and demonstrated to me even in an inactive period for the Storm Worm the authors have one hell of a sense of humor. Here is a list of all the Storm TCP servers that responded with this intriguing message: goaway_ip.txt and it’s corresponding bulk result from the cymru.com whois data: goaway_ip_asn.txt. Interesting enough all 18 of these servers were located in two countries the US and Mexico. I am not sure how relevant or important this is or if it was just a coincidence. Not all of the TCP servers communicating with my lab box provided this message. The servers that did not reply with this message simply sent reset packets and stopped the TCP handshake, so these could be patched boxes or cleaned boxes leading me to believe my TCP requests were based off old data residing in the Storm Network and/or Binary. In an attempt to perform fair analysis here is the list of 50 servers that did not respond with the “Go away” message: tcp_storm_noaway.txt and it’s corresponding cymru.com whois data: tcp_storm_noaway_asn.txt. These servers are definitely more geographically dispersed over a wide range of countries and ASNs.
So what does all this mean for the Storm Worm? Well, I am not really sure and can only make guesses as to why we haven’t seen another Storm campaign recently. My first guess would be that with all the recent data being published on the Storm Worm encryption mechanisms and it’s Double Fast Flux architecture, especially the Black Hat presentation by Joe Stewart in Vegas which may I say was very insightful, that the Storm Authors are making some major changes and have put everything else on hold until these changes can be rolled out into production. My second guess would be the heat from law enforcement sent them into hiding or laying low for a while. This second guess could also be combined with the first guess and the authors could be reworking their architecture to get the heat off of them. My final guess would be the Authors of the Storm Worm made enough money off the surge of campaigns we saw at the beginning of the summer that they really are not home and are off taking a vacation. Most likely enjoying the spending of all that cold hard cash they earned off the Canadian Pharmaceutical spam, Penny Stock manipulation, and phishing scams we grew so accustomed to seeing. My final conclusion is that the Storm Worm is currently dead/inactive, but I would not be surprised at all if we saw a new and improved Storm Worm in the coming months. I think the question isn’t is Storm dead, but more like when will we see it return and what new features or tactics will it have in store for us.
As always if you have any questions or comments feel free to contact me or leave a comment, as they are always welcome and appreciated.
October 8th, 2008 at 11:04 am
[...] Storm Worm – Go away, we’re not home [...]
October 8th, 2008 at 2:25 pm
storm worm come home to daddy
October 10th, 2008 at 12:38 am
I have developed methods to increase Internet security which will greatly enhance security, safety, protect consumers, block hackers, and prevent virus attacks.
The ideas to enhance Internet security are derived from these two fundamental yet elegant concepts:
1. IP address: The identification of an Internet entity. Every website has an IP address. IP addresses are assigned by Internet Service Providers (ISPs). ISPs obtain allocations of IP addresses from a Local Internet Registry (LIR), or National Internet Registry (NIR), or from their appropriate Regional Internet Registry (RIR) where IP address pool is assigned by the Internet Assigned Numbers Authority (IANA). ISPs use this information together with network topology to build Internet backbone routing tables to ensure all IP addresses are routed correctly and reachable by everyone. Website’s IP address or any IP address on the Internet must be legitimate, routable and reachable. On the Internet, both source and destination IP addresses are needed to establish a session for two-way communication. The source and destination IP address between any two nodes (parties) must be valid and cannot be altered. If the source IP address is altered, then the data will be routed to the altered IP address instead and one-way communication is created. With the altered IP address, data can be sent out, but no data will be received in return. In most cases, this will be considered a denial of service attack. Therefore, website and e-mail services will not work. In addition, most companies do not change their IP address often due to the complexity of updating and testing the Internet backbone routing tables.
In general, an IP addresses have the following properties:
• An IP address is allocated by IANA, RIR, ISP, etc.
• An IP address must be legitimate, routable, and reachable.
• A Websites cannot fake its IP addresses.
• Most Internet traffic consists of two-way communication.
• Most companies do not change their IP address (block).
2. Local White List: A database of trustworthy IP addresses for positive identification, unlike other white lists that check URLs or domain names which change frequently and can be defeated by the perpetrator. This White List is based on IP addresses and only the IP addresses from well-known trustworthy organizations, legitimate financial institutions, etc. will be added. Because websites cannot fake their IP addresses, this White List is more accurate, effective, and resistant to other attacks. Also, because most companies do not change their IP addresses, this White List will remain fairly stable, and easy to maintain.
The White List will have the following features:
• It is based on IP addresses.
• The White List will not change often and will be easy to maintain.
• The user should be able to modify the local White List.
Application of the concepts:
1. Identify Trustworthy Sites and Detect Phishing Websites: Unlike all other phishing detection software, we can positively identify trustworthy websites by comparing website’s IP address against the White List. With these new security concepts, trustworthy websites will be able to safely provide personal information. New or known phishing websites will not be included on the White List and can be instantly detected locally without any delay.
2. Discover Spoofed E-mail: Based on SMTP RFC 2821, the “Received” field in the e-mail header includes the IP address of the sender. This IP address is logged by the receiving mail server. Therefore, the sender cannot alter this IP address. Once the sender IP has been identified, the domain name can be determined from the White List. Comparing the domain name from the White List to the domain name in the “From” field, the non-spoofed e-mail can be identified. By checking the “Received” field, one can determine if an e-mail from financial institution is legitimate.
3. Protect and reveal unauthorized access to an account: When accessing an account, the server can verify if user’s IP address is authorized. In addition, server can log an entry with a timestamp and this client IP address. Then the server sends this information to this client local log file. If there is no unauthorized access, these two log files should be identical. The client log file can be on a USB device when multiple PCs are used to access the account.
4. Secure local systems from malicious attacks (i.e., viruses, worms, etc.): Before establishing a network connection, there must be verification of the following:
• Remote IP address
• Port number
• Payload type
For example, if Microsoft is fully trusted, all traffic on all ports with all payload types will be allowed. For most websites, only ports 80 and 443 are allowed with no executable program. For untrustworthy IP addresses, not on the White List, the user will be warned or denied access for both inbound and outbound traffic.
5. Prevent DoS Attacks: Most DoS attacks have spoofed their source IP address and send mass amounts of requests to one website. The router or switch that the attacker’s machine attaches to can validate the source IP addresses before forwarding to the network (RFC 3704). Since the router/switch nearest the attacker can determine if the source IP address is routable back to the originator, the invalid source IP address message will be discarded. An Edge Router that connects to an AS (autonomous system) can validate the source IP address as well. The router/switch/firewall at server location can also limit the number of requests based on each individual source IP address to help prevent DoS attacks. In addition, a White List with legitimate client’s IP addresses can be used to bypass this restriction so rightful users will not be blocked during DoS attacks.
I have a beta program that demonstrates how to identify trustworthy sites and detect phishing websites. This program is a Firefox web browser extension that checks the current website’s IP address against the local White List. When visiting a website, the user may want to check the legitimacy of this site before entering any personal information. By clicking this extension (button), the user will receive advice on how to proceed. The user can then decide the best course of action.
October 10th, 2008 at 9:07 am
Daniel:
White listing is not really a new concept, but I have to disagree with you and say that it is actually very hard to maintain. The internet was created as an open public form of communication and designed this way. Security really didn’t come into the design model until later on. Creating white lists would mean for any company that hosts a public web server they would need to index the entire internet IP space, which would defeat the purpose of white listing. Take ebay for example, how would they incorporate white listing into their business model? Now lets look at users and how white listing will affect them. You will need to index every single legitimate IP on the internet that a user may want to go to. So monitoring for new websites hosted on new IPs would be insanely tough if not impossible. Let’s take another approach to white listing, lets say you have strict policies on you users internet use, so indexing every single IP that hosts a legitimate web site isn’t an issue but these users require VPN access back into the company. This sounds simple right? I don’t think it is as most ISPs use DHCP to serve out IP addresses to their subscribers and if you white list their IP on Monday it doesn’t mean they will have that same IP address on Friday, again making it insanely tough to maintain.
For the email spoofing I prefer the concept of Sender Policy Framework over white lists, as again I believe white listing to be a cool concept just not a maintainable one. Mail is routed by looking up MX records. These MX records allow me to change my IP address at anytime and not affect mail operations, so if I created white lists of authorized mail server IPs that can send me mail I would have to constantly monitor these domain IP spaces for new MX records to ensure I don’t break mail flows at any given time. One thing I have learned in my IT career is you don’t break email for any reason unless you want to get fired or beat down by an angry mob of users.
As far as being able to prevent DDoS attacks, I don’t see this working all the time. Let’s say I do implement your white listing idea and place this insanely large white list of IPs in an ACL on my Edge router advertising my AS. You don’t think this router will stop routing when it starts having to check a DDoS traffic flow against this insanely large white list, I do. Most large organizations will tell you the same, that the ACL on the AS edge routers need to be small and to the point to ensure this router continues to route traffic during high traffic times. You don’t want to lose legitimate traffic, as legitimate traffic in most cases is what keeps you in business and pays the bills.
Don’t get me wrong here, I think white listing is a cool concept and that has it’s places, but the public internet is not one of them. Remember we kind of use to do white listing before DNS was used, as we swapped host files so we could connect to the internet, but these files soon grew to an astonishingly large size and were just not affective. DNS was born and we never looked back.
October 20th, 2008 at 1:14 am
Something very similar…
http://blog.fireeye.com/research/2008/10/storm-just-befo.html
January 19th, 2009 at 4:02 pm
[...] the Storm Worm now in decline (perhaps pushed-aside for its creators’ new project, Waledec, responsible for a host of fake [...]
September 11th, 2009 at 12:17 pm
[...] the Storm Worm now in decline (perhaps pushed-aside for its creators’ new project, Waledec, responsible for a host of fake [...]
October 30th, 2009 at 10:07 pm
I found an additional source of the “Go Away, We’re not home messages”…
When I use the firewall on my AT&T 2Wire Router to block a ports, it respnds to queries on the blocked ports with a forged TCP/IP response from the intended recipient with a payload of “Go Away, We’re not home.”