Over the past hour we’ve begun seeing a malware campaign hitting our filters that utilizes a common, and apparent favorite theme of the malware authors. These emails appear to resemble notifications from the eFax service that tons of people rely on to simplify their faxing needs. As is the case with a lot of these, actual logos and templates from real eFax notifications are used to trick the recipient into believing that these are just another ordinary eFax email and not a malicious facsimile (see what I did there?). However there are a couple of red flags that people should have noticed. One of the biggest is the fact that one of the banner graphics in the email is broken. The table is pointing towards an actual eFax file location, but it doesn’t appear to be there, possibly removed in order to be replaced by a newer advertisement. Another clue would be the supposed phone number presented in these emails. These are all randomly generated to look like real phone numbers as well as making every email just a little bit different in order to make blocking them a little more difficult as well. However, because they are randomly generated, some of them don’t exactly resemble phone numbers, such as the example below where the area code as well as the telephone prefix begin with the number zero, which you will not see in the United States.

malicious efax email

Another huge clue is that the attachment arrives as a zip file which you likely won’t see coming from eFax, also inside that Zip is an executable (which you really won’t see) named IMG.exe, they did try to disguise it by giving it a Pdf icon, although the icon itself is oddly pixelated, which I’ve seen more than once in different malware campaigns. I can’t be exactly sure what the point is in this or if it just occurred due to automation errors, that remains to be seen. It does serve as a sort of calling card though that more than likely links the origin of the campaigns that share this trait.

bad icon

If someone was unlucky enough to receive one of these and ran the executable, they wouldn’t notice very much going on on the surface, but behind the scenes the malware begins by making copies of itself and deleting the original executable in order to hide itself in the newly infected system. The sample then makes various checks for network connectivity before proceeding to receive instructions from command and control. We have seen nearly 300,000 pieces from this run so far, and at the time of capture, only 4 out of 57 AV’s recognized this piece of malware according to Virustotal, but AppRiver clients were safe as we proactively had protection in place to protect your inboxes.

With the release of iOS 8.2, Apple fixed the “GMT bug” that caused dual time zones to display in Calendar events. It is possible to edit and fix your individual calendar events that were displaying dual time zones in your iPhone or iPad’s Calendar after receiving the iOS 8.2 software update. This is a huge improvement over the previous iOS update, but you may have hundreds of events added to your calendar before the update that are still displaying the second time zone.

There is a method to remove the existing second time zones in bulk described by user JG in SB in Apple Support Communities forum that we were able to replicate, and tested with success even after the update to iOS 8.2.

Removing the second time zone from all events created prior to the update can be accomplished by performing these steps as follows:

1. From the Home screen tap Settings.


2. In the Settings app tap Mail, Contacts, Calendars.


3. Tap the Exchange email account.


4. Toggle Calendars synchronization Off by sliding the dialer from right to left (green to white)


5. Tap Delete from My iPhone to delete all existing Exchange calendar appointments. These events are backed up with Exchange.


6. Check the Calendar app to confirm all of the old events are deleted from the device then turn Calendars sync back on in the Settings.


This should reload all of the Exchange calendar events from the server back to the iPhone without the second time zone displayed in the previous version.

Click here to view the original post detailing the “GMT Bug” displaying dual time zones in Calendar events.

About the Author: Aaron Cohoon is a Mobile Solutions Administrator for AppRiver, a leading hosted Exchange e-mail security provider. Aaron has a significant Technical Support background in the telecommunications industry, accompanied with an immeasurable drive and dedication.

Apple launched iOS 8.2 Monday, March 9th, after extensive beta testing. The most recent beta version of Apple’s mobile operating system was confirmed to have corrected the time zone issue frustrating many hosted Exchange and other subscribed calendar users for months. A bug fix listed in the official iOS 8.2 release notes includes that the update “Fixes a timezone issue where Calendar events appear in GMT”.


