IT News

There are many reasons why we want a bug fixed as soon as we can, but there are also plenty of reasons why doing it “right now” is not an option. This phenomenon starts at the side of the developers. The average time to fix a bug seems to vary depending on the platform the bug was found in. What is one group doing better and can the others take lessons from that? Or is it something we have to take as it comes?

“Bug-fixing time” refers to the time required to fix known bugs. So, on a per bug basis it is the time between being made aware of an existing bug and issuing a fix for the bug. The ability to better understand and predict bug-fixing time can help a project team better estimate software maintenance efforts and better manage software projects.

Reasons to fix ASAP

There are some very obvious reasons why we want to push and install bug fixes as soon as possible.

• Improved security by fixing the vulnerability.
• Even if a vulnerability is found by a researcher taking the high road of responsible disclosure, once the cat is out of the bag, there is a good chance others will be able to duplicate the researcher’s effort. This could result in a zero-day vulnerability.
• When you are working on a new version, a critical bug in the old version is holding you back as long as you don’t know how to fix it.
• If the published timeline shows it has taken months to fix a bug it reflects badly on your company, and could lead customers to question whether you care about security.

In general, you can say that the bug-fixing time is an important factor for bug related analysis, such as measuring software quality. Having your software considered to be “buggy” does not helps sales in any way. But situations may arise when you need to prioritize what needs to be fixed first.

Differences in platform

Last month, the Project Zero team at Google looked at fixed bugs that were reported between January 2019 and December 2021. During this period, Project Zero reported 376 issues to vendors under their standard 90-day deadline.

When reading the data, it is important to note that the number of issues is too small and not chosen randomly enough to give a full picture, but it gives you an idea at least.

Vendor	Total bugs	Fixed by day 90	Fixed during grace period	Exceeded deadline and grace period	Avg days to fix
Apple	84	73 (87%)	7 (8%)	4 (5%)	69
Microsoft	80	61 (76%)	15 (19%)	4 (5%)	83
Google	56	53 (95%)	2 (4%)	1 (2%)	44
Linux	25	24 (96%)	0 (0%)	1 (4%)	25
Adobe	19	15 (79%)	4 (21%)	0 (0%)	65
Mozilla	10	9 (90%)	1 (10%)	0 (0%)	46
Samsung	10	8 (80%)	2 (20%)	0 (0%)	72

Overall, the data show that almost all of the big vendors here are coming in under 90 days, on average.

Complaints from bug bounty hunters

At this point it should be pointed out that bugs reported by the Project Zero team are reported to vendors directly and will be taken very seriously by the vendors.

Individual bounty hunters, however, have been complaining about getting their bugs accepted. For example, in January we saw CVE-2022-22587, a vulnerability in Apple’s IOMobileFrameBuffer, where a malicious app could execute random code with kernel privileges. This vulnerability ended up being a zero-day vulnerability that was exploited in the wild after one of them posted a Proof-of-Concept (PoC).

Many researchers that don’t want to report to vendors directly make use of the Zero-Day-Initiative (ZDI). The ZDI was created to encourage the reporting of zero-day vulnerabilities privately to the affected vendors by financially rewarding researchers, although there have been complaints from researchers that they didn’t feel they were taken seriously by the ZDI.

The next step

So, yes, it’s important to fix vulnerabilities ASAP, but why does it take so long sometimes before these fixes and patches get installed?

According to recent podcast guest Jess Dodson, the problem of patching isn’t just a problem of resources—time, staffing, funding—but also of mindset. For some organizations, refusing to patch almost brings with it a bizarre sense of pride, Dodson said.

This video cannot be displayed because your Functional Cookies are currently disabled.

To enable them, please visit our privacy policy and search for the Cookies section. Select “Click Here” to open the Privacy Preference Center and select “Functional Cookies” in the menu. You can switch the tab back to “Active” or disable by moving the tab to “Inactive.” Click “Save Settings.”

Finally, even if you are not a Federal Civilian Executive Branch (FCEB) agency that needs to follow the Binding Operation Directive 22-01, the CISA list known as the Known Exploited Vulnerabilities Catalog can act as a good guideline for your patch management strategy. This catalog provides FCEB agencies with a list of vulnerabilities that are known to be exploited in the wild and gives the agencies a due date by when the vulnerability needs to be patched in their organization.

The post The struggle to reduce bug-fixing time is real appeared first on Malwarebytes Labs.

Mozilla has announced it has fixed security vulnerabilities in Firefox 97.0.2, Firefox ESR 91.6.1, Firefox for Android 97.3.0, and Focus 97.3.0. Users should install the out-of-band security update as soon as possible, since it is designed to apply a fix for two vulnerabilities that are known to be exploited in the wild.

Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services). These are the CVEs you need to know:

CVE-2022-26485

The vulnerability listed under CVE-2022-26485 can be triggered by removing an XSLT parameter during processing which could lead to an exploitable use-after-free.

In the Extensible Markup Language (XML) the <xsl:param> element is used to declare a local or global parameter. XML is a markup language much like HTML and XML was designed to store and transport data. The XSLT <xsl:param> and <xsl:with-param> elements allow you to pass parameters to a template.

Use-after-free (UAF) is a vulnerability caused by incorrect use of dynamic memory during a program’s operation. If after freeing a memory location, a program does not clear the pointer to that memory, an attacker can use the error to manipulate the program.

CVE-2022-26486

The vulnerability listed under CVE-2022-26486 can be exploited by sending an unexpected message in the WebGPU IPC framework which in turn could lead to a use-after-free and exploitable sandbox escape.

WebGPU exposes an API for performing operations, such as rendering and computation, on a Graphics Processing Unit. Interprocess communication (IPC) refers specifically to the mechanisms an operating system provides to allow the processes to manage shared data. WebGPU sees physical Graphics Processing Units (GPUs) hardware as GPUAdapters. It provides a connection which manages resources, and the device’s GPUQueues, which execute commands.

The idea of browser sandboxes is to shield the system from the malware attacking the browser. They do this by containing any malicious code that originates from visiting a website, in the sandbox part of the browser. As soon as the sandbox is closed, everything inside it is erased, including the malicious code.

So, the ability to escape the application’s security sandbox is valuable to an attacker as it can be chained with other vulnerabilities to take over the target system. Since these two vulnerabilities were reported by the same researchers, it seems highly likely they were used together in online attacks for exactly that purpose.

Critical

These vulnerabilities are rated critical and that is very likely because they are being exploited in the wild. From the descriptions, we would deduce that these bugs are critical because they could allow a remote attacker to execute almost any command, including the downloading of malware to provide further access to the device. So, there are compelling reasons to apply this update as soon as possible

