Security and Privacy

• SIRv11: Putting Vulnerability Exploitation into Context

  As Vinny Gullotto, our GM blogged earlier in the week, the 11^th edition of the Security Intelligence Report (SIRv11) has been released. One of the new areas of research in this release is a study of the most prevalent kinds of vulnerability exploitation and how much of that exploitation is 0-day (short for zero-day, an attack or exploitation of a vulnerability without an available update). We took two paths to find this answer. The first was an analysis of how the top families found by the Microsoft Malicious Software Removal Tool (MSRT) were known to infect systems. We found that none of the top 27 families were known to use 0-day vulnerabilities in 1H11.

  The second way we approached this answer was to measure all of the exploit activity tracked by the MMPC through our real-time protection products (such as Microsoft Security Essentials and Forefront Endpoint Protection) and compare the number of attacks that were 0-day at the time (no update available) versus attacks that occurred after the update was made available. We actually gave a month buffer zone (so any exploits that happened during the month in which the update was made available was still counted as 0-day). We expected the percentage to be low, and it was– 0.12 percent to be exact for 1H11. Here’s what it looks like in chart form:

  
  Chart 1 – Chart illustrating percentage of exploits that were 0-day in 1H11

  One question that we discussed a lot while working on this report was: How do we measure what we don’t know and therefore can’t see? (In other words, 0-day by definition means you may not know about it.) Great question! Answer: We can’t measure what we can’t see. However, what we have seen tells us that “secret 0-days” don’t stay a secret for very long. Take, for example, a few we tracked in 2010. These attacks nearly always started out as targeted – sometimes reported as affecting only one entity when they were discovered. The trend they have in common is that they broaden to more generalized use (eventually) and we find out about them sooner or later.

  • CVE-2010-0806 was a 0-day affecting Internet Explorer 6 and 7 on older operating systems (like Vista and XP) that was reported as being used in targeted attacks. A few days later, after the release of public exploit code, we saw those attacks escalate and they have remained a sizable part of exploit activity throughout 2011.
  • CVE-2010-3962, which we dubbed the Weekend Warrior for its peaks of activity in Korea on the weekends, was discovered in Nov. 2010 when it was used in targeted attacks. Attackers broadened the targets of their attacks near the end of the month.
  • Another example is CVE-2010-3962, the vulnerability that used malicious .lnk files that was found with Stuxnet. It took a matter of weeks before this one technique used in this very targeted, singular attack got picked up by many other families of malware like Sality, broadening the impact considerably.

  The point here is that although it’s true that “you don’t know what you don’t know,” our experience tells us that when it comes to 0-day activity, we find out, and often, we find out quite quickly. Things start to unravel rapidly the moment the 0-day affects either a target that’s really paying attention or when the attacks start to affect a broader, less targeted audience.

  So, even if our estimates for 0-day activity were off by 5 fold, the estimated activity for 1H11 would remain under 1 percent. That’s still pretty small.

  Most Frequent Exploits

  So, now that the question of 0-day is out of the way, let’s talk about the broader volumes of exploit activity that were revealed in SIRv11. Although there are many interesting trends in the chart below, I want to focus on a few of them in this blog: Java (and the age of vulnerabilities in general) and Operating System vulnerabilities. If you want details about the other categories in this chart, see the full Security Intelligence Report.

   

  
  
  Chart 2 – Exploit activity over a one year period

  Java Exploits

  As we blogged a year ago, in 3Q10, the exploitation of Java vulnerabilities skyrocketed to new levels that we had never seen before. The analysis in SIRv11 shows that Java exploitation remains high and that the targeted vulnerabilities are quite old. The top four Java exploits are CVE-2010-0840, CVE-2008-5353, CVE-2010-0094, and CVE-2009-3867. These CVEs affect the Oracle Sun Java JRE or JDK, and all of them have updates available to fix them now. The most recent, CVE-2010-0094 and CVE-2010-0840, received updates in April 2010 after following a coordinated disclosure process with an external vendor.

  Operating System Exploits

  The jump in operating system exploits is primarily due to one technique: CVE-2010-2568 (the vulnerability mentioned earlier that was found with Stuxnet). This exploit was picked up by a number of families that were known to abuse Autorun. And, although CVE-2010-2568 has nothing to do with Autorun itself, the behavior is quite similar: the user connects to a USB device and browses the drive, the malware automatically executes (if the user hasn’t applied the update to fix the issue, that is). Malware authors must have found this exploit technique alluring. At least, the data certainly seems to indicate that they did. It’s also possible that attackers, after Microsoft released updates to harden the Autorun feature on older systems (which did appear to put a dent in their ability to infect users), were searching for ways to broaden their infection rate.

  Another interesting aspect in our exploit data on CVE-2010-2568 is the location of the targets. I recently did a talk at Virus Bulletin on the top exploits of 2011, and in that talk, I looked at geographical differences for regions that face the most exposure to exploitation attempts. Several regions that were at the top, Indonesia, Pakistan, and Vietnam, were there because of exploitation attempts for CVE-2010-2568. If you combine those three locations with two more, India and Mexico, those five together represent 52% of all the computers that have reported CVE-2010-2568 attack attempts in the first three quarters of this year. Although I don’t have update statistics for these regions, this data might indicate that there are large numbers of systems there that have not yet applied this very important update (MS10-046).

  Net Net

  I’ve talked about a lot of data in this post, and sometimes it’s hard to synthesize it. The key point of the exploit analysis in SIRv11 is that older vulnerabilities are what the vast majority of exploitation attempts target (90 percent are more than a year old). The special 0-day section of the report takes this concept even further – we look at how much of the malware infections are actually attributed to the exploit of vulnerabilities in general. (The answer: Less than 6 percent in 1H11.) To find out what the other 94 percent of infections are attributed to, download the report and keep your eye on this blog for more analysis to come.

  - Holly Stewart, MMPC

  