The “GMT Bug” has been prevalent when opening events within the Calendar app on iPhones, iPads, and other Apple devices running iOS 8 through iOS 8.1.3. Not all users experienced this, however, as it only occurred when those events had been created or edited using a different mobile device or calendar client application, and synchronized with a server hosted outside of the iPhone or iPad’s local time zone.

In testing a new calendar event was created on an iPhone 5 still running iOS 8.1.3 then opened the same synchronized event in the Calendar app on an iPhone 6, running the newly updated iOS 8.2. The event displayed correctly with no second time zone below the device’s local time zone.




A second test event was created on the same iPhone 6, and opened it on the iPhone 5 still running iOS 8.1.3. When opened within the Calendar app on the iPhone 5, the event that was created in iOS 8.2 displayed a second time zone below the device’s local time for the event. This is consistent with previous testing with the same iPhones running iOS 8 through 8.1.3.


The iPhone 5 software was then updated from iOS 8.1.3 to iOS 8.2, and new test events were created on the iPhone 5 and iPhone 6. Once the events synchronized and displayed on one iPhone after being created in the Calendar app on the other device, they consistently displayed correctly, excluding the second time zone that showed up in events created prior to the software update. Testing confirmed the update fixes all new events.

Events Created Before the Update

Events that were created using a different mobile device or calendar application prior to the update to iOS 8.2 on the iPhone 6 still retained the second time zone. While this continues one inconvenience of the issue into the update, there has been a significant improvement in how iOS 8.2 handles synchronizations of edits to Calendar events.

Removing the second time zone from events created prior to the update can be accomplished by taking the proceeding steps:

1. Open a Calendar event that is displaying the second time zone. In the Event details screen tap Edit.



2. Tap on Starts to edit the start time of the event.



3. The edit Date, Time, and Time Zone fields will appear. Make sure the date and time are correct, choose your local Time Zone and tap Done.



The calendar event will now synchronize without including the “origination” server time, and display correctly when opened from another iPhone or iPad that is running iOS 8.2.

While these steps correct individual posts, there are additional steps to fix all past events. If you are experiencing this on your iPhone or iPad click here for more details to repair events affected by the GMT bug.

Click here to view the original post detailing the “GMT Bug” displaying dual time zones in Calendar events.

About the Author: Aaron Cohoon is a Mobile Solutions Administrator for AppRiver, a leading hosted Exchange e-mail security provider. Aaron has a significant Technical Support background in the telecommunications industry, accompanied with an immeasurable drive and dedication.

shutterstock_93443800Email-borne attacks come in various shapes and sizes- phishing, spear phishing, Trojans, malicious attachments, hidden scripts and more. While most have evil intentions… some are more sinister than others.

In 2014 a steel plant in Germany was attacked by a group of unknown hackers. The attackers were targeting Industrial Control Systems (ICS), with what appears to be the objective of damaging the company’s productivity. The attackers were able to cause “massive damage to the system” according to one report. Though the hackers appear to have relied on some very specialized malware designed with ICS targeting built in, they gained their initial access via a fairly basic spear phishing attack.

The volume of malicious email has exploded over the past few years, all the while the growing number of malware variants designed to specifically target Industrial Control Systems has grown along with it.  Meanwhile, phishing/spear phishing has remained a popular attack vector for malicious actors trying to gain that initial access to an organization. Once inside an organization and a back door has been established, the attackers can further infect the target with these sorts of specialized malware that can take control of things like ICS.

For example the Dragonfly group compromising several multiple companies in the Energy sector often using a remote access trojan dubbed Havex in the summer of 2013. These infections originated with targeted emails to one or more people at a given organization. Once inside, they were able to implant their trojan inside software that was available for download on these companies websites, potentially compromising ICS that were currently in use. These malicious assets could have later been used for much more sinister purposes.

