Messages récents

Pages: [1] 2 3 4 5 6 7 8 ... 10
1
FLARE VM: The Windows Malware Analysis Distribution You’ve Always Needed!


  UPDATE (April 26, 2018): The web installer method to deploy FLARE
    VM is now deprecated. Please refer to the       href="https://github.com/fireeye/flare-vm/blob/master/README.md">README
      on the FLARE VM GitHub for the most up-to-date installation instructions.


 

As a reverse engineer on the FLARE Team I rely on a customized
  Virtual Machine (VM) to perform malware analysis. The Virtual Machine
  is a Windows installation with numerous tweaks and tools to aid my
  analysis. Unfortunately trying to maintain a custom VM like this is
  very laborious: tools frequently get out of date and it is hard to
  change or add new things. There is also a constant fear that if the VM
  gets corrupted it would be super tedious to replicate all of the
  settings and tools that I’ve built up over the years. To address this
  and many related challenges, I have developed a standardized (but
  easily customizable) Windows-based security distribution called FLARE VM.


 

FLARE VM is a freely available and open sourced Windows-based
  security distribution designed for reverse engineers, malware
  analysts, incident responders, forensicators, and penetration testers.
  Inspired by open-source Linux-based security distributions like Kali
  Linux, REMnux and others, FLARE VM delivers a fully configured
  platform with a comprehensive collection of Windows security tools
  such as debuggers, disassemblers, decompilers, static and dynamic
  analysis utilities, network analysis and manipulation, web assessment,
  exploitation, vulnerability assessment applications, and many others.


 

The distribution also includes the FLARE team’s public malware
  analysis tools such as FLOSS and FakeNet-NG.


 

How To Get It


 

You are expected to have an existing installation of Windows 7 or
  above. This allows you to choose the exact Windows version, patch
  level, architecture and virtualization environment yourself.


 

Once you have that available, you can quickly deploy the FLARE VM
  environment by visiting the following URL in Internet Explorer
  (other browsers are not going to work):


 


      href="http://boxstarter.org/package/url?https://raw.githubusercontent.com/fireeye/flare-vm/master/flarevm_malware.ps1" target="_blank">
      http://boxstarter.org/package/url?

    https://raw.githubusercontent.com/fireeye/flare-vm/master/flarevm_malware.ps1


 

After you navigate to the above URL in the Internet Explorer, you
  will be presented with a Boxstarter WebLauncher dialog. Select
  Run to continue the installation as illustrated in Figure 1.


 


 
 
 Figure 1: FLARE VM Installation


 

Following successful installation of Boxstarter WebLauncher, you
  will be presented with a console window and one more prompt to enter
  your Windows password as shown in Figure 2. Your Windows password is
  necessary to restart the machine several times during the installation
  without prompting you to login every time.


 


 
 
 Figure 2: Boxstarter Password Prompt


 

The rest of the process is fully automated, so prepare yourself a
  cup of coffee or tea. Depending on your connection speed, the initial
  installation takes about 30-40 minutes. Your machine will also reboot
  several times due to the numerous software installation’s
  requirements. During the deployment process, you will see installation
  logs of a number of packages.


 

Once the installation is complete, it is highly recommended to
  switch the Virtual Machine networking settings to Host-Only mode so
  that malware samples would not accidentally connect to the Internet or
  local network. Also, take a fresh virtual machine snapshot so this
  clean state is saved! The final FLARE VM installation should look like
  Figure 3.


 


 
 
 Figure 3: FLARE VM installation


 

NOTE: If you encounter a large number of error messages, try to
  simply restart the installation. All of the existing packages will be
  preserved and new packages will be installed.


 

Getting Started


 

The VM configuration and the included tools were either developed or
  carefully selected by the members of the FLARE team who have been
  reverse engineering malware, analyzing exploits and vulnerabilities,
  and teaching malware analysis classes for over a decade. All of the
  tools are organized in the directory structure shown in Figure 4.


 


 
  Figure 4: FLARE VM Tools


 

While we attempt to make the tools available as a shortcut in the
  FLARE folder, there are several available from command-line only.
  Please see the online documentation at   href="http://flarevm.info/">http://flarevm.info for the most up to
  date list.


 