Digest powered by RSS Digest

• MSRT October ’11: EyeStye

  This month, the Malicious Software Removal Tool (MSRT) targets two families: Win32/EyeStye and Win32/Poison.

  EyeStye (aka ‘SpyEye’) is a family of trojans that steals information, targeting authentication data used for online banking such as passwords and digital certificates. The method it employs is called “form grabbing” which involves the interception of webform data submitted to the host through the client’s browser. By intercepting this data, authentication information can be stolen, and web content presented to the user can be altered to the malware author’s preference. In one recent EyeStye variant (for example SHA1 e36287d81770d583679be28d9a229f8363ab4cde) we came across, we observed that the following browsers were targeted, indicating that the malware authors are leaving few stones unturned: Internet Explorer, Mozilla, Chrome and Opera.

  The malware file contains obfuscated code, while the payload is injected into running processes. It also employs user-mode rootkit protection in an effort to prevent itself from being seen via Windows Explorer or the Command Prompt. This may be intended to make detection and remediation challenging for antivirus engines. As this bot is kit-based, the file names and mutexes it creates are variable, which makes identification (based on these factors) difficult.

  Towards the end of 2010, the release of EyeStye kit 1.3.X included a feature to avoid detection by Trusteer’s Rapport, a feature also offered by Zeus (Zbot). This release also removed a feature to kill Zeus if it was detected running on the affected machine, leading some to suggest that the two bots were being merged. However, by that time the Zeus code was already publicly available, which lead us to believe that those rumors were speculative in nature. We continue to monitor both of these bots for evidence of such a merger.

  As with much of the malware we see today, EyeStye is often spammed out to users or posted on open forums enticing users to click on a link, employing one of the increasingly common social engineering techniques. An example of such a spam email can be seen below: This spam mail was being posted in an open BSD forum; clicking on the link leads to a download of a file named “VIEW_EVENT_DOC.PIF”, which we detect as Win32/EyeStye (SHA1 df8a8483515dd0db3494d796ede33fddb369df10).

  
   

  For more information on this malware family, please refer to Win32/EyeStye.

   

  – MMPC

  

Digest powered by RSS Digest

