Posté par: igor51 le mars 23, 2017, 21:00:54
Loved by administrators, Windows PowerShell enables users to
effectively perform automation and administrative tasks on local and
remote systems. However, its power, ease of use, and widespread use
has also made it attractive to attackers.
Researchers first began demonstrating attacks involving PowerShell
around 2010, and they were crafting more sophisticated PowerShell
attack methodologies and toolkits by late 2011. Gradually, PowerShell
started to show up in malware campaigns, although at the time it was
only observed being used to complete some steps in the attack cycle.
We’ve been investigating PowerShell attacks for years and you can
href="/content/fireeye-www/en_US/blog/threat-research/2015/10/macros_galore.html">read
more about that here.
We recently came across some data stealing campaigns in which nearly
all steps of the attack cycle involved simple yet efficient PowerShell commands.
One of these – a campaign targeting credentials – involves a
legitimate looking Russian domain website leading to a well-written
PowerShell script. Another campaign, also targeting credentials,
involves an RTF file with German language content that initiates a
series of PowerShell commands. In both campaigns, protective and
evasive steps are taken at points throughout the attack cycle.
Case Study I: A Russia-based data stealing campaign
We observed a Windows executable file in the wild downloading a
PowerShell script from a legitimate-looking Russian domain website.
The homepage of the website discusses martial arts, but it also hosts
the PowerShell script. On execution of the EXE file, a PowerShell
command to download another PS1 (PowerShell) script is initiated. The
usage of –hidden switch ensures that the execution of PowerShell
script is not obvious to the victim in the form of PowerShell window.
Similarly the execution policy is set as unrestricted to make sure the
script runs with desired access.
Figure 1: Command to download malicious
PowerShell script in hidden and unrestricted
mode.
Password stealing
On accessing the “74.ps1” hosted live on the website, we observed a
well-written PowerShell script with clear intent to steal data. The
script copies files from certain locations of the victims’ file system
that are expected to hold user credentials, as seen below. For
example, Figure 2 shows the intent to copy “Login Data” file from
Chrome folder, which contains the usernames and encrypted passwords of
websites logged in on the Chrome browser.
Figure 2: Command to copy known credential files
from victims’ system
System survey
The script also obtains system metadata (i.e., the victim's
username, firewall status, and configuration details such as RAM and
hard disk size), which is converted to an HTML page as shown in Figure 3.
Figure 3: Command to dump system information
metadata into an HTML file
Data extraction
The malware compresses all stolen data into a ZIP archive, as shown
in Figure 4.
Figure 4: Compressing stolen data to an archive
Once zipped, the stolen data is ready to be sent to the malware
author via SMTP-related commands. To send it, an email ID and password
of the malware author is required to be passed as parameters. These
credentials were visible to us while analyzing the malicious script.
Figure 5: Command to send stolen data to
malware author via email
When the malware is finally run, the malware generates an encrypted
report titled “My test report.” Reviewing the report, we observed that
the data is encrypted, as seen in Figure 6.
Figure 6: A section of the encrypted stolen information
Decryption of stolen data
As an extra layer of protection, the malware author had implemented
the RC4 algorithm in the PowerShell script itself and encrypted the
whole ZIP file, as seen in Figure 7.
Figure 7: RC4 algorithm implemented within PowerShell
Since the malware encrypts the data and does not use any public key
infrastructure, it has to have the RC4 key visible. This can be seen
in Figure 8, and ultimately it renders the extra security measure useless.
Figure 8: RC4 key used by the malware
author passed as parameter in the script
Analyzing the Data Collected
We used the hard-coded key to decrypt the ZIP file and then we
unzipped the information the malware collected, the results of which
are shown in Figure 9.
Figure 9: Data collected after decryption and unzipping
The “chrome” file contains information from Google Chrome login
table. The “CompInfo” HTML file contained metadata of the victim as
shown in Figure 10.
Figure 10: HTML containing stolen system information
The CREDHIST file, a component of credential manager, was also
observed among the stolen data. The CREDHIST file contains
representation of users’ recent and old account credentials.
Figure 11: Stolen credhist file
Case Study II: Germany / Austria-based data
stealing campaign
We observed an RTF file with German language content circulating in
Germany and Austria. It was found that the RTF file initiates a
drive-by download, leading to execution of a payload that initiates a
series of PowerShell commands. In this case, extra care is taken care
by a PowerShell command to make sure that virtualization is detected.
VM detection
As shown in Figure 12, a list of all running processes is retrieved
via Get-Process. Among them, the malware checks for services related
to VirtualBox, VMware, and Parallels. If found, the output will be
printed on the console.
Figure 12: PowerShell script calculating the
count of virtualization related processes
If this count is greater than zero, the malware is running in a
virtualized environment. However, mere output on the console does not
help the malware author – they will need to use this data. Using
CONOUT parameter, the information is passed on to the executable.
Depending on this output, the campaign will continue or abort.
Infection rate 29,000 and counting
The malware adds the number of attacks by visiting a counter website.
Figure 13: Script tracking infection count
So far, it has been visited 29,245 times, but this does not
necessarily mean that 29,245 systems have been infected – some visits
could have been from cybersecurity researchers.
Figure 14: Infection counter
After a virtualization check and tracking, the malware steals data.
The malware uses PowerShell to iterate and dump a number of possible
locations where cookies are stored to the text file, ftshvc.txt.
Command to steal data
Figure 15: Stolen data dumped in a text file
Prioritizing stolen data
However, the author is not interested in all the dumped data. They
prioritize the stolen data by searching for specific strings
and enabling a counter for it. Within the dumped stolen data, the
search for credentials includes everything from Facebook to banking
information sites such as “bankaustria.at” and “credit-suisse.com” (a
Swiss banking site). The prioritization of stolen data command is
shown in Figure 16.
Figure 16: Script calculates count of certain
specific stolen data
Making way for new payload
After completing the data theft, the PowerShell script makes way for
a new payload: Dofoil (yet again, a PowerShell command is used to
download a file from the malware site and run it via DownloadFile and
ShellExecute commands). This effectively closes the PowerShell data
stealing cycle and introduces a new payload, which will connect to the
command and control (CnC) server and perform other malicious commands.
Figure 17: Script to download and execute new payload
More Evasion Techniques
In addition to anti-vm tricks, the malware uses PowerShell features
such as encoding and quote obfuscation were also used.
For example, all three commands shown below will launch Notepad.
Figure 18: Three different ways to open notepad
via PowerShell
Just like a normal command line terminal, PS terminal has no issues
when strings are broken into quotes. As with command prompt, PS will
also launch Notepad when “note” ”pad” is typed.
Additionally, PowerShell provides a –enc (Encoding Command Switch)
that can enable the user/attacker to write PowerShell commands in Base64.
Evasion via encoding
The following is the PowerShell command observed by a separate
malware, which uses a –enc switch to hide the activity of first
calling system sleep (another evasion technique) and then connecting
to a desired link.
Figure 19: Encoded PowerShell script execution
in hidden mode
Real PowerShell command after Base64 decryption.
Figure 20: Script after decoding can be observed
to call sleep and connect to a link
Evasion via quote obfuscation
In the following case, when a Word macro executes, it initiates a
PowerShell script drop that is supposed to launch a VBscript.
The malware author breaks down the extension as “v” + “bs”. The same
is passed in command line parameters, which is another bypass attempt
by breaking the file extension into quotes.
Figure 21: Quote obfuscation to evade plaintext
string detection
The encoding and obfuscation evasion tricks were also observed in
document files attached to phishing messages which had embedded
macros, that also used PowerShell. There has been an increase in
spreading documents containing embedded malicious macros, and more on
that can be read here.
Conclusion
PowerShell is now often used in attacks. The use of PowerShell,
especially in a corporate environment, should be well regulated and
monitored with enhanced logging. Execution of encoded and obfuscated
commands requires an extra degree of observance. Due to PowerShell’s
ability to encode and obfuscate data, security teams should be aware
of how PowerShell can be maliciously used and cultivate expertise
investigating PowerShell attacks.
The evasion techniques we discussed are not able to bypass FireEye
appliances, and FireEye provides detection for various stages of such campaigns.
Reference
[1] https://www.fireeye.com/blog/threat-research/2015/10/macros_galore.html
Source: Uncovering Active PowerShell Data Stealing Campaigns (http://)