Mitigation

The affected Mozilla products need to be updated to the versions listed below.

• Firefox 97.0.2
• Firefox ESR 91.6.1
• Firefox for Android 97.3
• Focus 97.3
• Thunderbird 91.6.2

Under normal circumstances, updates will be applied without user intervention. You can check for the version number in the products’ menu under Help > About

Should you not be using the latest version for some reason, e.g. automatic updates are disabled, then this screen will inform you that a new version is available and will start downloading it.

When it’s done, all you need to do is restart the application to apply the update.

Stay safe, everyone!

The post Update now! Mozilla patches two actively exploited vulnerabilities appeared first on Malwarebytes Labs.

Recently, the Malwarebytes Threat Intelligence Team found a Formbook campaign targeting oil and gas companies. The campaign was delivered by a targeted email that contained two attachments, one is a pdf file and the other an Excel document.

Formbook

The Formbook malware is an information stealer that is in use by many threat actors. Formbook has been around since 2016 and is readily available on dark web market places.

The email

The email pretends to be from Saudi Aramco, a Saudi Arabian public petroleum and natural gas company, and one of the largest companies in the world by revenue. The email asks the receiver to provide an offer for refinery renovations that requires a swift response.

It read:

Dear Sir,

Warm Greetings From Saudi Aramco.

We request you to furnish your best, complete, exclusive and competitive techno-commercial offer to our esteemed company for the supply of below mentioned item(s) on or before 10-March-2022.

Your offer should conform to all the specifications (FIT, FORM and FUNCTION) mentioned in our requisition including the following information:

1. Manufacturer's Name and Country of Origin.
2. Latest Delivery Date and Shipment Terms.
3. Estimated Weight / Volume or Dimensions of the quoted item(s) / Final Package.
4. Cost of attestation of documents from chamber of commerce shall be borne by the Supplier.
5. Warranty Period.
6. Product Specifications / Data Sheet, Drawings, and Catalog (if available)
7. Payment Terms
8. Partial Order acceptable or not acceptable.
9. Offer Validity: 90 Days. 

END USER: SEC (Saudi Arabian Oil Company)
End Destination : Saudi Arabia 

If you need any more information, please don't hesitate to contact us. 

Please acknowledge the email along with the attachment (download below) and confirm your willingness to quote

Best regards,

The attachments

The attached pdf file contained an embedded Excel object. The embedded object downloaded a remote template that exploits CVE-2017-11882 to download and execute the FormBook malware. This vulnerability exists in Microsoft Office 2007 Service Pack 3, Microsoft Office 2010 Service Pack 2, Microsoft Office 2013 Service Pack 1, and Microsoft Office 2016 and allows an attacker to run arbitrary code in the context of the current user by failing to properly handle objects in memory. If the current user is logged on with administrative user rights, this means an attacker could take control of the affected system.

The attached Excel document has the same functionality as the embedded excel object in the pdf file.

IoCs for this campaign

Attachments

c421a4309d8fe9fa9bdfe1bde69ccce3

f260e184fb067d3b646af3574e901c05

da4fcf9512dbdf5fa8a6dc88a646100e

7f5da76f29cf8238ed1f944b1d0e587a

bb65278dd77988f8a7bad219b524384c

C2s

czuj.info

vzddc.com

habitatsaludable.website

modhotels.store

maxxflush.com

Malwarebytes

Malwarebytes users were protected against this campaign, because the Malwarebytes Anti-Exploit module blocked the execution of the malware.

Stay safe, everyone!

The post Beware of malware offering “Warm greetings from Saudi Aramco” appeared first on Malwarebytes Labs.

Cisco has released a security advisory about two vulnerabilities in the API and web-based management interfaces of Cisco Expressway Series and Cisco TelePresence Video Communication Server (VCS). The flaws could allow an authenticated, remote attacker with read/write privileges to the application to write files or execute arbitrary code on the underlying operating system of an affected device as the root user.

Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services). These are the CVEs you need to know:

CVE-2022-20754

The first vulnerability exists in the cluster database API of Cisco Expressway Series and Cisco TelePresence VCS. This vulnerability is due to insufficient input validation of user-supplied command arguments. An attacker could exploit this vulnerability by authenticating to the system as an administrative user and then submitting crafted input to the affected command. A successful exploit could allow the attacker to overwrite arbitrary files on the underlying operating system as the root user.

CVE-2022-20755

The second vulnerability exists in the web-based management interface of Cisco Expressway Series and Cisco TelePresence VCS. This vulnerability is alos due to insufficient input validation of user-supplied command arguments. An attacker could exploit this vulnerability by authenticating to the system as an administrative user and then submitting crafted input to the affected command. A successful exploit could allow the attacker to execute arbitrary code on the underlying operating system as the root user.

Mitigation

The following products are affected by these vulnerabilities:

• Cisco Expressway: X14.0.3 – X14.0.4
• TelePresence Video Communication Server (VCS): X14.0.3 – X14.0.4

For these two vulnerabilities there are no workarounds. The only way to address them is to install the free software updates provided by Cisco. Both vulnerabilities received CVSS scores of 9 out of 10 and are rated critical. Therefore, customers are urged to update to the latest versions as soon as possible.

Known exploited vulnerabilities catalog

The two vulnerabilities that were included in the security advisory were found during internal security testing, so there is no reason to assume that they are being exploited in the wild. The same is true for two high-severity vulnerabilities in Ultra Cloud Core – Subscriber Microservices Infrastructure (SMI) and Identity Services Engine (ISE) patched earlier. These are CVE-2022-20762 (CVSS score of 7.8) and CVE-2022-20756 (CVSS score of 8.6). Another vulnerability patched this week was CVE-2022-20665 (CVSS score of 6.0) in the command line interface of Cisco StarOS which could allow an authenticated, local attacker to elevate privileges on an affected device.

While these vulnerabilities are not known to be exploited in the wild, looking at the catalog maintained by the Cybersecurity and Infrastructure Security Agency (CISA) that covers known exploited vulnerabilities you will notice that of the 95 vulnerabilities that were added yesterday, 3 March, 38 are Cisco’s.

The affected products:

• Small Business RV160, RV260, RV340, and RV345 Series Routers
• Small Business RV320 and RV325 Dual Gigabit WAN VPN Routers
• Catalyst 4500 Series Switches and Cisco Catalyst 4500-X Series Switches
• Catalyst 6800 Series Switches
• Cisco IOS XE Software
• IOS, XR, and XE Software

