Security-X

Forum Security-X => News => Discussion démarrée par: igor51 le avril 03, 2017, 16:01:15

Titre: [FireEye]Dissecting One of APT29’s Fileless WMI and PowerShell Backdoors (POSHSPY)
Posté par: igor51 le avril 03, 2017, 16:01:15
Dissecting One of APT29’s Fileless WMI and PowerShell Backdoors (POSHSPY)

[html]

Mandiant has observed APT29 using a stealthy backdoor that we call
  POSHSPY. POSHSPY leverages two of the tools the group frequently uses:
  PowerShell and Windows Management Instrumentation (WMI). In the
  investigations Mandiant has conducted, it appeared that APT29 deployed
  POSHSPY as a secondary backdoor for use if they lost access to their
  primary backdoors.


 

POSHSPY makes the most of using built-in Windows features –
  so-called “living off the land” – to make an especially stealthy
  backdoor. POSHSPY's use of WMI to both store and persist the backdoor
  code makes it nearly invisible to anyone not familiar with the
  intricacies of WMI. Its use of a PowerShell payload means that only
  legitimate system processes are utilized and that the malicious code
  execution can only be identified through     href="https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html">enhanced
  logging or in memory. The backdoor's infrequent beaconing, traffic
  obfuscation, extensive encryption and use of geographically local,
  legitimate websites for command and control (C2) make identification
  of its network traffic difficult. Every aspect of POSHSPY is efficient
  and covert.


 

Mandiant initially identified an early variant of the POSHSPY
  backdoor deployed as PowerShell scripts during an incident response
  engagement in 2015. Later in that same engagement, the attacker
  updated the deployment of the backdoor to use WMI for storage and
  persistence. Mandiant has since identified POSHSPY in several other
  environments compromised by APT29 over the past two years.


 

We first discussed APT29’s use of this backdoor as part of our “No
  Easy Breach” talk. For additional details on how we first identified
  this backdoor, and the epic investigation it was part of, see the   href="https://www.slideshare.net/MatthewDunwoody1/no-easy-breach-derby-con-2016">slides
  and presentation.


 

Windows Management Instrumentation


 

WMI is an administrative framework that is built into every version
  of Windows since 2000. WMI provides many administrative capabilities
  on local and remote systems, including querying system information,
  starting and stopping processes, and setting conditional triggers. WMI
  can be accessed using a variety of tools, including the Windows WMI
  Command-line (wmic.exe), or through APIs accessible to programming and
  scripting languages such as PowerShell. Windows system WMI data is
  stored in the WMI common information model (CIM) repository, which
  consists of several files in the   class="code">System32\wbem\Repository directory.


 

WMI classes are the primary structure within WMI. WMI classes can
  contain methods (code) and properties (data). Users with sufficient
  system-level privileges can define custom classes or extend the
  functionality of the many default classes.


 

WMI permanent event subscriptions can be used to trigger actions
  when specified conditions are met. Attackers often use this
  functionality to persist the execution of backdoors at system start
  up. Subscriptions consist of three core WMI classes: a Filter, a
  Consumer, and a FilterToConsumerBinding. WMI Consumers specify an
  action to be performed, including executing a command, running a
  script, adding an entry to a log, or sending an email. WMI Filters
  define conditions that will trigger a Consumer, including system
  startup, the execution of a program, the passing of a specified time
  and many others. A FilterToConsumerBinding associates Consumers to
  Filters. Creating a WMI permanent event subscription requires
  administrative privileges on a system.


 

We have observed APT29 use WMI to persist a backdoor and also store
  the PowerShell backdoor code. To store the code, APT29 created a new
  WMI class and added a text property to it in order to store a string
  value. APT29 wrote the encrypted and base64-encoded PowerShell
  backdoor code into that property.


 

APT29 then created a WMI event subscription in order to execute the
  backdoor. The subscription was configured to run a PowerShell command
  that read, decrypted, and executed the backdoor code directly from the
  new WMI property. This allowed them to install a persistent backdoor
  without leaving any artifacts on the system’s hard drive, outside of
  the WMI repository. This “fileless” backdoor methodology made the
  identification of the backdoor much more difficult using standard host
  analysis techniques.


 

POSHSPY WMI Component


 

The WMI component of the POSHSPY backdoor leverages a Filter to
  execute the PowerShell component of the backdoor on a regular basis.
  In one instance, APT29 created a Filter named   class="code">BfeOnServiceStartTypeChange (Figure 1), which they
  configured to execute every Monday, Tuesday, Thursday, Friday, and
  Saturday at 11:33 am local time.