Sample Analysis


 

In order to best illustrate how FLARE VM can assist in malware
  analysis tasks let’s perform a basic analysis on one of the samples we
  use in our Malware Analysis Crash Course.


 

First, let’s obtain some basic indicators by looking at the strings
  in the binary. For this exercise, we are going to run FLARE’s own
  FLOSS tool, which is a strings utility on steroids. Visit   href="http://flosseveryday.info/">http://flosseveryday.info for
  additional information about the tool. You can launch it by clicking
  on the FLOSS icon in the taskbar and running it against the sample as
  illustrated in Figure 5.


 


 
 
 Figure 5: Running FLOSS


 

Unfortunately, looking over the resulting strings in Figure 6 only
  one string really stands out and it is not clear how it is used.


 


 
 
 Figure 6: Strings Analysis


 

Let’s dig a bit more into the binary by opening up CFF Explorer in
  order to analyze sample’s imports, resources, and PE header structure.
  CFF Explorer and a number of other utilities are available in the
  FLARE folder that can be accessed from the Desktop or the Start menu
  as illustrated in Figure 7.


 


 
 
 Figure 7: Opening Utilities


 

While analyzing the PE header, there were several indicators that
  the binary contains a resource object with an additional payload. For
  example, the Import Address Table contained relevant Windows API calls
  such as LoadResource, FindResource and finally WinExec. Unfortunately,
  as you can see in Figure 8 the embedded payload “BIN” contains junk so
  it is likely encrypted.


 


 
 
 Figure 8: PE Resource


 

At this point, we could continue the static analysis or we could
  “cheat” a bit by switching over to basic dynamic analysis techniques.
  Let’s attempt to quickly gather basic indicators by using another
  FLARE tool called FakeNet-NG. FakeNet-NG is a dynamic network
  emulation tool which tricks malware into revealing its network
  functionality by presenting it with fake services such as DNS, HTTP,
  FTP, IRC and many others. Please visit   href="http://fakenet.info/">http://fakenet.info for additional
  information about the tool.


 

Also, let’s launch Procmon from Sysinternals Suite in order to
  monitor all of the File, Registry and Windows API activity as well.
  You can find both of these frequently used tools in the taskbar
  illustrated in Figure 9.


 


 
 
 Figure 9: Dynamic Analysis


 

After executing the sample with Administrator privileges, we quickly
  find excellent network- and host–based indicators. Figure 10 shows
  FakeNet-NG responding to malware’s attempt to communicate with
    evil.mandiant.com using HTTP protocol. Here we capture useful
  indicators such as a complete HTTP header, URL and a potentially
  unique User-Agent string. Also, notice that FakeNet-NG is capable of
  identifying the exact process communicating which is
  level1_payload.exe. This process name corresponds to the unique
  string that we have identified in the static analysis, but couldn’t
  understand how it was used.


 


 
  Figure 10: FakeNet-NG


 

Comparing our findings with the output of Procmon in Figure 11, we
  can confirm that the malware is indeed responsible for creating
    level1_payload.exe executable in the system32 folder.


 


 
 
 Figure 11: Procmon


 

As part of the malware analysis process, we could continue digging
  deeper by loading the sample in a disassembler and performing further
  analysis inside a debugger. However, I would not want to spoil this
  fun for our Malware Analysis Crash Course students by sharing all the
  answers here. That said all of the relevant tools to perform such
  analysis are already included in the distribution such as IDA Pro and
  Binary Ninja disassemblers, a nice collection of debuggers and several
  plugins, and many others to make your reverse engineering tasks as
  convenient as possible.


 

Have It Your Way


 

FLARE VM is a constantly growing and changing project. While we try
  to cover as many use-case scenarios as possible it is simply
  impossible due to the nature of the project. Luckily, FLARE VM is
  extremely easy to customize because it was built on top of the
  Chocolatey project. Chocolatey is a Windows-based package management
  system with thousands of packages. You can find the list here:   href="https://chocolatey.org/packages">https://chocolatey.org/packages.
  In addition to the public Chocolatey repository, FLARE VM uses our own
  FLARE repository which constantly growing and currently contains about
  40 packages.


 