• New: Microsoft Security Intelligence Report Volume 11- Now Available

  Hi, again everyone!

  Today we released the 11th volume of the Microsoft Security Intelligence Report, also known as SIRv11.   I have to say once again we’ve outdone ourselves and launched the largest and most comprehensive version of this report to date. This time it’s over 800 pages of threat intelligence spanning 100+ countries and regions around the world.  The report provides threat trends and data analysis on topics like software vulnerabilities, exploits, malicious code and potentially unwanted software.  We also cover third party products in the report.

  As part of SIRv11, we’ve included an in-depth analysis titled “Zeroing in on malware propagation.”

  The purpose of this study is to help customers better understand where malware was propagating and encourage the use of this information to prioritize where and how to focus risk management efforts.  In contrast to popular belief, this study found that zero-day vulnerabilities accounted for a very small percentage of actual infections.  In fact, none of the top malware families detected through our tools like the Malicious Software Removal Tool and Microsoft Security Essentials, and others propagated through the use of a zero-day.  And while some smaller families did take advantage of these types of vulnerabilities, less than 1 percent of all vulnerability attacks were against zero-day vulnerabilities – in other words, approximately 99% of attempted attacks impacted vulnerabilities for which an update was available.

  While these statistics may come as a surprise to some, the key takeaway is how malware was actually propagating and we found that to be through  user interaction-typically employing social engineering techniques, Autorun feature abuse, file-infection, various exploits (with updates available) and brute force password attacks. This study provides insight into the frequency in which these methods were being used to spread malware, and puts zero-day vulnerabilities into context against other propagation methods.

  The graph below outlines the areas I’ve mentioned and gives you a good idea of where we’re seeing malware propagate from – essentially the methods.

  Figure: Malware detected by the Microsoft Windows Malicious Software Removal Tool (MSRT) in the first half of 2011, categorized by propagation methods

  

  We’ve always known the bad guys use multiple methods of malware distribution to compromise users, and they often build this functionality into the malware itself.  As an example, Conficker exploits vulnerabilities, abuses Autorun, and guesses passwords to infect users.  Other families, like Taterf, Vobfus, Ramnit, and Renocide focus on Autorun abuse and incorporate social engineering tricks that require user interaction.  However the report provides insight into the frequency in which these methods were being used to spread.  It also puts zero-day into context against the other propagation methods.

  Zero-day vulnerabilities tend to strike fear in the hearts of consumers and IT professionals, and for good reason. They combine fear of the unknown and an inability to fix the vulnerability, which leaves customers feeling defenseless. It’s no surprise that zero-day vulnerabilities receive enormous coverage in the press when they happen, and should be treated with the utmost level of urgency by the affected vendor and the vendors’ customers. Despite the level of concern, there has been little measurement of the zero-day threat in the context of the broader threat landscape.

  The purpose of our featured story in SIRv11 was to put zero-day threats into context against the other malware propagation vectors and encourage IT Professionals to consider this information when prioritizing their security practices.  Zero-day threats are real and I don’t want to diminish the risk they represent.  However we hope that users will take this information into consideration when prioritizing their security efforts.  

  The study just scratches the surface on the intelligence contained in the SIRv11.  For more information on global or regional threat trends, check out the website.  As I said the report is huge and  contains data from over 600 million systems worldwide, over 280 million Hotmail accounts, billions of pages scanned by Bing each day and more importantly the report provides prescriptive guidance to help protect against the bad guys.

  I hope you enjoy this report.  If you would like to provide input on ideas for future reports, join the SIR Community where you can gain early access to upcoming announcements and SIR events, learn about early concept ideas and extended content as well as participate in feedback surveys that help to drive the direction of data analyzed.

  Thanks again and stay safe!!

  Vinny Gullotto 
  General Manager
  Microsoft Malware Protection Center

  

Digest powered by RSS Digest

• Online game trading – sometimes more than you bargained for

  Some online games offer features for the game players to sell their game items online. In such situations, it is highly likely some sellers may send the potential buyers a screenshot of their items for sale, for example, via Instant Messaging programs. 

  Recently, malware distributors have started taking advantage of this. They pretend to be selling items and send a “screenshot” of their items for sale, when in fact, the “screenshot” file sent is a malicious executable file disguised as an image file. When executed, it does display a screenshot of some rare items (see below image); however, malware is silently dropped and executed in the background.

  
  Figure 1 – Imitation screenshot displayed by the malware

  This whole process may be user-initiated, and the user remains uncompromised until they open the “screenshot” file.

  The disguised malware is detected as TrojanDropper:Win32/Fedripto.A. It can be configured to drop different malware components, and in the wild, the dropped file may be detected as Backdoor:Win32/Zegost.H – a remote control backdoor that is a prevalent threat in China.

  Play it safe and scan files received from unknown sellers before opening – the items they are “selling” may simply be – malware! 

  TrojanDropper:Win32/Fedripto.A SHA1: 84c1db933ea6159be27a642a03c2542e68f7adc9
  Backdoor:Win32/Zegost.H SHA1: b79c07da4a9b55f065adc7af3aad23f84c08d91e

  Chun Feng
  MMPC Melbourne

  

