Inside an attack by the Syrian Electronic Army

A follow-up to this story can be found here.

The Syrian Electronic Army (SEA) has become a bit of a name brand as far as low-level hacking groups are concerned. Their methods are simple, but effective. They spend most of their energy on propaganda and self-promotion, but lately they’ve taken to targeting media organizations (or the people associated with them) and IDG Enterprise is no exception.

Through internal communications during the attack, my investigation into the incident, and other sources of data, here’s a first-hand view of what it’s like to be in the middle of a security incident from a known attacker, and avoid major problems.

Just another day on the job:

It was a typical Monday in May at CSO. However, elsewhere within IDG Enterprise, a story was about to hit the wires that could cause some issues. Ira Winkler, a known security expert and President of Secure Mentem, was about to have an editorial published on Computerworld, which focused largely on the SEA.

Earlier in the year, Winkler had given a talk about the SEA during the RSA Conference, where he compared the group to cockroaches and dismissed them as a major threat. In addition, he discussed various aspects of their operations, and explained how organizations can defend themselves against the group.

His remarks clearly left some SEA members with hurt feelings.

Some time later, once the video of the talk was posted to the Web, the SEA hijacked the DNS settings for the conference website (rsaconference.com) and pointed visitors to an image hosting a warning for Winkler. The attack itself was far from advanced, but it worked despite its simplicity.

After the attack against the RSA Conference domain, the SEA hijacked the Wall Street Journal Digital’s account on Twitter, in order to post an image of Winkler’s head on the body of a cockroach. This attempt at humiliation, childish as it was, used simple means in order to reach an objective. Their prank did nothing to alter Winkler’s thoughts on the group.

Awareness in action:

Knowing that the Computerworld editorial was coming, an email went out to all IDG staff. In it, the IT department explained that the pending editorial could cause some problems, and if the SEA’s past actions were any indication, they would soon start targeting IDG Enterprise.

“Computerworld is planning to run a column soon that may incite attack on our sites and/or social media accounts by the Syrian Electronic Army. This could affect every one of us through our email accounts, as well as those of you who manage web sites and social media accounts for IDG. We all need to be extremely cautious about clinking on links or opening up attachments within emails specifically those who we are unsure of [whom] the sender is.”

Awareness messages such as this are common within the company, especially where scams, Phishing emails, or malicious attachments are concerned. It’s just good policy.

Phishing or something like it:

Soon after the first warning was circulated, the Phishing emails started to arrive. These were pitiful, poorly written attempts, but I willingly admit – I say so as a person who is supposed to spot these things out of habit.

The Phishing email used the address of an ex-employee, and directed recipients to a Computerworld article.

However, the actual link pointed to a domain that wasn’t related to Computerworld, or any other IDG Enterprise domain. And when clicked, the URL pointed to a version of Outlook Web Access (OWA) that wasn’t used by IDG.

Red Flag #1 – Using an ex-employee’s address as the spoofed “From:” account. This is a huge red flag.

Red Flag #2 – Failing to realize that most journalists, especially those who report on security matters, read email in plain text – so we’ll spot the fake domain like a sore thumb.

Red Flag #3 – Using a landing page in the Phishing email that wasn’t authored by the victims themselves. These things stand out when you use Web-based-anything on a regular basis. So the fake Outlook login page makes no sense, especially if we’re expecting to see a news article.

I followed-up on the domain used in the Phishing email. It was an add-on domain, unrelated to the primary domain used by the victim company, but registered and hosted on the reseller account in order to prevent someone from capitalizing on the brand itself.

The victim’s primary domain used an outdated version of Joomla, a CMS platform that rivals WordPress. More to the point, it was running an old Joomla theme, which could explain how the SEA accessed the account.

On shared hosting, access to one domain will often grant permissions to all domains on the account, since they are using shared space and resources. It’s also possible that the domain owner or webhost was the victim of a socially based attack, such as Phishing.

Either way, once contacted, the owner of the domain reported it to the hosting company, which simply deleted the scripts and the fake OWA panel – preventing Salted Hash from examining them further. From this point, I tracked the email itself, or rather the server that delivered it.

The little things give you away:

The initial set of Phishing emails came form a customer of a well-known webhosting provider that specializes in Virtual Private Server (VPS) offerings. This customer, a website that focuses on current events and how they shape the political landscape globally, was a victim too.

While the SEA only attempted to target IDG Enterprise, they were successful in their campaigns against the VPS customer.