What all this means is that if you want to quickly add some package,
  let’s say Firefox, you no longer have to navigate to the software
  developer’s website. Simply open up a console and type in the command
  in Figure 12 to automatically download and install any package:


 


 
 
 Figure 12: Installing packages


 

In a few short moments, Firefox icon is going to appear on your
  Desktop with no user interaction necessary.


 

Staying up to date


 

As I’ve mentioned in the beginning, one of the hardest challenges of
  unmanaged Virtual Machine is trying to keep all the tools up to date.
  FLARE VM solves this problem. You can completely update the entire
  system by simply running the command in Figure 13.


 


 
 
 Figure 13: Staying up to date


 

If any of the installed packages have newer versions, they will be
  automatically downloaded and installed.


 


  NOTE: Don’t forget to take another clean snapshot of an updated
    system and set networking back to Host-Only.


 

Conclusion


 

I hope you enjoy this new free tool and will adopt it as another
  trusted resource to perform reverse engineering and malware analysis
  tasks. Next time you need to set up a new malware analysis
  environment, try out FLARE VM!


 

In these few pages, we could only scratch the surface of everything
  that FLARE VM is capable of; however, feel free to leave your
  comments, tool requests, and bugs on our Github issues page here:   href="https://github.com/fireeye/flare-vm">https://github.com/fireeye/flare-vm
  or http://flarevm.info/.


Source: FLARE VM: The Windows Malware Analysis Distribution You’ve Always Needed!
2
News / [FireEye]Analyzing the Malware Analysts – Inside FireEye’s FLARE Team
« Dernier message par igor51 le Aujourd'hui à 22:00:26 »
Analyzing the Malware Analysts – Inside FireEye’s FLARE Team


      src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/podcast/podcasticon.png"
  class="float-left" />At the Black Hat USA 2016 conference in Las Vegas
  last week, I was fortunate to sit down with Michael Sikorski,
  Director, FireEye Labs Advanced Reverse Engineering (FLARE) Team.


 

During our conversation we discussed the origin of the FLARE team,
  what it takes to analyze malware, Michael’s book “    href="https://www.amazon.com/Practical-Malware-Analysis-Hands-Dissecting/dp/1593272901">Practical
    Malware Analysis: The Hands-On Guide to Dissecting Malicious
  Software,” and the latest open source freeware tools   href="https://github.com/fireeye/flare-floss">FLOSS and FakeNet-NG.


 

Listen to the full podcast here.


Source: Analyzing the Malware Analysts – Inside FireEye’s FLARE Team
3
Internet & Réseau / Re : Re : Plus de wifi
« Dernier message par BiggieMacDeluxe le Aujourd'hui à 21:37:44 »
Citer
Avec le telephone oui ( enfin je branche mon téléphone au PC )
Citer
Le pc est branché au téléphone avec un câble , ou en wifi ?

Le téléphone et branché en câble au pc
4
Internet & Réseau / Re : Plus de wifi
« Dernier message par Longaripa le Aujourd'hui à 21:15:56 »
Citer
Avec le telephone oui ( enfin je branche mon téléphone au PC )
Citer
Le pc est branché au téléphone avec un câble , ou en wifi ?
5
Internet & Réseau / Re : Re : Re : Plus de wifi
« Dernier message par BiggieMacDeluxe le Aujourd'hui à 20:15:36 »
Bonjour

Si je puis me permettre une petite incursion :

Citation de: BiggieMacDeluxe
la j'ai branché mon téléphone en partage de connexion çà fonction

Ca fonctionne avec un telephone en partage de connexion ?

Et en se mettant à coté de la box ,à 1 metre par exemple ,  le wifi fonctionne ?

Avec le telephone oui ( enfin je branche mon téléphone au PC )
Bien là le pc et même pas à 1 mètre déjà
6
News / [Sophos]Know what Instagram knows – here’s how you download your data
« Dernier message par igor51 le Aujourd'hui à 20:00:34 »
Know what Instagram knows – here’s how you download your data

