Attacks/Breaches
7/26/2012
08:53 AM
50%
50%

Mahdi Malware Makers Push Anti-American Update

Spy malware, seemingly built by Iranians, gets update that searches for "USA" and "gov" on targeted machines, security researcher says at Black Hat.

Seculert found numerous clues suggesting that the malware had been built by Iranians. "We were able to identify strings within the communication that were in Farsi. Also, part of the strings were dates that were in the Persian calendar, which is different than the Gregorian calendar," said Raff, noting that most developers prefer to code in their native tongue.

Previously, four C&C servers controlled all Mahdi infections. "The interesting part is that one server is used mostly with Israeli targets, while the other three are for Iranian and Arab targets," said Raff. "The one used for Israel also targets other Middle Eastern countries, but there are no Israeli targets on the other three." All four C&C servers were also hosted by the same provider in Canada, although a whois lookup on the IP addresses claims that they're really based in Azerbaijan, and in one case on the premises of that country's Royal Bank. But according to Seculert, "we confirmed with several ISPs that the physical addresses of the C&C servers are indeed located in the headquarters of the Canadian hosting provider."

According to Seculert, about half of the 800 known systems infected by Mahdi--all via targeted attacks--have been in Iran, while roughly 7% of infections were in Israel. "Looking deeper into the Mahdi victims' IP addresses, we did find a few dozen IP addresses which seem to be from non-Middle-Eastern countries, such as the U.S and U.K.," according to Seculert, although it appeared that the infected machines were owned by people who were only visiting those countries. But those Seculert findings differed from research subsequently published by Symantec, which claimed that 72% of all Mahdi infections involved PCs in Israel.

What accounts for that discrepancy? "Symantec may have come up with 72% because they were only looking at variants which communicated with the C&C servers targeting entities from Israel," according to Seculert's latest analysis. "Or, maybe they are looking only at their customer's machines which they found to be infected with Mahdi. As an American company, Symantec is not allowed to sell their products to Iran, and therefore they can't see infections in Iran." But Raff noted that Seculert's analysis had come from identifying PCs that had connected to the Mahdi botnet itself.

One final piece of evidence that the botnet was built by Iranians involves its naming conventions. "Each bot node [infected PC] receives a unique identifier," Raff said, which is a text string combining reused prefixes with unique text strings, so that any individual machine can be quickly identified and controlled. Some of the words used to construct those prefixes include these names: Chabehar, Iranshahr, Khash, Nikshahr, Saravan, and Zabol. All of those names refer to cities or counties in Iran. Another prefix also used by developers, meanwhile, was "Flame."

Is that, finally, evidence of a connection between Mahdi and Flame? The answer is likely no. According to Seculert, "the first targeted victim with the 'Flame' prefix began communicating with the C&C server in early June, right after the Kaspersky Lab discovery of Flame went public." In other words, the inclusion of the word "Flame" in Mahdi appeared to have been made after Flame became public knowledge.

Previous
2 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: just wondering...Thanx
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.