Some of these vulnerabilities need to be fixed by 17 March, 2022, while others have a due date of 24 March. These types of vulnerabilities are considered a frequent attack vector for threat actors and to pose a significant risk.

The Known Exploited Vulnerabilities Catalog has been established to act as a living list of known CVEs that carry significant risk to the federal government. Binding Operational Directive (BOD) 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date. Although BOD 22-01 only applies to FCEB agencies, organizations are encouraged to play along too, and reduce their exposure to cyberattacks with prompt patching of the most serious vulnerabilities.

Stay safe, everyone!

The post Update now! Cisco fixes several vulnerabilities appeared first on Malwarebytes Labs.

This blog post was authored by Hasherezade, Ankur Saini and Roberto Santos

Disk wipers are one particular type of malware often used against Ukraine. The implementation and quality of those wipers vary, and may suggest different hired developers.

The day before the invasion on Ukraine by Russian forces on February 24, a new data wiper was found to be unleashed against a number of Ukrainian entities. This malware was given the name “HermeticWiper” based on a stolen digital certificate from a company called Hermetica Digital Ltd.

This wiper is remarkable for its ability to bypass Windows security features and gain write access to many low-level data-structures on the disk. In addition, the attackers wanted to fragment files on disk and overwrite them to make recovery impossible.

As we were analyzing this data wiper, other research has come out detailing additional components were used in this campaign, including a worm and typical ransomware thankfully poorly implemented and decryptable.

We obtained samples and in this post we will take apart this new malware.

Behavioral analysis

First, what we see is a 32 bit Windows executable with an icon resembling a gift. It is not a cynical joke of the attackers, but just a standard icon for a Visual Studio GUI project.

It has to be run as Administrator in order to work, and does not involve any UAC bypass techniques. As we will later find out, the name of the sample also (slightly) affects its functionality; if the name starts with “c” (or “C”, as it is automatically converted to lowercase) the system will also reboot after execution.

Once run, the sample works silently in the background. For several minutes we may not notice anything suspicious.

Only if we watch the sample using tools like Process Explorer, we can notice some unusual actions. It calls various IOCTLs, related to retrieving details about the disks:

…including FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_MOVE_FILE which can remind of files defragmentation*.

[*] Note, that at the low-level, files may not be kept in a filesystem in one continuous chunk (as we see them at high-level), but in multiple chunks, stored in the various sectors of the disk. Defragmentation is related to consolidating those chunks, and fragmentation – to splitting them.

However, further examination has shown that the effect here is the opposite of defragmentation. In fact, the data gets more fragmented as a result of the malware execution.

The disk status regarding data fragmentation, before and after the malware execution, can be checked in the following images:

This is probably made in order to escalate the created damage: the more fragmented the file is, the more difficult it is to carve it out from the raw disk image, and reconstruct it forensically.

As the execution progresses, at some point, we may realize that some applications stopped working. It is because of the fact that some files, including system DLLs, have been overwritten with random data.

Example: an application failed to run because of a system DLL being trashed:

If we now view the raw image of the disk (i.e. using HxD), we can notice that some sectors have been also overwritten with random data:

Not surprisingly, on reboot our Windows OS will no longer work:

But what exactly happened underneath? Let’s have a closer look…

Used components

The initial sample: 1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591 – comes with several PE files in its resources:

The names chosen for the resources (DRV_X64, DRV_X86, DRV_XP_X86, DRV_XP_X64) suggest that they are a version of the same driver, dedicated to different versions of Windows: appropriately 32 or 64 bit version, or a legacy version for Windows XP. Each of them is in compressed form. By checking the dumped files by the Linux file command, we can see the following output:

file DRV_XP_X86
DRV_XP_X86: MS Compress archive data, SZDD variant, original size: 13896 bytes

To find out how they are loaded, we need to have a look at the sample that carries them.

Fortunately, the sample is not obfuscated. We can easily find the fragment that is responsible for finding the appropriate version of the driver:

The buffers are then decompressed with the help of the LZMA algorithm:

This format of compression is supported by a popular extraction tool, 7zip. We can also make our own decoding tool, basing on the malware code (example).

As a result we get 4 versions of legitimate drivers from the EaseUS Partition Master – just as reported by ESET (source).

• 2c7732da3dcfc82f60f063f2ec9fa09f9d38d5cfbe80c850ded44de43bdb666d
• 23ef301ddba39bb00f0819d2061c9c14d17dc30f780a945920a51bc3ba0198a4
• 8c614cf476f871274aa06153224e8f7354bf5e23e6853358591bf35a381fb75b
• 96b77284744f8761c4f2558388e0aee2140618b484ff53fa8b222b340d2a9c84

Based on the timestamps in the PE headers, the builds of the drivers are pretty old. Probably they have been stolen by the attackers from an original, legitimate software bundle. Each of them comes with a Debug directory, including a PDB path. Example:

Driver overview

The drivers leveraged by HermeticWiper are part of the Suite from EaseUS, a legitimate software that brings to the user disk functionalities like partitioning and resizing. As told, this tool is legitimate so no one was detecting the sample in VirusTotal at the time of the attack:

Looking inside the driver, we can see typical functions. The driver creates the required device and establishes some Dispatch Routines, as can be seen in the following image:

The internals of the driver are quite straightforward. In order to access the driver from usermode we need to use CreateFile API function and the name of the device under which the driver was installed (\.EPMNTDRV) along with the partition ID. Example shown below:

This string is important to understand the driver capabilities. As you can see, this drivers code will convert this sent string from usermode to integer and will use that integer as an input to the `saveReferenceHardDisk` helper function. As it can be extracted from the images, this helper function will save a reference to the physical disk (DeviceHarddisk[num]Partition0) in FsContext attribute:

This behaviour can has been tested also in real time. We can see how the leading backslash is removed prior to convert this value to integer type:

IRP_MJ_CREATE function will save a Device Object pointer for the hard disk in FsContext2 attribute, returned by getDeviceObject helper function. The DeviceObject pointer in getDeviceObject is used to find IRP_MJ_CREATE function will save a Device Object pointer for the hard disk in FsContext2 attribute (returned by getDeviceObject helper function). The DeviceObject pointer in getDeviceObject is used to find the disk.sys associated device object by traversing to the lowest device object leveraging IoGetLowerDeviceObject function. To confirm that the lower device object is indeed the one we are looking for we check the ServiceKeyName of the object with “Disk” which indicates that its looking for the disk.sys object as the ServiceKeyName for that object is “Disk”. These objects will be used later in read and write operations. That means that, when different operations are requested to the driver from usermode, the real operation will be performed over the machine physical disks.