Thank you GDPR.
Source: Know what Instagram knows – here’s how you download your data
7
News / [FireEye]Establishing a Baseline for Remote Desktop Protocol
« Dernier message par igor51 le Aujourd'hui à 19:00:43 »
Establishing a Baseline for Remote Desktop Protocol

For IT staff and Windows power users, Microsoft Terminal Services
  Remote Desktop Protocol (RDP) is a beneficial tool that allows for the
  interactive use or administration of a remote Windows system.
  However, Mandiant consultants have also observed threat actors using
  RDP, with compromised domain credentials, to move laterally across
  networks with limited segmentation.


 

To understand how threat actors take advantage of RDP, consider the
  following example (and Figure 1):


 
  1. A staff member from the
        HR department working on his or her desktop inadvertently installs a
        malicious backdoor by interacting with a phishing email.

  2.    
  3. The backdoor malware runs password stealing functionality from
          Mimikatz to
        obtain credentials stored in memory for any user accounts that have
        accessed the system.
  4. The backdoor creates a network tunnel
        to an attacker’s command and control (C2) server.
  5. The
        attacker logs on to the HR employee’s system with RDP through the
        network tunnel by using the compromised credentials.
  6. In
        pursuit of compromising financial information, the attacker uses
        Active Directory enumeration commands to identify domain-based
        systems used by the finance department.
  7. The attacker uses
        RDP and the compromised HR employee account to connect to a system
        in the finance department.
  8. The attacker uses Mimikatz to
        extract credentials on the finance system, resulting in access to 
        cached passwords for the finance employee who uses the system and an
        IT administrator who recently logged onto the system for
      troubleshooting.
  9. Using RDP, the attacker leverages the HR
        employee’s account, the finance employee’s account, and the IT
        administrator employee’s account to log onto additional systems in
        the environment.
  10. The attacker stages data onto the HR
        employee’s system.
  11. The attacker steals the files via the
        built-in RDP copy and paste functionality.

 


 
 
 Figure 1: Example of a compromise that
    uses RDP for lateral movement


 

A best practice used to identify this type of activity is network
  baselining. To do this, an organization must first understand what is
  normal behavior for their specific environment, and then begin to
  configure detections based on unexpected patterns. Sample questions
  that can help determine practical detection techniques based on the
  aforementioned scenario include:


 
  1. Do our HR and/or finance
        employees typically use RDP?
  2. Do any of our HR employees RDP
        to a destination system in finance?
  3. Do any of our HR and/or
        finance employees RDP to multiple destination systems?
  4. Are
        the systems in our HR and/or finance departments used as source
        systems for RDP?
  5. Do our IT administrator accounts RDP from
        a source system that is not part of an IT network segment?

  6.    
  7. Do any of our critical servers have logons from source systems
        that are not part of an IT network segment?
  8. Do any of our
        critical servers have RDP logons sourced from user accounts that are
        correlated to any of our HR and/or finance personnel?
  9. Is it
        expected for a single user account to initiate RDP connections from
        multiple source systems?

 

While it can take time to develop a customized process to baseline
  the scope of user accounts, source systems – and destination systems
  that leverage RDP in your organization’s environment – normalizing and
  reviewing this data will empower your staff with a deeper
  understanding of user account behavior, and the ability to detect
  unexpected activity to quickly begin investigating and triaging.


 

Tracking RDP through Event Logs


 

One first step and important resource for identifying your network’s
  typical behavior is through the use of event logs. RDP logons can
  generate file, event log, and registry artifacts on both the source
  and destination systems involved. Page 42 of JPCERT’s reference, “    href="https://www.jpcert.or.jp/english/pub/sr/20170612ac-ir_research_en.pdf">Detecting
    Lateral Movement through Tracking Event Logs,” details many
  artifacts that investigators may find on source and destination systems.


 

For the purpose of scalability, our baselining approach will focus
  on three high-fidelity logon events recorded on a destination system:


 

  •     EID 21 and EID 25 within the
        “TerminalServices-LocalSessionManager” log, commonly located at
      “%systemroot%\Windows\System32\winevt\Logs\Microsoft-TerminalServices-LocalSessionmanager%3Operational.evtx”

  •           href="https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4624">EID
        4624 entries of Type 10 logons within the “Security” log,
        commonly located at
      “%systemroot%\Windows\System32\winevt\Logs\Security.evtx”

 