This second victim, as detailed in discussions with Salted Hash, was likely compromised due to a third-party add-on on their WordPress installation. After detecting the initial breach, which led to the IDG Enterprise Phishing emails, the victim reset their virtual instance and started the recovery process.

The malicious files that enabled the Phishing blast were present before the reset, and appeared afterwards, in the exact same add-on folder.

Either this means there is a zero-day vulnerability in the add-on, or the server itself is compromised. Internal investigations by the victim have determined that the add-on is the problem, and they’ve taken steps to protect their accounts. The vendor responsible for the add-on WordPress script was notified, but they have made no comment on the matter.

It’s an interesting side note that the VPS victim was also targeted by the SEA in the past.

In addition to the red flags raised above by this most recent attempt, the VPS victim has also seen emails from someone that’s a magazine editor (or their email account at the least), yet the messages are filled with grammatical errors. In fact, the emails were written in sloppy English.

For the record, the VPS victim confirmed they were able to clean their domain and prevent any further hijacking, but Salted Hash will be privy to any future attempts and the recovery process.

A non-advanced persistent threat:

After investigating the IDG Enterprise attack, and talking to the victims, it’s clear that the Syrian Electronic Army isn’t always successful in their attacks, but they do have success. However, this success isn’t because they are elite hackers, it’s because people continue to fall for their poorly crafted schemes.

For example, not long after the Phishing emails were circulating on the IDG Enterprise network, the phone calls started.

“We have received a few reports of phishing attempts coming in via telephone/cell phone to a few IDG employees today,” an awareness email on the topic to company employees explains.

“One such caller was stating he was from the internal support department and needed the password from their Windows machine. The caller was pressing hard for this information, stating it was critical that he get this information. After the IDG client pressed him for some further information, the call was terminated.”

However, an employee relayed a different version of the same event, which is worth repeating. A person, with a heavy accent, called an IDG Enterprise employee and claimed that they were with the “computer technical department” and requested a password for the employee’s “Windows machine.”

The call came from a blocked number, reading as unavailable on caller ID, and the caller didn’t have any answers when pressed for information. For example, when asked what company they were with, the response was a flat, “yours.”

Scams involving support-based phone calls are nothing new. In fact, it’s possible that this was bad timing and unrelated to the SEA at all. But still, the details match with stories offered by other SEA victims and the timing is just too convenient to be anything else.

Earlier this year, IntelCrawler published a report on the SEA that covers their antics. The report marks them as a dangerous group, but based on their most recent efforts, and what they’ve done in the past, perhaps there is an A Team and a B Team, and the B Team are the slackers.

Still, slackers or not, it isn’t wise to dismiss them out-of-hand. Make no mistake, the SEA targets the weakest point in the security chain (humans), and they’re highly successful.

At the same time, most of their attacks rely on tactics that are easily spotted and schemes that are easily avoided. If anything, one could argue that the SEA are the poster children for user awareness training.

So in this case, the SEA targeted IDG Enterprise, and were ultimately unsuccessful. We were able to hold our own due to awareness training, and the fact that employees were given advance warning.

Unfortunately, as is clear when looking at their previous victims, such warnings and awareness are the exception and not the rule. I’ll argue we were fortunate in this case. If it wasn’t for the fact that we expected it, knew what to look for, and constantly communicate, we too might have been victims.

For a solid overview on the SEA, their methods, and their previous victims, the aforementioned IntelCrawler report is a great starting point.

As for dealing with the SEA directly, communication is the key. After that, the following are things that Ira Winkler suggests as mitigation steps:

• Make sure that all URLs related to the company are locked, which will prevent them from being transferred or otherwise altered at the registrar level.
• When it comes to social media, such as Twitter or Facebook, use two-factor authentication options.
• Related to the second point, make sure that the people responsible for social media accounts are aware of any potential threats, and know how to deal with Phishing or Social Engineering attempts. Special attention should be paid to people who have access to Tweetdeck, Hootsuite, or the equivalents.

Once inside, the SEA will use their access to send messages to known associates of the compromised accounts, which in turn are used to further their foothold on the victim organization. Also, they will mine the compromised email accounts for addition authentication data.

It’s also likely that they will attempt to reuse passwords on accounts outside of the company, made possible because recycling credentials is a common activity among most people online.

Special attention should be given to users on mobile devices, as they lack the ability to perform the anti-Phishing checks that most desktop users can, including hovering over URLs to determine the actual source. In addition most mobile users are without anti-Phishing (reputation based) protections, and lack the ability to detect malicious attachments.