Digest powered by RSS Digest

• Operation b79 (Kelihos) and Additional MSRT September Release

  For the month of September, Microsoft is adding the Win32/Kelihos family to a second release of the Malicious Software Removal Tool. This additional release is to support the most recent action in Project MARS- Operation b79 which targets the Kelihos botnet. Operation b79 builds on the successes of the Rustock and Waledac takedowns. This operation extends previous legal tactics in addition to our various technical measures in that we are, for the first time, naming a defendant in a civil case involving a botnet. The intent of this tactic is sending a strong message to online criminals that accountability still applies on the Internet and that it is our goal to make online crime riskier and more expensive for those involved. You can see more details on the legal aspects of this operation in the blog of our partners in the Microsoft Digital Crimes Unit.

  The Win32/Kelihos malware family distributes spam email messages that may contain links to web sites serving installers of Kelihos itself. It may also communicate with remote computers to exchange information that it uses to execute various tasks such as bootstrapping to the botnet, sending spam emails promoting bogus products or services, stealing sensitive information, or downloading and executing arbitrary files.

  Figure 1 below shows the monthly reported counts from our telemetry for the Win32/Kelihos family. It made a big bang around the holidays last year by launching a holiday-themed spam campaign that distributed e-cards containing malicious links pointing to servers hosting Kelihos installers. As you can see in the chart, ever since then, it’s been slowly trying to grow in size.

   

  Figure 1 Win32/Kelihos Detection Reports

  We have observed Win32/Kelihos protecting itself by employing several techniques such as server-side polymorphism, encrypted communication (a sample of which is shown in Figure 2), fast-flux, and dynamic reconfiguration. Moreover, it is able to persistently connect to the botnet using an updatable peer list. It is also capable of updating itself so that it can utilize new or improved versions of itself and to perform additional tasks, if there are any.   In our investigation of this botnet’s command and control infrastructure, and as we allege in our complaint, we identified more than 3,700 subdomains being hosted in the Czech Republic by a single hoster. This same hoster had more than 215,000 subdomains hosting malware. In May of 2011, Google temporarily blocked more than 200,000 of these but reinstated the subdomains after the defendant allegedly corrected the problem.

  

  Figure 2 Encrypted Communication

  As a ploy to avoid detection by antivirus or security products, the binaries distributed by Win32/Kelihos are also wrapped in obfuscators that make use of anti-emulation tricks. In addition, Kelihos randomizes the header values of its HTTP request messages to make it harder for NIS/IPS products to catch them. Aside from randomizing the name of the HTM files, Kelihos has also taken to using different values for the User-Agent string of each subsequent message.

  Over the past months, Kelihos has launched various spam campaigns promoting scams or dubious products. Using reconfigurable email templates and lists, Kelihos is easily able to update its spam runs. This is why it is also possible for more than one spam campaign to run in the Kelihos botnet at any given time. Figure 3 below shows an example of a spam email template that is being distributed in the Kelihos botnet at the time of writing this blog post:

  Received: from unknown (HELO %^C6%^I^%.%^I^%.%^I^%.%^I^%^%) ([%^V6^%]) by %^A^% with ESMTP; %^D%^R20-300^%^% Message-ID: <%^O%^V6^%:%^R3-50^%^%%^V0^%> From: “%^Fmynames^% %^Fsurnames^%” <%^Fnames^%@%^Fdomains^%>To: <%^0^%> Subject: %^Fskli_subj^% Date: %^D-%^R30-600^%^% MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=”KOI8-R”; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.%^C7%^Foutver.6^%^% X-MimeOLE: Produced By Microsoft MimeOLE V6.00.%^V7^% ε?????? ?? Γ???????: - ???????? ? ????????? - ???????? ? ???????? - ????? ? ?????????? - ??????????? ? ?????? ??????: %^Fskli_link^%

  Figure 3 Spam Email Template

  The above template was used to distribute spam containing links to a website of a political activist group in Eastern Europe.

  Another payload of Kelihos is to steal sensitive information from the compromised computer. This includes attempting to harvest email addresses, FTP login credentials, and Bitcoin wallets, among other things. Our investigation also revealed that in addition to hosting Kelihos, defendants’ cz.cc domain has previously been investigated for delivering MacDefender, a type of rogue security software which infects Apple’s operating system.

  It is interesting to note that the Kelihos botnet shares significant similarities of its code with the Win32/Waledac botnet (Waledac was the target of our first Project MARS action- Operation b49).  These similarities have caused some to refer to Kelihos as “Waledac 2.0”. While similar to Waledac, the Kelihos botnet is more complicated in many ways. In spite of this complexity, we are hopeful that we will disrupt a meaningful portion of the botnet in addition to naming a defendant. Both of these are important steps towards deterring online crime globally.

  If you believe a computer under your care may be infected with Kelihos or other malicious software, we recommend that you leverage antivirus software from a software provider you trust. You can find information about Project MARS as well as additional support information at http://support.microsoft.com/botnets.

  