The EID 21 entry shown in Figure 2 is created on a destination
  system when a successful interactive local or remote logon event occurs.


 


 
 
 Figure 2: EID 21 Example Structure


 

The EID 25 entry shown in Figure 3 is created on a destination
  system that has been reconnected from a system that previously
  established an RDP session that was not terminated through a proper
  user logout. For example, closing the RDP window (which would generate
    EID 24), as opposed to logging off through the start menu
  (which would generate EID 23).


 


 
 
 Figure 3: EID 25 Example Structure


 

The EID 4624 entry is created on a destination system when a logon
  of any type occurs. For evidence of RDP authentication, we will focus
  on EID 4624 entries with with Logon Type 10 as shown in Figure 4,
  which correspond to RDP authentications.


 


 
 
 Figure 4: Type 10 EID 4624 Example Structure


 

These event log entries provide evidence of a successful RDP
  authentication from one system to another. For most security teams to
  collect this event log data, the logs must either be forwarded to an
  aggregation platform, such as a security information and event
  management (SIEM) platform, or collected using a forensic acquisition
  utility such as     href="https://www.fireeye.com/products/hx-endpoint-security-products.html">FireEye’s
    Endpoint Security (HX) appliance. Once extracted, the data must
  be processed and stacked for frequency analysis. The scope of this
  post is to generate metrics based on unique user accounts, source
  systems, and destination systems.


 

For both EID 21 and EID 25, the user account and source system are
  captured in the event log strings, while the destination system is the
  system that recorded the event. Note that the “Source Network Address”
  recorded within the log may be either a hostname or an IP address.
  Your data processor may benefit from mapping IP addresses and
  hostnames together, while keeping Dynamic Host Configuration Protocol
  (DHCP) leases in mind. Understanding which systems correlate to
  specific user accounts or business units will greatly benefit the
  analysis of the processed results. If your organization does not track
  this information, you should request for this documentation to be
  created or captured within an asset management database for automated correlation.


 

Identifying Inconsistencies


 

Once RDP activity is baselined across your environment via the
  analysis of event logs, security analysts can then begin to identify
  RDP activity that deviates from business requirements and normalized
  patterns. Keep in mind that distinguishing between legitimate and
  anomalous RDP activity may take time.


 

Not only will DHCP logs prove useful when mapping IP address to
  hostnames, but documentation that associates systems and user accounts
  with specific business units can also help with reviewing and
  correlating observed RDP activity for suspicious or benign behavior.
  Any RDP activity inconsistent with expected business practices should
  be investigated. Additionally, RDP logons confirmed as benign should
  be noted in the baseline for future investigators.


 

Leveraging Metrics


 

By using SIEM correlation techniques, analysts can stack RDP
  activity by account, source system, and destination system, to
  pinpoint the number/count of the following metrics-related elements,
  which will deepen the security staff’s understanding of RDP activity
  in your network:


 
  • source systems per user
      account
  • destination systems per user account
  • user
        accounts per each source system to destination system path

  •    
  • user accounts per each source systems
  • user accounts per
        each destination system
  • source system to destination system
        paths per user account
  • total RDP logons per user
      account
  • total RDP logons per source system
  • total RDP
        logons per destination system
  • destination systems for each
        source system
  • source systems for each destination
      systems

 

This list of metrics is not exhaustive and can be expanded by
  including timestamp metadata if desired.


 

Recommendations


 

While baselining RDP activity may not readily identify threat actors
  who do not utilize this technique, or who take extra steps to blend in
  with legitimate user activity, it will continually help analysts
  better understand what normal behavior looks like in their specific
  environments – and could ultimately identify anomalies or potential
  indicators of unauthorized activity.


 

