itman 1,801 Posted February 7, 2020 Posted February 7, 2020 (edited) To begin, anyone who hasn't updated their Realtek audio driver in the last few months is most likely vulnerable. All audio drivers prior to version 8857 are vulnerable. I am posting this because: 1. This is a kernel mode device driver vulnerability. 2. The outfit, SafeBreach Labs, who developed the POC: https://safebreach.com/Post/Realtek-HD-Audio-Driver-Package-DLL-Preloading-and-Potential-Abuses-CVE-2019-19705 , has a penchant for later using their POC's to show how AV protections can be bypassed using these vulnerabilities. Quote Realtek fixed a security vulnerability discovered in the Realtek HD Audio Driver Package that could allow potential attackers to gain persistence, plant malware, and evade detection on unpatched Windows systems. The Realtek High Definition Audio Driver is installed on Windows computers that come with Realtek audio cards. The bug was reported to the vendor on July 10, 2019, and it received a patch on December 13, 2019. Realtek fixed the issue in the HD Audio driver package ver.8857 or newer, while driver versions earlier than 8855 that were built using the old version of the Microsoft development tool (VS2005) are still vulnerable to attacks. If exploited, the vulnerability tracked as CVE-2019-19705 allows attackers to load and execute malicious payloads within the context of a Realtek-Semiconductor signed process on machines running an unpatched version of the HD Audio driver. https://www.bleepingcomputer.com/news/security/realtek-fixes-dll-hijacking-flaw-in-hd-audio-driver-for-windows/ Edited February 7, 2020 by itman peteyt 1
itman 1,801 Posted February 7, 2020 Author Posted February 7, 2020 (edited) Another kernel mode driver issue. Ransomware Exploits GIGABYTE Driver to Kill AV Processes Quote The attackers behind the RobbinHood Ransomware are exploiting a vulnerable GIGABYTE driver to install a malicious and unsigned driver into Windows that is used to terminate antivirus and security software. When performing a network-wide compromise, ransomware attackers need to push out a ransomware executable as quickly as possible and to as many systems as they can to avoid being detected. One protection that can get in their way of a successful attack, though, is antivirus software running on a workstation that removes the ransomware executable before it can be executed. To overcome this hurdle, the operators behind the RobbinHood Ransomware are utilizing a custom antivirus killing package that is pushed out to workstations to prepare it for encryption. Using trusted drivers to terminate security processes In a new report, Sophos researchers have seen the RobbinHood attackers installing a known vulnerable GIGABYTE driver that has been cosigned by Microsoft and exploiting its vulnerability to disable Microsoft's driver signature enforcement feature. Once disabled, they can install a custom malicious kernel driver that is used to terminate antivirus and security software processes. "In this attack scenario, the criminals have used the Gigabyte driver as a wedge so they could load a second, unsigned driver into Windows," Sophos' report explains. "This second driver then goes to great lengths to kill processes and files belonging to endpoint security products, bypassing tamper protection, to enable the ransomware to attack without interference." The attack starts with the operators deploying an executable named Steel.exe to exploit the CORE-2018-0007 vulnerability in the GIGABYTE gdrv.sys driver. When executed, Steel.exe extracts the ROBNR.EXE executable to the C:\Windows\Temp folder. This will cause two drivers to be extracted to the folder; the vulnerable GIGABYTE gdrv.sys driver and the malicious RobbinHood driver called rbnl.sys. https://www.bleepingcomputer.com/news/security/ransomware-exploits-gigabyte-driver-to-kill-av-processes/ -EDIT- Attention Eset. No detection for the following at VT: Quote IoCs We analyzed the following files in the course of this investigation SHA256 Filename 791c32a95f401f7464214960e49e716656f6fd6fff135ac2a6ba607236d3346e STEEL.EXE 99c3cc348f8ee4e87bce45b1dd185d31830c370ac43fd3e39ac50340f029ef79 ROBNR.EXE 0b15b5cc64caf0c6ad9bd759eb35383b1f718edf3d7ab4cd912d0d8c1826edf8 RBNL.SYS 31f4cfb4c71da44120752721103a16512444c13c2ac2d857a7e6f13cb679b427 GDRV.SYS https://news.sophos.com/en-us/2020/02/06/living-off-another-land-ransomware-borrows-vulnerable-driver-to-remove-security-software/ Edited February 8, 2020 by itman
Most Valued Members Nightowl 206 Posted February 7, 2020 Most Valued Members Posted February 7, 2020 (edited) That's quite interesting the second one , thanks for sharing About the VT results for robnr.exe , those who detect it used machine learning I guess , due to the naming of the detection Edited February 7, 2020 by Rami
itman 1,801 Posted February 7, 2020 Author Posted February 7, 2020 (edited) 1 hour ago, Rami said: About the VT results for robnr.exe , those who detect it used machine learning I guess , due to the naming of the detection This is a nasty one. Gigabyte never patched the vulnerability in the gdrv.sys driver stating it wasn't vulnerable. That is not surprising for those familiar w/Gigabyte. This malware will exploit that vulnerability and then load the exploited driver on the targeted device. They then use the exploited loaded driver to load their malicious driver to kill off AV processes. Note that Win 10 ELAM driver feature that Eset and many AV vendors use to load their anti-malware drivers, only loads this driver prior to any other app based drivers. Kernel mode device drivers load prior to any app based drivers which would allow malicious ones to intercept any activities from any app drivers. Edited February 7, 2020 by itman
itman 1,801 Posted February 7, 2020 Author Posted February 7, 2020 (edited) As far as the above noted Robbinhood ransomware portion of the attack; Quote Next it will stop 181 Windows services associated with antivirus, database, mail server, and other software that could keep files open and prevent their encryption. It does this by issuing the "sc.exe stop" command as shown below. cmd.exe /c sc.exe stop AVP /y A full list of services stopped by RobbinHood; List of Stopped Services: AVP, MMS, ARSM, SNAC, ekrn, KAVFS, RESvc, SamSs, W3Svc, WRSVC, bedbg, masvc, SDRSVC, TmCCSF, mfemms, mfevtp, sacsvr, DCAgent, ESHASRV, KAVFSGT, MySQL80, POP3Svc, SMTPSvc, Smcinst, SstpSvc, TrueKey, mfefire, EhttpSrv, IISAdmin, IMAP4Svc, McShield, MySQL57, kavfsslp, klnagent, macmnsvc, ntrtscan, tmlisten, wbengine, Antivirus, MSSQL$TPS, SQLWriter, ShMonitor, UI0Detect, sophossps, MSOLAP$TPS, MSSQL$PROD, SAVService, SQLBrowser, SmcService, swi_filter, swi_update, AcrSch2Svc, EsgShKernel, MBAMService, MSSQLSERVER, MsDtsServer, SntpService, VeeamNFSSvc, swi_service, AcronisAgent, FA_Scheduler, MSExchangeES, MSExchangeIS, MSExchangeSA, MSSQL$ECWDB2, MSSQL$SOPHOS, MSSQL$TPSAMA, PDVFSService, ReportServer, SQLAgent$TPS, SQLTELEMETRY, VeeamRESTSvc, MSExchangeMTA, MSExchangeSRS, MSOLAP$TPSAMA, McTaskManager, SQLAgent$CXDB, SQLAgent$PROD, VeeamCloudSvc, VeeamMountSvc, SQL Backups, mozyprobackup, msftesql$PROD, swi_update_64, EraserSvc11710, MSExchangeMGMT, MSSQL$BKUPEXEC, MSSQL$SQL_2008, MsDtsServer100, MsDtsServer110, SQLSERVERAGENT, VeeamBackupSvc, VeeamBrokerSvc, VeeamDeploySvc, Sophos Agent, svcGenericHost, EPUpdateService, MBEndpointAgent, MSOLAP$SQL_2008, MSSQLFDLauncher, McAfeeFramework, SAVAdminService, SQLAgent$ECWDB2, SQLAgent$SOPHOS, SQLAgent$TPSAMA, VeeamCatalogSvc, MSSQL$SHAREPOINT, MSSQL$SQLEXPRESS, MSSQL$SYSTEM_BGC, NetMsmqActivator, ReportServer$TPS, SepMasterService, TrueKeyScheduler, EPSecurityService, MSOLAP$SYSTEM_BGC, MSSQL$PRACTICEMGT, SQLAgent$BKUPEXEC, SQLAgent$SQL_2008, SQLSafeOLRService, VeeamTransportSvc, Zoolz 2 Service, MSSQL$PRACTTICEBGC, MSSQL$VEEAMSQL2012, Sophos MCS Agent, BackupExecJobEngine, MSSQL$SBSMONITORING, MSSQLFDLauncher$TPS, MSSQLServerADHelper, McAfeeEngineService, OracleClientCache80, ReportServer$TPSAMA, SQLAgent$SHAREPOINT, SQLAgent$SQLEXPRESS, SQLAgent$SYSTEM_BGC, SQLTELEMETRY$ECWDB2, Sophos MCS Client, BackupExecRPCService, MSSQL$VEEAMSQL2008R2, TrueKeyServiceHelper, BackupExecVSSProvider, MSSQL$PROFXENGAGEMENT, ReportServer$SQL_2008, SQLAgent$PRACTTICEBGC, SQLAgent$PRACTTICEMGT, SQLAgent$VEEAMSQL2012, BackupExecAgentBrowser, MSSQLFDLauncher$TPSAMA, MSSQLServerADHelper100, MSSQLServerOLAPService, SQLAgent$SBSMONITORING, VeeamDeploymentService, VeeamHvIntegrationSvc, Acronis VSS Provider, Sophos Clean Service, ReportServer$SYSTEM_BGC, SQLAgent$VEEAMSQL2008R2, Sophos Health Service, Sophos Message Router, MSSQLFDLauncher$SQL_2008, SQLAgent$PROFXENGAGEMENT, SQLsafe Backup Service, SQLsafe Filter Service, SQLAgent$CITRIX_METAFRAME, VeeamEnterpriseManagerSvc, BackupExecAgentAccelerator, MSSQLFDLauncher$SHAREPOINT, MSSQLFDLauncher$SYSTEM_BGC, Sophos Safestore Service, Symantec System Recovery, BackupExecManagementService, Enterprise Client Service, Sophos AutoUpdate Service, BackupExecDeviceMediaService, Sophos Web Control Service, MSSQLFDLauncher$SBSMONITORING, Sophos File Scanner Service, McAfeeFrameworkMcAfeeFramework, MSSQLFDLauncher$PROFXENGAGEMENT, Sophos Device Control Service, Sophos System Protection Service, Veeam Backup Catalog Data Service, https://www.bleepingcomputer.com/news/security/a-closer-look-at-the-robbinhood-ransomware/ Oh, my ..................... 😭 Edited February 7, 2020 by itman
itman 1,801 Posted February 8, 2020 Author Posted February 8, 2020 (edited) For those wondering how the attackers could get around driver signature enforcement protection that has existed since Win 7: Quote Instead, the malware authors chose a different route. The properly signed third party GDRV.SYS driver contains a privilege escalation vulnerability as it allows reading and writing of arbitrary memory. The malware authors abuse this vulnerability in order to (temporarily) disable driver signature enforcement in Windows – on-the-fly, in kernel memory. Once driver signature enforcement is disabled, the attackers are able to load their unsigned malicious driver. Disabling Driver Signature Enforcement The attackers are able to disable driver signature enforcement by changing a single variable (a single byte) that lives in kernel space. On Windows 7 (or older), this variable is called nt!g_CiEnabled (NTOSKRNL.EXE). On Windows 8 and 10, this variable is called ci!g_CiOptions (CI.DLL). In order to resolve the location of this variable, the attackers use a strategy taken from DSEFix. On Windows 8 or 10, the trick starts by loading the standard Windows component CI.DLL as a data library using DONT_RESOLVE_DLL_REFERENCES in their process. Once CI.DLL is loaded, they query the location of CI.DLL in kernel memory via the GetModuleBaseByName function. It uses NtQuerySystemInformation(SystemModuleInformation …) to get the kernel addresses of all loaded kernel modules. https://news.sophos.com/en-us/2020/02/06/living-off-another-land-ransomware-borrows-vulnerable-driver-to-remove-security-software/ Note that this can also be classified as a Win kernel patch protection bypass. Edited February 8, 2020 by itman
Recommended Posts