Digest powered by RSS Digest

• A tale of grannies, Chinese herbs, Tom Cruise, Alureon and steganography

  I’ve been monitoring the development of a particular strain of Alureon since the start of August this year. The installer (detected as Trojan:Win32/Alureon.FE – cc9a8000f80b6aecee30375e3277292a725acbfb) is easily distinguishable from more prevalent strains such as Trojan:Win32/Alureon.DX by the use of PE resources to store each component. This particular installer is often downloaded by variants of Trojan:Win32/Fakesysdef using remote file names such as ’531-direct’.

  

  Whilst investigating one of the components this week, I came across something new: Functionality to download another component with the file name ‘com32‘ had been added. I proceeded to download and decrypt this component. My initial analysis yielded what appeared to be functionality related to cryptography and JPG processing. This intriguing combination piqued my interest, owing in part to a section of the configuration file which I had examined earlier.

  

  I turned my attention to trying to determine the purpose of the URLs hosted on the free blogging sites “LiveJournal” and “WordPress”. The content of each page appeared to be benign, containing numerous and varied JPGs hosted on the free image provider “imageshack.us”. Examining the code responsible for retrieving the pages, I discovered the HTML content was parsed for specific IMG tags.

  

  Alureon would then attempt to retrieve the JPG pointed to by the markup. The raw data, along with a 61-character ASCII string, would then be passed to the ‘com32′ component. The long string had a distinctly password-like appearance.

  

  After further investigation, I was able to determine that embedded within each of the JPGs was a complete configuration file using steganography. One of the critical sections of the configuration file contains the list of command and control servers. The purpose of the publically hosted data was revealed — it’s there to provide a layer of redundancy and defense against existing domains that might become unavailable. In the event that no command and control server could be contacted, Alureon would then seek to retrieve an updated configuration file from these ‘backup’ locations. 

  And below is a collage of the images I encountered, in which the configuration file is tucked away — a grandmotherly woman, a bowl of Chinese medicinal herbs, and a fellow who appears to be the star of Top Gun.

  

  Whilst the use of data embedded and obfuscated within JPG files is not a new technique, it is interesting to see Alureon adopt this technique as part of a defensive mechanism.
   

  Scott Molenkamp
  MMPC Melbourne

  

Digest powered by RSS Digest

• Rustock Case Update

  Today, Microsoft’s Digital Crimes Unit announced that we have concluded our civil case against the Rustock botnet operators and turned evidence found during that investigation over to the FBI as a criminal referral. While the FBI will be driving that investigation, we will continue to offer the $250,000 reward for information which leads to the arrest and conviction of Rustock’s operators. Any leads can be sent to ms_referrals@ic.fbi.gov.

  We will continue to work with ISPs and CERTs to clean infected computers utilizing the telemetry we receive from having control of Rustock’s command and control domains. Since the takedown in March, and through this cooperation, the Rustock botnet has declined in volume by almost 75%. You can see more about the overall volume at peak in the special edition of our Security Intelligence Report on Rustock which we released in June.
   
  If you believe you may have a computer under your control which is infected with Rustock, you can find support information here: http://support.microsoft.com/contactus/cu_sc_virsec_b107#tab0
   
  It is our recommendation that any system infected with Rustock be cleaned with a full antivirus product as our telemetry shows that machines infected with Rustock are generally infected with other malicious software as well.
   
  – MMPC, Jeff Williams

  