The following recommendations can help maximize the effectiveness of
  your RDP baselining exercises, while also reducing the opportunities
  for RDP to be leveraged for malicious actors within your environment:


 
  1. Disable the remote
        desktop service on end-user workstations and laptops, as well as
        systems where the service is not required for remote
      connectivity.
  2. Where connectivity using RDP is required,
        implement a combination of host and network-based controls to
        enforce that RDP connectivity must be initiated from specific jump
        boxes and centralized management servers for remote connection to
      endpoints.
  3. Host-based firewall rules that explicitly deny
        inbound RDP connections provide enhanced protections, especially for
        remote users that may utilize their system at locations outside of
        an organization’s managed infrastructure. Use host-based firewall
        rules to:
    • Deny inbound RDP connections by default.

    •        
    • When required, explicitly permit inbound RDP only from IP
              addresses correlating to authorized jump boxes.

  4.    
  5. Employ the “Deny log on through Remote Desktop Services”
        security setting to prevent standard users from connecting to
        endpoints using RDP.
    • Ideally, this setting should also deny
              RDP access for privileged accounts (e.g. domain administrators,
              service accounts) on endpoints, as these types of accounts are
              commonly leveraged by attackers for laterally moving to
              sensitive systems within an environment.

  6.    
  7. Prevent the use of RDP using local accounts by:

             
    • Installing         href="http://support.microsoft.com/kb/2871997">KB2871997,
              and adding the SID “S-1-5-114: NT AUTHORITY\Local account and
              member of Administrators group” to the “Deny log on through
              Remote Desktop Services” security setting on endpoints. This can
              be accomplished by using Group Policy.
    • Randomizing
              passwords for the built-in local administrator account on
              endpoints with a solution such as           href="https://technet.microsoft.com/en-us/mt227395.aspx">Microsoft
            LAPS.
  8. Ensure that EID 21, EID 23, EID 24,
        and EID 25 within the “TerminalServices LocalSessionManager
        Operational” event log are being captured and forwarded to a SIEM or
        log aggregator.
  9. Confirm that EID 4624 within the “Security”
        event log is being captured and forwarded to a SIEM or log
      aggregator.
  10. Increase the maximum size of the
        “TerminalServices LocalSessionManager Operational” and event log to
        at least 500 MB. This can be accomplished by using Group Policy
        Preferences (GPP) to modify the “MaxSize” registry value within the
        registry key
        “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-TerminalServices-LocalSessionManager/Operational”
        on endpoints.
  11. Increase the maximum size of the “Security”
        event log to at least 1 GB.
  12. Monitor for evidence of the
        “Security” and “TerminalServices LocalSessionManager Operational”
        event logs being cleared (      href="https://www.sans.org/summit-archives/file/summit-archive-1498249764.pdf">EID
      1102).
  13. Create and regularly update documentation that
        maps user accounts and hostnames to business units.
  14. Ensure
        DHCP logs are archived and easily accessible to correlate source
        system IP addresses with their hostname at the time of a logon
      event.

Source: Establishing a Baseline for Remote Desktop Protocol
8
News / [Sophos]20 years ago today! What we can learn from the CIH virus…
« Dernier message par igor51 le Aujourd'hui à 19:00:27 »
20 years ago today! What we can learn from the CIH virus…

The 20-year-old CIH virus, aka "Chernobyl", isn't just a museum curiosity. It still has plenty of lessons to teach us today.
Source: 20 years ago today! What we can learn from the CIH virus…
9
Internet & Réseau / Re : Re : Plus de wifi
« Dernier message par BiggieMacDeluxe le Aujourd'hui à 18:56:01 »
Bonjour

Si je puis me permettre une petite incursion :

Citation de: BiggieMacDeluxe
la j'ai branché mon téléphone en partage de connexion çà fonction

Ca fonctionne avec un telephone en partage de connexion ?

Et en se mettant à coté de la box ,à 1 metre par exemple ,  le wifi fonctionne ?

Avec le telephone oui
Bien là le pc et même pas à 1 mètre déjà
10
Internet & Réseau / Re : Plus de wifi
« Dernier message par Longaripa le Aujourd'hui à 18:07:39 »
Bonjour

Si je puis me permettre une petite incursion :

Citation de: BiggieMacDeluxe
la j'ai branché mon téléphone en partage de connexion çà fonction

Ca fonctionne avec un telephone en partage de connexion ?

Et en se mettant à coté de la box ,à 1 metre par exemple ,  le wifi fonctionne ?
Pages: [1] 2 3 4 5 6 7 8 ... 10