Next images show how the driver builds the incoming requests and forwards them to the lower level devices:

By using FsContext2 field saved by a CreateFile operation performed from usermode, this driver could be seen as a proxy driver where IRPs are handled by underlying devices. In a nutshell, this legitimate driver lets the attackers bypass some windows security mechanisms which would ideally be forbidden from usermode such as writing to certain sectors of the raw disk.

Implementation of the Wiper

This malware is designed to maximize damage done to the system. It does not only overwrite the MBR, but goes further: walking through many structures of the filesystem and corrupting all of them, also trashing individual files.

We know that this executable is going to somehow abuse those drivers in order to implement the wiper functionality. Yet, the question arises, how exactly is it implemented?

It is worth to note that Windows (since Vista) introduced limitations, thanks to which only the sectors at the beginning of the disk can be written to from usermode (with the help of the standard windows drivers). If we want to write to further sectors, i.e. overwrite MFT (Master File Table) we need some custom workarounds. (More explanation given here.)

In case of Petya (as well as NotPetya, which used the same component), this workaround was implemented by an alternative “kernel” that was booting (instead of Windows) on machine restart, and doing the overwrite. In case of the HermeticWiper, the authors decided for an easier way: they used another driver, that was able to do such overwrites.

First, the malware parses NTFS structures, and stores information about them in the internal structures. For implementing the reads, standard system devices being used. After the needed data is collected, the additional (EaseUS) driver comes into play: it is used as a proxy to write into the collected sectors.

The attack can be divided into several phases:

1. Preparation, including:
   • Installation of the additional driver (EaseUS)
   • Disabling system features that may help in recovery, or in noticing of the attack
2. Data collection: walking through NTFS structure, collecting sectors and files that are going to be overwritten. Also, the random data of appropriate size is generated for the further overwrite.
3. Trashing (at this stage the EaseUS driver is utilized): the collected sectors are being overwritten by the previously generated random data

At the end, the system may be automatically rebooted.

Execution flow

Let’s now have a look at the malware sample, to see how those phases are implemented in detail.

Preparations

First the sample parses command line arguments. They will have minor impact on the execution – may just alter how long the sample is going to sleep between the execution of the particular phases.

Then, the sample proceeds to set privileges that are needed in order to execute the actions that are going to be performed. Two privileges are being set in the main function of the malware: SeShutdownPrivilege (that allows to reboot the system) and SeBackupPrivilege (that allows to manipulate system backups):

Here comes and interesting twist: the string defining SeShutDownPrivilege is composed on the stack, and one chunk in between is missing:

This missing chunk wnPr is then being filled at the position that is calculated depending on the first character of the current executable name. Due to this, the string becomes complete (and the privilege is set properly) only in the case if the sample has a name starting from “c”.

The reason why the authors decided for such unusual alteration of the flow is not sure. It may be just to obfuscate this particular, suspicious string. It is also common for malware authors to use a name check as an anti-sandbox technique (since sandboxes may assign to samples some predictable names: in the case if such name was detected, sample may exit, so that its behavior cannot be tracked by the Sandbox). However, here the change in the sample behavior is very minor – it affects only the reboot functionality, not the main mission of the malware.

Driver Installation

After that, the malware proceeds to the installation of the driver:

The installation function takes several steps.

First, the system is fingerprinted, so that the malware can select the most appropriate version of the driver to be used. Depending on the Windows version, and the bitness (32 or 64 bit), the resource is selected.

Before installing the driver, the crash dump mechanism is being disabled:

Crash Dumps are usually being made if the full system crashes, possibly because of a bug/instability in a driver. They contain information about the full status of the system, and on what exactly happen, in order to help debugging. Disabling crashes before the installation suggests that the authors of the malware have some level of distrust in the used drivers, or believe that the executed operation posses some risk of crashing the system. That’s why they want to be extra sure that if it eventually happens, the Administrators will have a harder time to find the reason.

Then, they check if the driver is already installed. They do it by sending there and IOCTL, that is supposed to retrieve information about the drive geometry. If this operation has failed, it means the driver is not there, and they can proceed with the installation.

The installation is done by first generating a pseudorandom, 4-character long name for the driver, from the hardcoded charset. The function also makes sure that the file with the generated name does not exist yet.

Then, the compressed version of the file is being dropped. And finally, the driver is decompressed from it.

The decompressed driver is installed as a service:

At this point, the newly dropped files are also added to the structures that will be further passed to the wiping functions – so that the files can be overwritten at low level. More about it is described in section “Data collection”.

The installation function (denoted as create_driver_svc) first enables yet another privilege: SeLoadDriverPrivilege (which is required to allow loading drivers):

Then the driver is added as a system service, and started:

This triggers execution of the DriverEntry function, and since that point, the driver is residing in memory.

After the successful installation, the registry keys related to the service, as well as the dropped files, are deleted, to make the new driver more difficult to spot:

We must note, that file deletion does not interfere in the functionality of the driver. It is still loaded in memory (till the next reboot) and will be available for the further use.

Disabling shadow copies

It is a common action done by ransomware to delete shadow copies. It is supposed to destroy system backups, and paralyze the recovery. In this case, we can see the sample disabling the Shadow copy Service:

Data Fragmentation

During our analysis, we noticed that the malware fragments the files present on the disk (as opposite of defragmentation).

Before the fragmentation routine, it changes some settings related to explorer:

This is probably to hide the information about the file status to the user, to keep them in blind for as long time as possible.

Below function shows how the fragmentation routine is executed:

The standard windows directories are being excluded:

This can be done both to save time (by not corrupting standard files), and to avoid the interference with system stability.

The file fragmentation process can be seen in next images:

The fragmentation algorithm implementation is achieved by using different IOCTL_CODES (FSCTL) as FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_GET_MOVE_FILES. The code looks pretty similar to a defragmentation code. But in this case, is being modified in order to fragment, where file chunks are splitted and moved to free clusters in the disk.

Data collection

After those preparations, malware enters the second stage of the execution: data collection. In casual ransomware cases, we may see sometimes that prior to the encryption, malware iterates through various directories, and makes a list of files that it is going to attack. This case is analogous, but much more interesting, because the authors iterate not through directories (at high level, using windows API), but at low level, through NTFS file system, reading various structures and parsing them manually. To enumerate them, they send IOCTLs through standard Windows devices (the newly installed driver is not used yet).

Data storage

The output of this parsing is stored in custom structures which we managed to reconstruct, and defined in the following way:

struct elemStr
{
  elemStr *fLink;
  elemStr *bLink;
  chunkStr *chunkPtr;
  DWORD diskNumber;
  BYTE *randomBufToWrite;
  DWORD sizeBuffer;
};

struct chunkStr
{
  chunkStr *fLink;
  chunkStr *bLink;
  LARGE_INTEGER offset;
  QWORD chunk_size;
};

They both are linked lists.

The first one elemStr defines the element that will be overwritten. Its size is retrieved, and the random buffer dedicated for its overwrite is generated:

The “chunk” represents a continuous block of physical addresses to be overwritten.

So in general, the malware will use these structures in a 2 step process. First step will collect all the data. The second step will wipe this data, using the previous created structure.

Collected elements

As seen before, these structures will be sent to functions that will perform the data corruption, at a very low level. The elements that are collected for later destruction are presented below.

Own executable and the dropped drivers

We have seen that the attackers were interested in cleaning their trace. To accomplish that, they will delete their own executable from disk, even tough the binary itself keeps running and in memory. As any other task performed in the filesystem by HermeticWiper, the way of deleting their binary is slightly different as other malwares do. The attackers first manage to find which offset the binary occupies in raw, and finally they will overwrite that specific offset.

The dropped files (compressed and uncompressed driver) were added to the same structure, just after the the installation.

The Boot Sector

One of the attackers motivation is making devices incapable of loading the OS. The first step followed is enumerating all physical devices, as well as partitions. For that, a simple loop is used that tries to open a handle to HardDisk[num], where num is iterated from 0 to 100:

All this information is then stored into a elemStr structure that contains data as the disk number. In this case, chunkElement will describe raw addresses of boot sectors. In that regard, an especial mention is made to C:System Volume Information. The attackers will add to boot_sectors structure this folder contents:

According to Microsoft, “The Mount Manager maintains the Mount Manager remote database on every NTFS volume in which the Mount Manager records any mount points defined for that volume. The database file resides in the directory System Volume Information on the NTFS volume” (Windows Internals, 6th edition). So this technique is also created for increasing damage. Finally, all these collected offsets will be overwritten as the malicious binary was, leveraging the EasyUS driver.

Reserved Sectors and MFT

As before, the malware will brute-force again against the PhysicalDrive ID to find valid drive IDs. Then it uses IOCTL_DISK_GET_DRIVE_LAYOUT_EX to retrieve information about all the primary partitions present on the drive and reads the first sector from that partition. Other information required to read one sector from the disk is retrieved by using the IOCTL_DISK_GET_DRIVE_GEOMETRY_EX.

Once the first sector of a partition is read then the callback function passed by the malware is invoked on this sector.

Depending on the filesystem type if its FAT then it wipes all the Reserved Sectors, the boot record sectors in FAT filesystem are part of Reserved Sectors. In case of NTFS the malware wipes the MFT and MFTMirror (backup MFT) present on the disk, the purpose of which is to make the recovery of the data harder.

Each file on an NTFS volume is represented by a record in a special file called the master file table (MFT). In case the MFT becomes corruptible then MFT mirror is read in an attempt to recover the original MFT, whose first record is identical to the first record of the MFT. MFT table is the index on which the filesystem relies, having information like where a file resides. Without MFT, the system will be unable to know were folders and files are, or modification dates, etc. 

Bitmap and LogFile

In an attempt to hinder the recovery, Bitmap and LogFile are overwritten as well for all the logical drives present on the system. The logical drives are retrieved by GetLogicalDriveStringsW in this case. These structures are also important when doing recovery and postmortem investigation. $Bitmap contains information about free and occupied clusters and $Logfile contains a log of transactions that happened in the filesystem.

Also user files will be impacted by data destruction. We have discovered that the malware will overwrite as well almost everything inside C:/Documents and settings. In modern Windows, Documents and Settings will point to C:/Users. This folder contains users data folders (for example, My Documents or Desktop are located in these folders). Some files are skipped in this process, as the ones under APPDATA but in general, every file that is contained under these folders will be overwritten.

Collecting clusters to erase the whole disk

The final part of the data collection is to get information required to wipe all the occupied clusters on the disk. To get this information the malware uses FSCTL_GET_VOLUME_BITMAP IOCTL which gives us information about all the occupied and free clusters on the disk. The malware traverses all the logical disks and uses FSCTL_GET_VOLUME_BITMAP to retrieve the bitmap, every bit in the bitmap denotes a cluster, a value of 1 implying that the cluster is occupied and 0 meaning that the cluster is free. The bitmap retrieved with the IOCTL is traversed bit by bit and all the occupied clusters are added to the wiping structure which is described above in the post, one thing to note here is that malware combines all the contiguous clusters and these contiguous multiple clusters are denoted by a single chunk structure opposed to earlier usages where one chunk structure denoted a single cluster.

Finally, all occupied clusters will be collected in a elemStr typed structure for its destruction.

How is this all performed?

Through the entire post its been told that some NTFS properties (like attributes, indexes, etc) are being used in order to collect data, that will be wiped after. We will like to show an example of how attackers implemented that functionality and show the level of sophistication.

For that, we will take as example the code responsible in collecting the Windows log files:

After this call, some data structures are filled, containing data regarding physical disk properties and the folder name itself. Our first reference to the NTFS filesystem is found in the way that the HANDLE is retrieved. This folder is opened as a NTFS stream:

Eventually, the code will reach the following point. The first call will parse $INDEX_ROOT attribute, and the functionality is relatively similar and simpler than the second one, where $INDEX_ALLOCATION attribute is used. Additional information about these NTFS attributes can be found here. We will assume that the list of elements is long enough to have an $INDEX_ALLOCATION and we will deep into this call:

It is important to have in mind the parameters sent for a better understanding of the whole process. First two parameters (nFileIndexLow and nFileIndexHigh) are used for calling the function FSCTL_GET_NTFS_FILE_RECORD, which will retrieve a NTFS record. After some checks (for example, the magic value), we will pop out in a function that we have called callback_when_attribute_is_found. Note that the first parameter sent to this function will be the $INDEX_ALLOCATION (0x20) value that was previously sent:

What this function will do is to iterate through all NTFS attributes that are part of the record. To do that, the code will have to find the offset to the first attribute. This offset is just 2 bytes long, as is relative to the structure. The layout of the header is demonstrated below:

A NTFS File record will follow this structure:

Record Header

Attribute

Attribute

Attribute

If we still remember the $INDEX_ALLOCATION (0x20), it becomes handy now. Attributes will start with a specific TypeCode, as $INDEX_ALLOCATION is. So, if one of the attributes matches the selected type that was required, the first callback function (the one sent steps before as a parameter) will be triggered:

In the case there is not matching TypeCode but an $ATTRIBUTE_LIST is found, that will mean that exists more attributes, but these cannot fit into $MFT table. In this rare case, the malware will continue processing these extra attributes and will call recursively the first function.

Lets check what this callback will do. Remember that this callback function, in our case is indexAllocation_Callback_CollectAllfiles. The first step will be recovering the stream that this attribute points to. As $INDEX_ALLOCATION is an attribute meant for directories, makes sense this stream being an index array (block indexes):

As this is an index array, these indexes will point to something. This something is, as you would imagine, NTFS records. In raw disk, these type of indexes look like that:

As indexes point to records, all of these records will be sent, recursively, once more to the initial function. But this time the callback function will be different, also the typecode:

So this time, every record sent will behave differently. $DATA attributes will be looked for instead of $INDEX_ALLOCATION ($DATA contains file data). Also, the executed callback function will be different (named now dataExecuting). By using the disk properties that were sent in the first call combined with information gathered from indexes, this callback will locate the exact location of the file in disk. The last step for these files, as for all the ones that we have summarized in this report is being added as a member to a elemStr* structure. The offsets contained in this structures, as stated, will be overwritten by the malware in the last steps:

Data overwriting

Finally, after all data is collected, the malware starts overwriting. The elemStr structure is passed into the function, and all the elements on the linked list are being processed:

The overwriting function uses the installed driver in order to gain the write access to the sectors. It opens the device, and then walks through all the collected chunks, by their offsets. It uses WriteFile to fill it with the previously prepared, random data.

Example below shows a fragment of a log from our experiments, when we dumped the content of particular structures during malware execution: first data collection, and then usage of the filled structures to wipe out the sectors on the disk:

Conclusion

As can be seen, by leveraging legitimate but flawless signed code, the attackers are capable of bypassing some Windows security mechanisms. This is extremely harmful because user applications are not meant to have this level of control in kernel space, for security reasons.

Also, we would like to state that recovery in this case is complicated. The attackers first fragment files on disk, and finally, will overwrite all of these fragments. Even without the last step (indiscriminate disk trashing), the combination of fragmentation and wiping of required structures (like $MFT) would be enough to make recovery almost impossible.

Our final thoughts are about the special focus that cybercriminals put in hiding their tracks. Maybe, that part is the final stage of a bigger operation. In fact, ESET recently described other related artifacts here, and they connect them to the same actor and campaign. Being part of a bigger picture can explain why attackers are so much interested in corrupting files like $LogFile and Windows events.

Malwarebytes detects this disk wiper as Trojan.HermeticWiper.

The post HermeticWiper: A detailed analysis of the destructive malware that targeted Ukraine appeared first on Malwarebytes Labs.

On February 25, news broke about a cyberattack on Nvidia, America’s biggest microchip company, which saw parts of its business taken offline for two days. Soon after, the ransomware group LAPSUS$ claimed responsibility and threatened to leak 1 TB in exfiltrated data.

You would think that while this is big news, the story is one that has been told many times. So many times that ransomware fatigue is starting to become the new security fatigue. But there are some interesting aspects to this particular attack that make it stand out.

LAPSUS$

The LAPSUS$ group is a relative newcomer to the ransomware scene, but it has made a name for itself by bringing down big targets like Impresa, the largest media conglomerate in Portugal, Brazil’s Ministry of Health, and Brazilian telecommunications operator Claro. The group is believed to hail from South America, based on its targets and the near-native use of Spanish and Portuguese. The main attack vector is phishing which the group uses to gain a foothold before moving on to breach the network from there.

Vigilante

In the case of the Nvidia breach, LAPSUS$ claimed it was mainly after the removal of the lite hast rate (LHR) limitations in all GeForce 30 series firmware—apparently all to help out gamers and the mining community. Nvidia LHR graphics cards detect when they’re being used for Ethereum (ETH) cryptocurrency mining and automatically halve the hash rate.

“LAPSUS$

After evaluating our position and NVIDIA’s we decided to add one more requirement.

We request that NVIDIA commits to COMPLETELY OPEN-SOURCE (and distribute under a foss license) their GPU drivers for Windows, macOS and Linux, from now on and forever.

If this request is not met, on Friday we will release the COMPLETE SILICON, GRAPHICS, AND COMPUTER CHIPSET FILES for all recent NVIDIA GPUs, including the RTX 3090Ti and UPCOMING REVISIONS! Of courrse this includes all files with extensions such as .v, .vx, .vg and more.

So, NVIDIA, the choice is yours! Either:

-Officially make current and all future drivers for all cards open source, while keeping the Verilog and chipset trade secrets… well, secret

OR

-Not make the drivers open source, making us release the entire silicon chip files so that everyone not only knows your driver’s secrets, but also your most closely-guarded trade secrets for graphics and computer chipsets too!

YOU HAVE UNTIL FRIDAY, YOU DECIDE!”

(Friday in this demand is March 4, 2022)

Nvidia’s goal by implementing LHR was to get more GeForce graphics cards in the hands of gamers. We understand why LAPSUS$ would demand the removal of LHR on behalf of miners, but why the group feels this would also be beneficial to gamers is unknown, especially since there are many doubts around the effect of LHR. Also, cryptominers have already managed to unlock 70% of the hash rate in NVIDIA’s new GPUs.

Nvidia

Initially, Nvidia said the ultimate concern was that somebody might have put something in one of the software updates, which is understandable since that could be the foundation of a huge supply-chain attack.

Now, Nvidia has confirmed that it was hacked and that the threat actor is leaking employee credentials and proprietary information onto the internet.

“Shortly after discovering the incident, we further hardened our network, engaged cybersecurity incident response experts, and notified law enforcement.”

Hacked back?

At some point during the negotiations the LAPSUS$ group started to make a big fuss about having been hacked back. The group claimed Nvidia had hacked back to encrypt the group’s virtual machine with the data, although later toned that down to “Nvidia tried but failed, we have all the data”.

Nvidia has not responded to these claims and did not address that element in its statement. While hacking back is not unheard of, it is highly unlikely in cases like this, especially as under current US law it is illegal for the victim of a cyberattack to hack back. If we define hack back as “to launch a counterattack aimed at disabling or collecting evidence against the perpetrator,” that is.

Passwords

The passwords and email addresses of some 70k employees were involved. According to Nvidia, all employees have been required to change their passwords.

The information on HaveIBeenPwnd says about the Nvidia breach:

“Impacted data included over 70k employee email addresses and NTLM password hashes, many of which were subsequently cracked and circulated within the hacking community.”

