Top Middle East Cyber Threats- 16 July 2019
At Help AG, our Managed Security Services (MSS) team offers 24x7x365 monitoring of complex IT security infrastructures to some of the largest enterprises in the region. As a result, we have our eyes keenly fixed on the cybersecurity threat landscape and are among the first in the region to learn and act upon new threats.
In this blog, I share the top three cybersecurity threats our MSS team has recently come across. So, read on to learn about what you need to look out for in the weeks ahead:
1) Navigating Muddy Waters
Seedworm a.k.a MuddyWater is an emerging APT group targeting the Middle East agencies. Their attacks are characterized by the use of a slow evolving, multi-stage Power-Shell based first stage backdoor known as POWERSTATS.
These attackers are known to primarily focus on governmental organizations and various IT and telecommunication sectors. These hackers have targeted various compromised legitimate accounts belonging to military entities and educational institutions in Jordan, Turkey, Azerbaijan and Pakistan.
Iraq and Saudi Arabia have also been targeted consistently, and other victims have also been detected in countries like Mali, Austria, Russia, Europe, US, Iran and Bahrain.
Attack Description
The attackers use a series of compromised websites which act as proxies to encapsulate the real address of their C2 server.
- Communication is established between the infected endpoint and a random proxy server.
- The information extracted from these victims is then sent over to the C2 server via the proxies, thereby masquerading the IP address from the victims.
- The attackers then route commands to each backdoor by interacting with the C2 server.
A decoy document containing the malicious macro is dispatched to the initial backdoor.
The table below outlines the MuddyWater campaign trend in the first half of 2019 as reported in this article:
Discovery Month | Method for dropping malicious code | Type of files dropped | Final payload |
January 2019 | Macros | EXE | SHARPSTATS |
January 2019 | Macros | INF, EXE | DELPHSTATS |
March 2019 | Macros | Base64 encoded, BAT | POWERSTATS v2 |
April 2019 | Template injection | Document with macros | POWERSTATS v1 or v2 |
May 2019 | Macros | VBE | POWERSTATS v3 |
Recommendations and Remediations
- It is advised to eliminate security loopholes while also monitoring and fixing improper system configurations or errors in proprietary applications.
- Block the attackers’ known Indicators of Compromise (IoCs) on your security appliances for detection and prevention purposes.
- Enable a whitelisting solution to prevent process child-parent execution hierarchies.
- Vulnerability assessments and patch management must be in regular practice.
- Network Access Control (NAC) must be enabled to block access and prevent APTs from spreading.
- Enabling a web application firewall will prevent sensitive data from falling into the wrong hands.
- Consider using an IDPS solution to detect and prevent such attacks before they spawn in the system.
- All employees should be made aware of the risks of spear phishing and how to identify and tackle such attempts.
2) Snooping on O365 Inboxes with Hidden Rules
The security community has begun noticing that attackers are using various techniques such as phishing to compromise Microsoft Exchange credentials. They craft malicious Inbox rules to copy the incoming and outgoing emails of the target victim. As a result, the attacker gains guaranteed access to the victim’s emails, irrespective of whether their credentials have been changed or not. Moreover, the victim can be completely unaware of this attack and Outlook does not provide any indication of a corrupted inbox rule.
These hidden rules have been taken advantage of and are being leveraged for attacks that include persistence, reconnaissance and data collection, as researched by Matthew Green in this article.
Attack Description
Though there are multiple steps involved in the attack, making the inbox rule hidden is the point of focus for the attackers. As described in an article by Compass Security, the following step by step process is undertaken by the attacker:
- The attacker manages to get hold of the victim’s mailbox credentials by malicious activities such as phishing.
- Once the attacker has successfully obtained access into the victim’s mailbox in Outlook, he/she uses Outlook’s wizard tool to create a rule in the victim’s inbox. After being setting up in the wizard, this rule is enabled and visible.
- The attacker then hides the rule created in the previous step. Even though the rule is hidden in popular email clients as well as in Exchange Administration tools, it remains functional.
- This makes it difficult for the rule to be detected by the victim and even the administrator.
- Hiding the rule is achieved by using MAPI (Microsoft’s messaging API). MAPI is used by messaging applications to access the messaging subsystem of Windows.
- MFCMapi, a MAPI client, enables us to view and set low-level contents (raw data) of underlying Exchange-storage Databases.
- The magic for making the rule hidden, is to empty the following two properties of the inbox’s “Associated Content Table”:
- PR_RULE_MSG_NAME <– Empty ANSI String
- PR_RULE_MSG_PROVIDER <– Empty ANSI String
Removal of these two properties is what makes the inbox rule invisible to common messaging applications, thereby making it more difficult to detect.
Detection
Detection of hidden inbox rules can be done on two main ways, as described by Matthew Green in his above mentioned article:
MAPI based – point in time:
Microsoft released a script for use over Exchange Web Services (EWS) – Get-AllTenantRulesAndForms that enables tenant wide collection of Exchange Rules and Forms querying the low-level data stores. This script enables visibility of Hidden Rules but leaves out an essential PR_RULE_MSG_PROVIDER field for detection. A fake, mistyped or blank PR_RULE_MSG_PROVIDER field, keeps the rule hidden.
Unified Audit Log (UAL) – telemetry:
UAL is a centralized log that stores audit events for all Azure services.
It is accessed via O365 WebUI.or EMS administration.
This method is effective for active monitoring via a SIEM or monitoring solution.
It is also possible to indirectly detect the hidden inbox rules with O365. One such method is a built-in alerting system on forwarding mail to external addresses. This alert will also be generated as a SecurityComplianceAlert in the UAL. But if the account has been compromised, it is possible for the attacker to suppress such alerts to stay under the radar.
Remediation
The following measures were published by the Cyber and Infrastructure Security Agency (CISA) for organizations migrating their email services to Microsoft Office 365:
- Multi-factor authentication: This is the best mitigation technique for protection against credential theft for O365 users.
- Enable unified audit logging in the Security and Compliance Centre.
- Enable mailbox auditing for each user.
- Ensure Azure AD password sync is planned for and configured correctly, prior to migrating users.
- Disable legacy email protocols, if not required, or limit their use to specific users.
Help AG recommends implementing the following advice (courtesy of Microsoft’s John Lambert in his Office 365 attacks PPTX) to further mitigate threats and attacks against O365 users and mailboxes:
- Implement a process for detection and approval of new Azure Apps.
- Regularly review Forwarding Rules enabled across all mailboxes and implement a company-wide policy addressing Auto-Forwarding of emails.
- Identify and disable ‘Open’ mailboxes (Default: Allow Anyone) and implement “No Access by Default” on new mailboxes.
- Monitor access to Azure/Exchange/O365 Administrative Users/Interfaces.
For individual mailboxes however, we would recommend following the advice by Compass-Security in their article:
- The best way to remove hidden inbox rules is through a MAPI editor such as “MFCMapi”. Alternatively, this can also be done by running Outlook with the “/cleanrules” flag. This removes all the rules on the corresponding mailbox (not only the hidden ones).
3) Frankenstein Attacks!
Security researchers at Cisco Talos recently discovered a series of attacks aimed at infecting victims with malware designed to harvest credentials. The researchers have named the campaign as ‘Frankenstein’ – due to the threat actor’s ability to build malicious tools with freely available and unrelated components.
Threat actors behind the campaign are believed to be moderately sophisticated and highly resourceful. Their preference for open-source solutions appears to be part of a broader trend in which adversaries are increasingly using publicly available solutions.
The campaign used freely available components of:
- An article to detect when your sample is being run in a VM.
- A GitHub project that leverages MSbuild to execute a PowerShell command.
- A component of GitHub project called “Fruityc2” to build a stager.
- A GitHub project called “PowerShell Empire” for their agents.
Attack Description
Talos has identified two different infection vectors associated with this campaign. To compromise their victims, the threat actors sent trojanized Microsoft Word documents, mainly via email.
The first vector relies on a trojanized document that fetches a remote template and then uses a known exploit. Once the victim opens the document, it fetches a remove template from the actor-controlled website, hxxp://droobox[.]online:80/luncher.doc. Once the luncher.doc is downloaded, it uses CVE-2017-11882, to execute the code on the victim’s machine. After the exploit, the file runs a command script to set up persistence as a scheduled task named “WinUpdate”. The newly created schedule task runs a series of base 64-encoded PowerShell commands that act as a stager.
Since the threat actors create fake security labels for malicious documents (e.g. secured by Kaspersky – to enable macro), this technique could also indicate that the threat actor had performed reconnaissance on the intended victims, suggesting that the documents had been socially engineered to some degree.
Some of the analysed documents displayed the national flag of Jordan, as well as logos that appear to be from several Middle East government agencies. Lastly, the document also showed an image of unspecified buildings.
The second vector is a trojanized Word document that prompts the victim to enable macros and run a Visual Basic script that checks for anti-malware analysis tools like a sample running in sandbox environment, process explorer, Wireshark, fiddler, etc. If they are present and running on the system, the script will stop execution.
Once the evasion checks are complete, the threat actors use MSbuild to execute an actor-created file named “LOCALAPPDATA\Intel\instal.xml”. The researchers from Talos suspect the adversaries chose MSBuild because it is a signed Microsoft binary, meaning that it can bypass application whitelisting controls on the host when being used to execute arbitrary code.
Once the “instal.xml” file begins execution, it would deobfuscate the base 64-encoded commands.
When executed successfully, the stager connects to the C2. After the successful GET request, the C2 would return a string of characters. Once the string is RC4 decrypted, it launches a PowerShell Empire agent.
The PowerShell script attempts to enumerate the host to look for information, such as – username, domain name, machine name, and public IP address. It also checks if the user has administrative privileges, extracts a list of all the running processes, and more.
The agent includes functionality to communicate via an encrypted channel, in this case AES-CBC, in addition to using a specific user-agent string and a session key. This agent then allows the threat actors to remotely interact with the agent to upload and download files and to use the various plugins that are compatible with the Empire framework, such as those used to harvest credentials on the victim’s machine.
Remediation
- It is recommended to blacklist the attack’s known Indicators of Compromise (IoCs) on your security appliances to help detect and prevent any malicious attempts made by the same.
- Exercise caution when receiving or accessing unsolicited, unexpected or suspicious files / emails / URLs.
- Disable execution of scripts on users’ endpoint devices or restrict execution to a virtual environment if required.
- Keep operating systems and software up-to-date with the latest patches.
- Maintain up-to-date antivirus software, and scan all software downloaded from the internet before executing.
As always, at Help AG, we’re here to help you protect against these any other cyber threats so please reach out to us for all your cyber security needs.