Digest powered by RSS Digest

• Banker – the other way around

  There are many techniques used by malware in the banker family to steal user’s authentication credentials for online banking sites. We came across an interesting sample recently, detected as Trojan:Win32/Banload.A, which uses a remote proxy script in order to target online banking sites and facilitate data theft.

  When Trojan:Win32/Banload.A is executed, it opens an Internet browser to a certain animation site to trick the user into thinking that it’s nothing but an animation file:

   

  

   

  However, the cute animation masks the main objective of this trojan, which is to modify the web browser settings to use a Proxy Automatic Configuration script… And once set, that’s it! Mission accomplished! This malware’s job is done, for now…

   

  

   

  By using a proxy configuration script, the trojan sets the user’s Internet connection to be routed through a proxy server.
   
  Affected users should note that in the case of Trojan:Win32/Banload.A, because it makes changes to the proxy settings, removing the malware will not be enough to fix an affected computer and return it to a pre-compromised state. The configuration settings will need to be fixed manually. Without changing these settings, while the remote script remains available, the affected computer will still be utilizing it. The script effectively moderates the affected user’s Internet use – possibly providing false information and redirecting the user away from sites of their choice to sites of the attacker’s choice – with the affected user being none the wiser.
   
  MMPC downloaded the Proxy Script from the URL (shown in the above graphic) and found it to be malicious; we detect it as TrojanProxy:JS/Banker.B. It contains code that monitors for online banking sites visited by the affected user, and redirects traffic to a proxy server that could result in the theft of authentication credentials or other sensitive information.
   

  In order to change these proxy settings:
   
  1. In Internet Explorer, click the Tools menu, and then click Internet Options.
   
  2. Click the Connections tab, and then click LAN Settings.
   
  3. In the Automatic configuration area, de-select Use automatic configuration script.
   
  4. Click OK.
   

  For more information about using automatic proxy configuration, see the following articles:

  • http://technet.microsoft.com/en-us/library/dd361918.aspx
  • http://support.microsoft.com/kb/135982
  • http://support.microsoft.com/kb/819961

   

  SHA1s:
  C3D1E6E68CC5241F92F22C07F120487C0AFB03D4
  c93c7823c5ba4fe39a91964c8db08f413262719e
  0525cbdce83410586a7707c10aea49e87c3f8a19

   

  Jonathan San Jose
  MMPC Melbourne

  

Digest powered by RSS Digest

• Doing the Zbot spot; playing gotcha with a botnet

  Greetings Internet!

  This month (carefully hidden under the Win32/Bamital blanket), employing the old adage ‘fight fire with fire’, we decided to fight sneakiness with sneakiness and quietly slipped a fairly major Win32/Zbot update into MSRT.
   
  “Zbot” I hear you say? Yes, it’s still around and kicking. Despite Win32/Zbot (officially self-titled with the oh-so-ego-inflating ‘Zeus’ moniker, despite never fathering Hercules bot, nor employing lightning in any way during infection) being rumoured to have merged with Win32/EyeStye (aka SpyEye), we’re still seeing both distinct malware families out and about in the wild. Between the two, we’re finding that they’re responsible for a significant amount of the e-commerce-related fraud happening at any given time.
   
  Of course, since Zbot has been in MSRT since last October, MSRT has been continually updated monthly with all of our related signatures. We believe this tried-and-true method is effective – every month we clean between 60,000 and over 100,000 unique Windows computers:

   

  Month	Count
  March	103391
  April	113814
  May	60385
  June	83555
  July	61323
  August	89994

  So what’s changed? Well, let’s just say we felt it was time to turn the screws tighter on Zbot again. Whilst we get to do some pretty in-depth analysis of infections through the telemetry we get back from Microsoft Security Essentials, it’s time for us to get a really definitive snapshot of the Zbot infection ecosystem as best we could. I know! Statistics are fun! High five!

  Ideally, this information will help us and our partners in law enforcement battle the threat more effectively in the future.

  Naturally, once we see how things pan out in MSRT over the next couple of days, I’ll update you on how it’s all going!

  Until next we meet via the medium of blog (and/or interpretive dance),

   
  Matt McCormack
  MMPC Melbourne

  

Digest powered by RSS Digest