In a tweet Troy Hunt, the owner of HaveIBeenPwnd, stated that 17% of addresses were already in the database.

Although that is a worrying number, it does not come as a surprise. According to research, 80% of consumers have had their emails leaked on the dark web and 60% of people reuse passwords across multiple accounts. The same researchers published a list of the 20 passwords most commonly found on the dark web, due to data breaches:

• 123456
• 123456789
• Qwerty
• Password
• 12345
• 12345678
• 111111
• 1234567
• 123123
• Qwerty123
• 1q2w3e
• 1234567890
• DEFAULT
• 0
• Abc123
• 654321
• 123321
• Qwertyuiop
• Iloveyou
• 666666

If you recognize one or more of them we would encourage you to not only change them, but also to start using a password manager. Passwords managers help you because:

• You don’t have to memorize all your passwords anymore.
• They can auto-generate highly secure passwords for you.
• They can alert you to a phishing site. If you’re using a browser-based password manager, it will not auto-complete the username and password fields since it doesn’t recognize the website as the one tied to the password.
• They can help your beneficiaries when you pass away. All you need to leave behind is the keys to the vault.
• Password managers save time. Beyond just storing passwords for you, some can store and auto-fill name, address, email, phone number, and credit card info.
• Many password managers sync across different operating systems.
• They help protect your identity, because they make it a lot easier not to re-use your passwords. One breach will not require you to change a multitude of passwords.

Stay safe, everyone!

The post Nvidia, the ransomware breach with some plot twists appeared first on Malwarebytes Labs.

Russia’s continued, weeklong invasion of Ukraine has altered the landscape of cybersecurity threats facing organizations both near and far from the physical threat of war.

Disinformation is spreading and being actively fought. The old hacker group Anonymous promised “cyber war” against Russia. One ransomware group swore to launch retaliatory attacks for any harm brought to Russia’s critical infrastructure (and then subsequently had to stanch the informational bleeding caused by an insider’s leak campaign). And external government-sponsored threat actors are still continuing their own campaigns against Africa, Asia, Europe, and North America.

The crossfire of these international cyber offensives can, regrettably, catch ordinary small- to medium-sized businesses (SMBs) in the middle. Here are four cybersecurity best practices that SMBs can adopt today to protect their businesses, employees, devices, and networks in this continually evolving crisis.

1. Lock down your public-facing networks and beef up internal security

Cybersecurity’s history of its most devastating attacks involves many stories of basic lapses in judgment—unprotected Remote Desktop Protocol (RDP) ports, elevated access privileges for far too many employees, unpatched vulnerabilities, and lacking multi-factor authentication.

These are simple errors that, with the right prioritization, can be solved. According to the most recent advice from the US Cybersecurity and Infrastructure Security Agency (CISA), all companies, including SMBs, should commit to the following:

• Validate that all remote access to the organization’s network and privileged or administrative access requires multi-factor authentication.
• Ensure that software is up to date, prioritizing updates that address known exploited vulnerabilities identified by CISA.
• Confirm that the organization’s IT personnel have disabled all ports and protocols that are not essential for business purposes.
• If the organization is using cloud services, ensure that IT personnel have reviewed and implemented strong controls outlined in CISA’s guidance.
• Sign up for CISA’s free cyber hygiene services, including vulnerability scanning, to help reduce exposure to threats.

With these practices, many of the most common types of cyberattacks can be prevented. For more information on how to detect cyber breaches as they happen, and to prepare on how to respond to such an attack when it happens, you can read CISA’s “Shields Up” guidance on staying cybersecure during Russia’s attacks against Ukraine.

2. Audit access privileges and clean up old account credentials

Similar to how any SMB should be ensuring that any remote access to their networks is protected with multi-factor authentication, SMBs should also audit which of their employees have access privileges to which systems and resources. Too often, employees who do not need access to high-level, sensitive controls are given blanket access to their entire company. All it takes for an attacker to get in, then, is for any of those employees to slip up in, say, a phishing scam.

Take the time to audit who has access to what parts of the company, and whether they actually need it. Also, be sure to clean up any old user accounts from ex-employees. Such accounts should be deactivated.

3. Stay vigilant of phishing scams

Much like how online scammers leveraged the global COVID-19 pandemic in its earliest days to swindle people out of their money, the crisis in Ukraine will likely lead to bogus pleas for charity donations that, in truth, could end up in a cyberthief’s hands.

SMBs should remind their employees about phishing threats and, if possible, send an updated notice about phishing attempts specifically related to Russia’s invasion of Ukraine.

The same rules for spotting phishing emails still apply: Be wary of any unexpected requests for personal information, hover over URL links to ensure they’re legitimate, double-check the sender’s own email address, avoid opening email attachments from unknown senders, and scan any message for spelling and grammar mistakes.

But as we’ll explain in our next cybersecurity best practice, if an SMB has not pushed out any phishing training in its organization, now is not the time to roll out a new training module.

4. Do not roll out brand new, untested cybersecurity measures

The cybersecurity priorities for SMBs right now are securing the tools and programs that they currently use—not adding new ones, and new complexity, to the mix. This work takes time and caution, as even a small business could be in control of hundreds of endpoints each with dozens of software tools that each have their own reams of account credentials, both current and out-of-date.

While a new, fancy tool may sound promising in bolstering your cybersecurity, what it could actually add is a headache for your IT professionals.

As the cybersecurity landscape continues to change, IT professionals inside SMBs should not have to split their time with yet another project to manage. Give them the time—and the authority—to raise red flag issues with your C-suite and to fix any problems that they find today without having to worry about new ones tomorrow.

The post Four SMB cybersecurity practices during geopolitical upheaval appeared first on Malwarebytes Labs.

Earlier this week, we spotted a Microsoft sign-in phish that appeared to be taking advantage of the Ukraine crisis in order to scam people. The email warned of unauthorized log in attempts to the recipient’s account, and the location of those attempts was listed as “Russia/Moscow”. We probably won’t ever know whether this campaign is definitely inspired by current events, but one thing is for sure, the latest spam campaign we’ve seen recently is.

In this latest spam mail, which allegedly originates from @president.gov.ua, which is clearly a spoofed domain.

The header image looked like a stretched Ukraine flag, suggesting it was not professionally made. The text below it reads:

A donation campaign has been launched to support Ukraine and also help refugees fleeing the conflict area in Ukraine

The campaign, organized by the humanitarian organization Act of Peace, is hoping to raise $9,000,000 to support refugees in the region.

Stand with the people of Ukraine. Now accepting cryptocurrency donations. Bitcoin, Ethereum, USDT and NFT.