So why is hacking against ICS so concerning? ICS include things like Energy Management Systems, Distributed Control Systems, Instrument Control, Building Automation, Programmable Logic Controllers, etc… These are the systems that control utilities like power grids to drinking water, safety systems to manufacturing plants… just to name a few. In other words there is a great deal of damage that can be done by attacking ICS.

These types of attacks will prove to be more complex and more frequent going forward as more automation continues to expand across the globe. ICS will be targeted by for profit hacking groups as well as attacks initiated by nation states. We can expect to see these attacks against business and government entities and utilities alike.

While there is no cure-all that will put an end to these attacks, security professionals can focus on shrinking the attack surface.  We know that attackers often use spear phishing as an initial infection vector to ultimately gain access to internal networks. So, organizations can mitigate their odds of attack by using an intelligent email security solution, and educating its users on best practices for IT security.  After all, most employees don’t realize that it only takes one entry point for an entire network to become compromised.

Other tips to shore up your defenses include:

  •   Hackers often leverage vulnerabilities in outdated software.  That’s why Web browsers and third-party software must be kept up to date.
  •   Keep a healthy level of skepticism when reading  unsolicited email.  Never click on its links or attachments.
  •   Foster a work environment that rewards honesty.  Once a company’s perimeter has been breached, reaction time plays a critical role in mitigating the damage.  Employees should not be afraid of facing   repercussions if they’ve fallen victim to an attack.  Instead, they should be encouraged to inform their IT Department straight away.

This morning we had a decent sized malware campaign start across our servers. There wasn’t much to the actual body of the message with it just being some small plain text. The subject just mentions a time sheet and the body says this time it has an attachment. Just enough information to get a user possibly curious to open the file.


 The attached zip has a small executable inside. As of writing this, 11 of 57 AV companies have it classified as malware. Most have it classified as Upatre. Upatre is a piece of malware aimed at downloading other malware on to the machine.

In this case, the downloader executable says it was compiled on March 24, 2006, which is very likely fake. The creation time is often faked just to try and throw people off on it. It was probably created with the last day or two given the low detection rate with AV scanners. This is also like many other tricky malware we have seen in which an icon resource is used in the exe to make it look like something familiar. With this virus, it looks like a pdf. This is a very common tactic used since an average user can relate to a pdf file just being something to read. I generally always recommend to set Windows to show all file extensions just for reasons like this. Teaching users to not open exe’s doesn’t help too much if the file extensions are hidden.

Screenshot from 2015-02-24 09:35:54

If file extensions were shown, you could see the .exe at the end

Once the malware is run, it reaches out to download a few files that appear to be encrypted. A few of the first attempts for the png file failed on file retrieval and it hopped around until it found a server that had the file. And on one particular file that had a .tar extension, it downloaded it 8 times.

Screenshot from 2015-02-24 09:47:31

Not actually a png

This was downloaded 8 times

This was downloaded 8 times. Not actually a tar file.


After the files are all downloaded, the malware made a connection out to a direct IP address using SSL, had about a 2kb conversation, and no more action was seen. Likely this malware is sitting idle and possibly waiting to steal credentials. There were a lot of modifications and queries to Outlook related registry keys and it opens a pst file if one is on the machine. So it may also bring the machine online to a botnet to send spam and malware to a users contacts.

This was a campaign that came in pretty heavy and pretty quick. Between 6AM and 7AM this morning, we stopped a little over 1.5 million. Since then, we have seen about 5 thousand an hour. The good news about this campaign is that the campaign in its entirety was stopped by a virus rule we had written a few days ago. Sometimes with the always evolving malware out there, we have to react within the first few minutes of a new campaign to stop it. But this is one of the cases where prior research had helped us predict future variations of malware, and stop the malware campaign from the very first message. When a new unseen piece of malware comes in, we can have it blocked system wide within minutes (compared to hours for some AV vendors). But from there we take the time to see why the file wasn’t blocked and see what rules we can write to try and block future variations. This allows us to have many cases like this where no leakage is seen for an initial blast of malware and all messages are caught.