In many malware cases, the infection method can be far more elaborate than the actual malware being installed. This is the case with Newscaster, a campaign believed to have Iranian origins and targeting US defense contractors, high ranking military officials, and government officials. With an infection vector so involved, and malware as simple as it is, this campaign was able to avoid detection since it began in 2011.
Spreading the news
In a report for the recently exposed attack dubbed “Newscaster” by iSIGHT Partners (documented here) highlight how social networks, combined with social engineering efforts continue to be a highly successful attack vector. The level of effort, time and detail expended, combined with the profile of the victims was significant.
Fake news site that was used in the attacks
The report details how senior targets in the military, diplomats, defense contractors and journalists all became victims of a well-engineered social network attack that leveraged a fictitious news website “NewsOnAir.org” utilizing fictitious reporting personas that interacted with the victims over LinkedIn, Facebook, Google+, and Twitter. It is believed that the core group of attackers are Iranian.
Potential Facebook site used in the attacks
The usual approach to social engineering attacks on social networks is to lure users into providing credentials or opening files/links intended to compromise their computers.
The attacks in this campaign came from an attacker posing as a legitimate persona, sharing common interests or business goals. The convinced victim will "connect" with the attacker, whom they believe they know, or has similar interests or has business goals. This will then lead to dialog with the attacker masquerading as a peer.
Once the connection is made, the attacker will send “spear phishing” emails or direct messages containing links to the victim through the chosen platform (Facebook, Google services, LinkedIn, Twitter).
Fake Google+ account with Typo
Google+ Account has 142 people/organizations in their circles including several government and politicians which contribute to its 'clout'.
The victim is far more likely to click any links that have been directly shared with them especially if blended with other legitimate dialog related to the common interest.
The payload of these messages ultimately results in data loss or theft – typically delivered as spear phishing emails or instant message communication to deliver data stealing malware or user supplied credentials.
The website was made to look legitimate by providing news feeds from legitimate sites, but with the bylines of the articles posted changed to the fake personas used by the attackers to increase the legitimacy of any interaction with the victim.
The Cylance research team discovered 90 samples related to this campaign, 12 of those still without any detection after extended period of time. Many of these samples leveraged Botnet / IRC techniques to control the victim PC.
The below sample is one example of a Flash video "bait" embedded in a malicious executable. Original analysis date was 1 year ago with zero detection 1 year later.
The sample would have likely been delivered via a phishing email. The below screen shot shows the “Flash player” executing.
Let's take a deeper look into this sample, so we can better understand the leverage gained from these infections. The samples fall into two primary groups, installer and bot.
The installer portion is the result of a file binder which executes the bot and bait at the same time. The name of the file binder being used is "SetupEx". The bait typically is some form of product installer or funny video. When we first execute this sample installer, we can see the bait application running.
The bait in this installer is a Flash video
The bot component is the core of the payload. Its operations are simple but effective. It does have methods implemented to avoid detection, but they are not advanced.
We can observe some of these methods statically. For instance, there are a large number of encoded strings in the binary. The encoding method is inverting the alphabet (for instance 'a' becomes 'z'). To save time, I developed a script to automate this decoding.
You will be able to see strings such as the remote domain for the IRC server, the channel being used on the IRC server, its password, etc. This information is not stored in a rigid format, so you still must extract them from the results of this script. Here is some sample output when decoding the mutex name.
bwall@research:~$ echo "zuLmvXlkbNfgvc" | python alphareverse.py
Example usage of decoding script
We can use some of the encoded strings to create an effective YARA rule (detects 85 of 90 samples).
$needed01 = "PON\\HLUGDZIV\\Nrxilhlug\\Drmwldh\\XfiivmgEvihrlm\\Klorxrvh\\Vckolivi\\Ifm"
$needed02 = "zuLmvXlkbNfgvc"
$needed03 = "f:\\filebuildernew version\\builder c++\\setupex\\debug\\setupex.pdb" nocase
1 of them
YARA rule for detecting Newscaster binaries
This bot stores its configuration in the current user's TEMP directory, creating a subdirectory named "System". It stores a mutated instance of itself in the ProgramData directory, creating a subdirectory named "Windows Update". It names this instance "isass.exe" but with a capital "I" to appear as if it were 'lsass.exe', a critical part of the Windows operating system.
All instances appear to use the same mutex, "afOneCopyMutex", which also happens to be part of the above YARA rule (albeit in its encoded state).
Disassembly showing mutex name being decrypted and used by CreateMutexA
For more information on the malware's non-interactive behavior, see the Malwr analysis here.
Command and Control
This bot uses IRC for its command and control protocol. It also appears that a custom IRC daemon is being used, as it supplies very little information back to connecting bots.
I setup an IRC server and used the name "AF" for my client. The sample being used only accepts certain commands from other users with names starting with "AF" or "AS_". The IRC channel is configurable, and may be different for different samples. The connection to the IRC server is delayed after the start of the bot.
Disassembly of code section checking checking name of command's sender
The connection to the IRC server happens after attempting to disable the UAC in Windows, which would allow for easier privilege escalation.
From reverse engineering, we can see the accepted command, although a few do not perform any operations. The "VER" command obtains version information from the bot.
The "HI" command invokes a polite response.
The "!CMD" command executes commands.
The "EXEC" command gets the path of the executing binary.
The "!DSF" command will upload a selected file to a select IP and port.
An instance of netcat was able to capture the uploaded data. Here is a truncated hexdump from the receiving server.
A similar command, "!UP", uploads the selected file to an HTTP server.
I also used a netcat server for this. Here is the truncated hexdump of the information uploaded.
The "KILL" command shuts the bot down.
Cylance PROTECT is able to run in both a blocking and monitor mode. In this example we are running in monitor mode so we can gain more visibility into the threat. Running the application causes CylancePROTECT to discover 2 threats.
The 2 file detection is due to the second dropped file. In the PROTECT console we are able to see 2 active threats on the client, and both files detected. CylancePROTECT does not rely on detonation analysis, but it is able to provide this data in the console to assist in forensic analysis.
Drilling down via the console, we can see that after initial execution, the dropped file is running.
Clicking on the “endend.exe” allows us to drill in further on the specific sample.
By clicking the Detailed Threat Data button, the Cylance PROTECT Administrative console allows us to get further details on the threat: in this case, dropped files.
Detailed Data -> Network provides us a view into the hosts that the malware is attempting to communicate with.
The Cylance PROTECT console also allows us to see the File, Mutex and Registry keys that the sample attempts to generate or interact with during detonation, aligning to the research earlier in the blog post.
Using Cylance V, our detection and forensics tool, we can see that all 90 samples we were able to source are detected, and of that set at least 12 samples still without a solid AV industry detection.
The Newscaster campaign, while not technically advanced, was elaborate and extensive. It managed to go undetected from at least 2011, and some of the malware it produced continues to go undetected by signature based detection. The mathematical detection provided by Cylance, even with no prior knowledge of this malware, had no issue in detecting 100% of these samples.
Sample distribution with relations computed by ssdeep