USDT is Tether, a kind of cryptocurrency. It’s interesting to note that they accept NFTs as “donation”.

There are no misspellings, which is seen as a classic red flag in scam mails. Act of Peace is also a legitimate humanitarian organization based in Australia, and it does have an exclusive donations page for the Ukraine crisis. What it probably doesn’t have is access to an email server it can use to send donation emails on behalf of the official website of the President of Ukraine.

Stay vigilant

If you really want to finance humanitarian aid to help Ukrainian refugees, here is a helpful Twitter thread of verified organizations put together by Ukrainians themselves that you can check out.

Remain vigilant. The last thing you want is to hand over your hard-earned money to help the hurting only for it to end up inside scammers’ pockets.

Stay safe!

The post Don’t fall for the “Donate to help children in Ukraine” scam appeared first on Malwarebytes Labs.

Meta says it has detected and removed two disinformation campaigns regarding the current Russia-Ukraine war. These campaigns, it says, were run by groups in Russia and Ukraine to target Ukraine users.

In the post, Nathaniel Gleicher, Meta’s head of security policy, and David Agranovich, Meta’s director of threat disruption said:

“We took down this operation, blocked their domains from being shared on our platform, and shared information with other tech platforms, researchers and governments. This network used fake accounts and operated fictitious personas and brands across the internet — including on Facebook, Instagram, Twitter, YouTube, Telegram, Odnoklassniki and VK — to appear more authentic in an apparent attempt to withstand scrutiny by platforms and researchers.”

They noted that the fictitious personas used in these campaigns were likely generated using generative adversarial networks (GAN), technology that is used in disinformation campaigns with the use of fake videos and several fraud scams. These personas claim to be within Ukraine and in white-collar jobs pre-conflict.

The misinformation campaign involves websites masquerading as independent news outlets that push claims that the West has failed Ukraine and that it’s now a failed state. Meta links the campaign with a previous campaign it removed in April 2020. Both are linked to individuals in Russia, Donbas—a region in Ukraine populated by separatist groups, most of whom are “ethnically Russian and identify as Russian,” and media organizations previously sanctioned by the US government.

Gleicher and Agranovich also said Meta had seen Ghostwriter—a known hacking group aligned with Belarusian government interests—targeting Ukrainian Facebook and Instagram users in the past several days.

“We detected attempts to target people on Facebook to post YouTube videos portraying Ukrainian troops as weak and surrendering to Russia, including one video claiming to show Ukrainian soldiers coming out of a forest while flying a white flag of surrender.”

In a previous post, we noted that misinformation is one of the six risks internet users could encounter online during this crisis period. To curb this and other online threats, Meta has rolled out additional security and privacy measures to protect both its users in Ukraine and Russia.

On top of promoting fake news, Ghostwriter has also targeted Ukrainians with phishing attacks, Gleicher and Agranovich said. Meta already blocks these phishing domains.

“We encourage people to use caution when accepting friend requests and opening links and files from people they don’t know. Please refrain from reusing the same passwords across different services to prevent malicious hackers from gaining access to your information. We also strongly recommend using two-factor authentication on all online accounts.”

The post Meta blocks Russia-Ukraine disinformation campaigns on Facebook, Instagram appeared first on Malwarebytes Labs.

I have long said that Deepfakes missed the boat on being stealthy, believable pieces of footage able to turn the tide of elections or other major events. We’ve seen time and again how suggested examples of use during important happenings have been terrible, whereas the smart use has tended to be quiet, low level affairs as a stepping stone rather than an end goal.

The other stance on this is that people will find moving imagery more believable than photographs or AI generated text. This is an entirely fair point of view, and we can’t really say for sure that nothing seriously bad on the global scale will ever come from a deepfake. However, one study suggests the fakers still have a way to go before that becomes a possibility.

Audio and visual clues

The Register reports that researchers at MIT have pulled the rug on the whole deepfake issue. Just over 5,000 people participated in a video/audio versus text transcript showdown. The task: figure out whether audio, video/audio, and text transcripts of Joe Biden and Donald Trump were real or fake. The results:

Video and audio: 82% guessed correctly

Audio only: 76% guessed correctly

Text only: 57% guessed correctly

One would assume text only is going to be quite the dice-throw. In terms of video, are we getting better at spotting the joins, the edits, the slight uncanny valley effect in most deepfake content? Have we somehow trained ourselves to know when something isn’t right by virtue of having seen so many pieces of deepfake content over the last few years?

These aren’t questions we have answers for yet, although as always, we may have more pressing concerns anyway.

Who needs Deepfakes?

I’m a fan of the path of least resistance idea where deepfakes are concerned. That is to say, are there simpler ways to achieve the desired effect of a deepfake with simpler methods? And, if so, why even reach for the deepfake in the first place? It’s a lot of hard work for something with a big risk of little to no pay off.

A good case in point: the many, many pieces of dis/misinformation currently surrounding events in Ukraine. Deepfakes aren’t being used; it’s just regular footage spliced in whatever way is required. Tricky, sophisticated AI generated fakes may not be required when simple photographs or viral videos are mislabeled and made viral.

In the last few days alone, we’ve seen several examples of this phenomenon doing big numbers on social media, quite often promoted by verified (and perhaps mistaken as authoritative) commentators on social media:

My strikes:
– the tiktok of the woman showing how to drive a tank
– the photo of Ukrainian kids saluting tanks (old photo)
– news of mayor saying Kiev was encircled
2/3 of were me retweeting other verified users who themselves had been trigger happy

— David Carroll (@profcarroll) March 1, 2022

Digitally doctored video versus jpegs

Commentators continue to warn of the dangers of deepfakes, but look at the example from this video. His head moves oddly and doesn’t look properly connected to the peculiarly flat-looking body. The mouth moves strangely at various points throughout. Even without using tools to analyse the footage, there’s clearly something very wrong with the content. So, we’re right back where we started: tried and tested methods, with less demanding technical overheads. When upwards of 14 million people are being told Steven Seagal is on the frontline thanks to a hasty image edit, the impact of overwrought deepfakes recedes into the distance.  

When fakes fight fakes

On top of everything else, we have the peculiar sight of face-swap apps trying to disseminate real information. With what is claimed to be 9 million messages sent out related to one campaign, and 2 million of those being sent to users in Russia, it’s arguable that the most interesting and pervasive use of deepfake tech during a major event is to essentially cancel its own power.

Strange times indeed for the AI-altered revolution which never quite seems to land.

The post Deepfake study suggests fakes can run but not hide appeared first on Malwarebytes Labs.