Tag Archives: attackers

What is the Hyper-V Core Scheduler?

In the past few years, sophisticated attackers have targeted vulnerabilities in CPU acceleration techniques. Cache side-channel attacks represent a significant danger. They magnify on a host running multiple virtual machines. One compromised virtual machine can potentially retrieve information held in cache for a thread owned by another virtual machine. To address such concerns, Microsoft developed its new “HyperClear” technology pack. HyperClear implements multiple mitigation strategies. Most of them work behind the scenes and require no administrative effort or education. However, HyperClear also includes the new “core scheduler”, which might need you to take action.

The Classic Scheduler

Now that Hyper-V has all new schedulers, its original has earned the “classic” label. I wrote an article on that scheduler some time ago. The advanced schedulers do not replace the classic scheduler so much as they hone it. So, you need to understand the classic scheduler in order to understand the core scheduler. A brief recap of the earlier article:

  • You assign a specific number of virtual CPUs to a virtual machine. That sets the upper limit on how many threads the virtual machine can actively run.
  • When a virtual machine assigns a thread to a virtual CPU, Hyper-V finds the next available logical processor to operate it.

To keep it simple, imagine that Hyper-V assigns threads in round-robin fashion. Hyper-V does engage additional heuristics, such as trying to keep a thread with its owned memory in the same NUMA node. It also knows about simultaneous multi-threading (SMT) technologies, including Intel’s Hyper-Threading and AMD’s recent advances. That means that the classic scheduler will try to place threads where they can get the most processing power. Frequently, a thread shares a physical core with a completely unrelated thread — perhaps from a different virtual machine.

Risks with the Classic Scheduler

The classic scheduler poses a cross-virtual machine data security risk. It stems from the architectural nature of SMT: a single physical core can run two threads but has only one cache.

Classic SchedulerIn my research, I discovered several attacks in which one thread reads cached information belonging to the other. I did not find any examples of one thread polluting the others’ data. I also did not see anything explicitly preventing that sort of assault.

On a physically installed operating system, you can mitigate these risks with relative ease by leveraging antimalware and following standard defensive practices. Software developers can make use of fencing techniques to protect their threads’ cached data. Virtual environments make things harder because the guest operating systems and binary instructions have no influence on where the hypervisor places threads.

The Core Scheduler

The core scheduler makes one fairly simple change to close the vulnerability of the classic scheduler: it never assigns threads from more than one virtual machine to any physical core. If it can’t assign a second thread from the same VM to the second logical processor, then the scheduler leaves it empty. Even better, it allows the virtual machine to decide which threads can run together.

Hyper-V Core Scheduler

We will move on through implementation of the scheduler before discussing its impact.

Implementing Hyper-V’s Core Scheduler

The core scheduler has two configuration points:

  1. Configure Hyper-V to use the core scheduler
  2. Configure virtual machines to use two threads per virtual core

Many administrators miss that second step. Without it, a VM will always use only one logical processor on its assigned cores. Each virtual machine has its own independent setting.

We will start by changing the scheduler. You can change the scheduler at a command prompt (cmd or PowerShell) or by using Windows Admin Center.

How to Use the Command Prompt to Enable and Verify the Hyper-V Core Scheduler

For Windows and Hyper-V Server 2019, you do not need to do anything at the hypervisor level. You still need to set the virtual machines. For Windows and Hyper-V Server 2016, you must manually switch the scheduler type.

You can make the change at an elevated command prompt (PowerShell prompt is fine):

Note: if bcdedit does not accept the setting, ensure that you have patched the operating system.

Reboot the host to enact the change. If you want to revert to the classic scheduler, use “classic” instead of “core”. You can also select the “root” scheduler, which is intended for use with Windows 10 and will not be discussed further here.

To verify the scheduler, just run bcdedit by itself and look at the last line:


bcdedit will show the scheduler type by name. It will always appear, even if you disable SMT in the host’s BIOS/UEFI configuration.

How to Use Windows Admin Center to Enable the Hyper-V Core Scheduler

Alternatively, you can use Windows Admin Center to change the scheduler.

  1. Use Windows Admin Center to open the target Hyper-V host.
  2. At the lower left, click Settings. In most browsers, it will hide behind any URL tooltip you might have visible. Move your mouse to the lower left corner and it should reveal itself.
  3. Under Hyper-V Host Settings sub-menu, click General.
  4. Underneath the path options, you will see Hypervisor Scheduler Type. Choose your desired option. If you make a change, WAC will prompt you to reboot the host.

windows admin center

Note: If you do not see an option to change the scheduler, check that:

  • You have a current version of Windows Admin Center
  • The host has SMT enabled
  • The host runs at least Windows Server 2016

The scheduler type can change even if SMT is disabled on the host. However, you will need to use bcdedit to see it (see previous sub-section).

Implementing SMT on Hyper-V Virtual Machines

With the core scheduler enabled, virtual machines can no longer depend on Hyper-V to make the choice to use a core’s second logical processor. Hyper-V will expect virtual machines to decide when to use the SMT capabilities of a core. So, you must enable or disable SMT capabilities on each virtual machine just like you would for a physical host.

Because of the way this technology developed, the defaults and possible settings may seem unintuitive. New in 2019, newly-created virtual machines can automatically detect the SMT status of the host and hypervisor and use that topology. Basically, they act like a physical host that ships with Hyper-Threaded CPUs — they automatically use it. Virtual machines from previous versions need a bit more help.

Every virtual machine has a setting named “HwThreadsPerCore”. The property belongs to the Msvm_ProcessorSettingData CIM class, which connects to the virtual machine via its Msvm_Processor associated instance. You can drill down through the CIM API using the following PowerShell (don’t forget to change the virtual machine name):

The output of the cmdlet will present one line per virtual CPU. If you’re worried that you can only access them via this verbose technique hang in there! I only wanted to show you where this information lives on the system. You have several easier ways to get to and modify the data. I want to finish the explanation first.

The HwThreadsPerCore setting can have three values:

  • 0 means inherit from the host and scheduler topology — limited applicability
  • 1 means 1 thread per core
  • 2 means 2 threads per core

The setting has no other valid values.

A setting of 0 makes everything nice and convenient, but it only works in very specific circumstances. Use the following to determine defaults and setting eligibility:

  • VM config version < 8.0
    • Setting is not present
    • Defaults to 1 if upgraded to VM version 8.x
    • Defaults to 0 if upgraded to VM version 9.0+
  • VM config version 8.x
    • Defaults to 1
    • Cannot use a 0 setting (cannot inherit)
    • Retains its setting if upgraded to VM version 9.0+
  • VM config version 9.x
    • Defaults to 0

I will go over the implications after we talk about checking and changing the setting.

You can see a VM’s configuration version in Hyper-V Manager and PowerShell’s Get-VM :

Hyper-V Manager

The version does affect virtual machine mobility. I will come back to that topic toward the end of the article.

How to Determine a Virtual Machine’s Threads Per Core Count

Fortunately, the built-in Hyper-V PowerShell module provides direct access to the value via the *-VMProcessor cmdlet family. As a bonus, it simplifies the input and output to a single value. Instead of the above, you can simply enter:

If you want to see the value for all VMs:

You can leverage positional parameters and aliases to simplify these for on-the-fly queries:

You can also see the setting in recent version of Hyper-V Manager (Windows Server 2019 and current versions of Windows 10). Look on the NUMA sub-tab of the Processor tab. Find the Hardware threads per core setting:


In Windows Admin Center, access a virtual machine’s Processor tab in its settings. Look for Enable Simultaneous Multithreading (SMT).


If the setting does not appear, then the host does not have SMT enabled.

How to Set a Virtual Machine’s Threads Per Core Count

You can easily change a virtual machine’s hardware thread count. For either the GUI or the PowerShell commands, remember that the virtual machine must be off and you must use one of the following values:

  • 0 = inherit, and only works on 2019+ and current versions of Windows 10 and Windows Server SAC
  • 1 = one thread per hardware core
  • 2 = two threads per hardware core
  • All values above 2 are invalid

To change the setting in the GUI or Windows Admin Center, access the relevant tab as shown in the previous section’s screenshots and modify the setting there. Remember that Windows Admin Center will hide the setting if the host does not have SMT enabled. Windows Admin Center does not allow you to specify a numerical value. If unchecked, it will use a value of 1. If checked, it will use a value of 2 for version 8.x VMs and 0 for version 9.x VMs.

To change the setting in PowerShell:

To change the setting for all VMs in PowerShell:

Note on the cmdlet’s behavior: If the target virtual machine is off, the setting will work silently with any valid value. If the target machine is on and the setting would have no effect, the cmdlet behaves as though it made the change. If the target machine is on and the setting would have made a change, PowerShell will error. You can include the -PassThru parameter to receive the modified vCPU object:

Considerations for Hyper-V’s Core Scheduler

I recommend using the core scheduler in any situation that does not explicitly forbid it. I will not ask you to blindly take my advice, though. The core scheduler’s security implications matter, but you also need to think about scalability, performance, and compatibility.

Security Implications of the Core Scheduler

This one change instantly nullifies several exploits that could cross virtual machines, most notably in the Spectre category. Do not expect it to serve as a magic bullet, however. In particular, remember that an exploit running inside a virtual machine can still try to break other processes in the same virtual machine. By extension, the core scheduler cannot protect against threats running in the management operating system. It effectively guarantees that these exploits cannot cross partition boundaries.

For the highest level of virtual machine security, use the core scheduler in conjunction with other hardening techniques, particularly Shielded VMs.

Scalability Impact of the Core Scheduler

I have spoken with one person who was left with the impression that the core scheduler does not allow for oversubscription. They called into Microsoft support, and the engineer agreed with that assessment. I reviewed Microsoft’s public documentation as it was at the time, and I understand how they reached that conclusion. Rest assured that you can continue to oversubscribe CPU in Hyper-V. The core scheduler prevents threads owned by separate virtual machines from running simultaneously on the same core. When it starts a thread from a different virtual machine on a core, the scheduler performs a complete context switch.

You will have some reduced scalability due to the performance impact, however.

Performance Impact of the Core Scheduler

On paper, the core scheduler presents severe deleterious effects on performance. It reduces the number of possible run locations for any given thread. Synthetic benchmarks also show a noticeable performance reduction when compared to the classic scheduler. A few points:

  • Generic synthetic CPU benchmarks drive hosts to abnormal levels using atypical loads. In simpler terms, they do not predict real-world outcomes.
  • Physical hosts with low CPU utilization will experience no detectable performance hits.
  • Running the core scheduler on a system with SMT enabled will provide better performance than the classic scheduler on the same system with SMT disabled

Your mileage will vary. No one can accurately predict how a general-purpose system will perform after switching to the core scheduler. Even a heavily-laden processor might not lose anything. Remember that, even in the best case, an SMT-enabled core will not provide more than about a 25% improvement over the same core with SMT disabled. In practice, expect no more than a 10% boost. In the simplest terms: switching from the classic scheduler to the core scheduler might reduce how often you enjoy a 10% boost from SMT’s second logical processor. I expect few systems to lose much by switching to the core scheduler.

Some software vendors provide tools that can simulate a real-world load. Where possible, leverage those. However, unless you dedicate an entire host to guests that only operate that software, you still do not have a clear predictor.

Compatibility Concerns with the Core Scheduler

As you saw throughout the implementation section, a virtual machine’s ability to fully utilize the core scheduler depends on its configuration version. That impacts Hyper-V Replica, Live Migration, Quick Migration, virtual machine import, backup, disaster recovery, and anything else that potentially involves hosts with mismatched versions.

Microsoft drew a line with virtual machine version 5.0, which debuted with Windows Server 2012 R2 (and Windows 8.1). Any newer Hyper-V host can operate virtual machines of its version all the way down to version 5.0. On any system, run  Get-VMHostSupportedVersion to see what it can handle. From a 2019 host:

So, you can freely move version 5.0 VMs between a 2012 R2 host and a 2016 host and a 2019 host. But, a VM must be at least version 8.0 to use the core scheduler at all. So, when a v5.0 VM lands on a host running the core scheduler, it cannot use SMT. I did not uncover any problems when testing an SMT-disabled guest on an SMT-enabled host or vice versa. I even set up two nodes in a cluster, one with Hyper-Threading on and the other with Hyper-Threading off, and moved SMT-enabled and SMT-disabled guests between them without trouble.

The final compatibility verdict: running old virtual machine versions on core-scheduled systems means that you lose a bit of density, but they will operate.

Summary of the Core Scheduler

This is a lot of information to digest, so let’s break it down to its simplest components. The core scheduler provides a strong inter-virtual machine barrier against cache side-channel attacks, such as the Spectre variants. Its implementation requires an overall reduction in the ability to use simultaneous multi-threaded (SMT) cores. Most systems will not suffer a meaningful performance penalty. Virtual machines have their own ability to enable or disable SMT when running on a core-scheduled system. All virtual machine versions prior to 8.0 (WS2016/W10 Anniversary) will only use one logical processor per core when running on a core-scheduled host.

Go to Original Article
Author: Eric Siron

WhatsApp vulnerabilities let hackers alter messages

Attackers are able to intercept and manipulate messages in the encrypted messaging app WhatsApp.

According to new research from Check Point, there are WhatsApp vulnerabilities that enable attackers to manipulate and modify messages in both public and private conversations. This type of manipulation could make it easy to continue the spread of misinformation.

WhatsApp, which is owned by Facebook, has over 1.5 billion users who send approximately 65 billion messages daily. The Check Point researchers warned of online scams, rumors and the spread of fake news with a user base that large, and WhatsApp has already been used for a number of these types of scams.

The new WhatsApp vulnerabilities that Check Point outlined in its blog post involve social engineering techniques that can be used to deceive users in three ways: by changing the identity of the sender of a message in a group, changing the text of someone else’s reply message, and by sending a private message to a group member to which replies are made public.

“We believe these vulnerabilities to be of the utmost importance and require attention,” the researchers wrote.

The WhatsApp vulnerabilities have to do with the communications between the mobile version of the application and the desktop version. Check Point was able to discover them by decrypting the communications between the mobile and desktop version.

“By decrypting the WhatsApp communication, we were able to see all the parameters that are actually sent between the mobile version of WhatsApp and the Web version. This allowed us to then be able to manipulate them and start looking for security issues,” the researchers wrote in their blog post detailing the WhatsApp vulnerabilities.

In the first attack outlined by Check Point’s Dikla Barda, Roman Zaikin and Oded Vanunu, hackers can change the identity of a sender in a group message, even if they are not part of the group. The researchers were also able to change the text of the message to something completely different.

In the second attack, a hacker can change someone’s reply to a message. In doing this, “it would be possible to incriminate a person, or close a fraudulent deal,” the Check Point team explained.

In the final attack disclosed, “it is possible to send a message in a group chat that only a specific person will see, though if he replies to this message, the entire group will see his reply.” This means that the person who responds could reveal information to the group that he did not intend to.

Check Point said it disclosed these vulnerabilities to WhatsApp before making them public.

In other news

  • Computers at the office of PGA America have reportedly been infected with ransomware. According to a report from Golfweek, employees of the golf organization noticed the infection earlier this week when a ransom note appeared on their screens when they tried to access the affected files. “Your network has been penetrated. All files on each host in the network have been encrypted with a strong algorythm (sic),” the note said, according to Golfweek. The files contained information for the PGA Championship at Bellerive and the Ryder Cup in France, including “extensive” promotional materials. According to the Golfweek report, no specific ransom amount was demanded, though the hacker included a bitcoin wallet number.
  • Microsoft may be adding a new security feature to Windows 10 called “InPrivate Desktop.” According to a report from Bleeping Computer, the feature acts like a “throwaway sandbox for secure, one-time execution of untrusted software” and will only be available on Windows 10 Enterprise. Bleeping Computer became aware of this previously undisclosed feature through a Windows 10 Insider Feedback Hub quest and said that it will enable “administrators to run untrusted executables in a secure sandbox without fear that it can make any changes to the operating system or system’s files.” The Feedback Hub said it is an “in-box, speedy VM that is recycled when you close” the application, according to the report. There are no details yet about when this feature may be rolled out.
  • Comcast Xfinity reportedly exposed personal data of over 26.5 million of its customers. Security researcher Ryan Stevenson discovered two previously unreported vulnerabilities in Comcast Xfinity’s customer portals and through those vulnerabilities, partial home addresses and Social Security numbers of Comcast customers were exposed. The first vulnerability could be exploited by refreshing an in-home authentication page that lets users pay their bills without signing into their accounts. Through this, hackers could have figured out the customer’s IP address and partial home address. The second vulnerability was on a sign-up page for Comcast’s Authorized Dealer and revealed the last four digits of a customer’s SSN. There is no evidence yet that the information was actually stolen, and Comcast patched the vulnerabilities after Stevenson reported them.

Undocumented Word feature could lead to system information theft

Researchers have found an undocumented Microsoft Word feature that can be abused by attackers in order to obtain the system information of a victim.

The undocumented Word feature was detailed by Alexander Liskin, heuristic detection group manager, Anton Ivanov, senior malware analyst, and Andrey Kryukov, security researcher at Kaspersky Lab. A hidden feature known only as was discovered by the Kaspersky team in malicious attachments contained in suspected phishing emails. The field contained links formatted in Unicode rather than the intended ASCII format, which are ignored by Word and are used by the attackers to send GET requests to malicious domains.

According to the researchers, targeted attacks using the undocumented Word feature can be very hard to detect because malicious documents “contained no macros, exploits or any other active content.”

“A close inspection revealed that [the malicious documents] contained several links to PHP scripts located on third-party web resources. When we attempted to open these files in Microsoft Word, we found that the application addressed one of the links. As a result, the attackers received information about the software installed on the computer,” the Kaspersky researchers wrote in their analysis. “This code effectively sent information about the software installed on the victim machine to the attackers, including info about which version of Microsoft Office was installed.”

The researchers noted that the undocumented Word feature was present in versions of Office for Windows, iOS and Android, but said other productivity suites like LibreOffice and OpenOffice did not call the malicious links. The research team also noted there is no official documentation for the field.

Avihai Ben-Yosef, CTO of Cymulate, said the system information theft could likely be just the first stage of an attack.

“[Knowing the] version of Office will allow hackers to identify whether or not the client that opened the Word document is vulnerable to known exploits that could be used to hack them. Imagine that hackers are building a database by simply sending thousands of emails to users and collecting information about those that opened the document,” Ben-Yosef told SearchSecurity. “Hackers will know if their Office version is vulnerable to a specific exploit and will be able to trigger an attack when they feel like it.”

Intelligence is king in cyberattacks as well as cyberdefense.
Marina Kidronhead of the Skybox Security Research Lab

Marina Kidron, head of the Skybox Security Research Lab, said spear phishing campaigns, like the ones abusing this undocumented Word feature, may not always present an imminent threat to an organization, this type of system information theft “could make or break a targeted attack.

“Intelligence is king in cyberattacks as well as cyberdefense. Targeted attacks are traditionally more complex than distributed attacks, such as ransomware, because they have — and need — more context on the environment they’re working in. With more context, attacks can be crafted to have better chances of evading detection,” Kidron told SearchSecurity. “This can render signature-based intrusion detection systems ineffective and raises the importance of good cyberhygiene stalwarts like network segmentation and vulnerability management. If an attack slips through the intrusion detection system, you need to be sure vulnerabilities with active or available exploits have been mitigated, access is limited and controls are in place to prevent the spread of the attack.”

Microsoft expands Office 365 MFA support, but snags remain

attackers another avenue to break in and wreak havoc on the enterprise.

Multifactor authentication (MFA) adds another layer of security to protect organizations against data breaches — even when passwords fall into the wrong hands. Because of the added exposure that comes with using a cloud service, more administrators have established an Office 365 MFA setup to prevent outsiders from gaining access.

Microsoft added support for multifactor authentication to Azure Active Directory (AD) PowerShell, version 1.0, in 2015; however, the feature lacked the ability to connect to other Office 365 services with MFA-enabled accounts. The company updated the module to version 2.0 in 2017 to provide that functionality. Each Office 365 service requires its own module, listed below:

Complications with PowerShell modules

The Office 365 MFA update helps secure access to cloud services, but there is a downside. Because every service has its own module, they do not share tokens. When an authorization against Exchange Online with an MFA-enabled account occurs, the other modules cannot reuse the authorization token. To connect to other services, the authorization process must repeat. Organizations with more service-oriented management roles likely will not encounter this issue; for example, some Exchange administrators are more likely to connect only to Exchange Online and occasionally to Azure Active Directory.

Additionally, the newer module’s cmdlets used to connect to the Office 365 service with an MFA-enabled account differ from their regular cmdlet counterparts — and the options are inconsistent. This is contrary to version 1.0 of the Azure Active Directory module, which allows the use of the same cmdlet (Connect-MsolService) for both MFA and non-MFA accounts. Version 1.0 also permits the specification of the Credentials parameter in both scenarios, after which the module checks if additional MFA authentication is required.

Here is a short overview of the cmdlets that connect to various Office 365 services with non-MFA-enabled and MFA-enabled accounts:


Non-MFA account

MFA-enabled account

Exchange Online

 -ConnectionUri https://outlook.office365.com/
 -Credential $Credentials
 -Authentication Basic
-SessionOption $SessionOptions

 -ConnectionUri https://outlook.office365.com/
 -UserPrincipalName $UserID

Skype for Business Online

 -Credential $Credentials

New-CsOnlineSession -Username $UserID

SharePoint Online

 -url $TenantURL
 -Credential $Credentials

 -url $TenantURL

Azure Active Directory, module version 1.x

Connect-MsolService -Credential $Credential

 -Credential $Credential

Azure Active Directory, module version 2.x

Connect-AzureAD -Credential $Credential


As the table shows, it’s not always an option to provide credentials directly to the module. If an administrator omits the Credentials parameter when connecting to Skype for Business Online, for example, the Office 365 MFA authentication process gets triggered. Using that same module, it can be confusing when a logon fails after specifying the Credential parameter for an MFA-enabled account. There isn’t an ability to provide additional session options through the Exchange Online MFA PowerShell module, such as timeout settings or proxy configuration. For the proxy, the module uses the system Internet Explorer configuration.

Another item to be aware of: If the PowerShell session times out, you need to fully reconnect and go through MFA approval process again. With version 1.0 of the Azure Active Directory module, PowerShell would just reconnect with the cached credentials when entering a cmdlet.

Script simplifies the Office 365 MFA connection process

It can be difficult to remember how to connect to different Office 365 services, especially with newer MFA authentication variations. To make it easier, add the following script to the PowerShell profile.

The script detects the installed modules and shares a link to download any missing modules. It also detects MFA-supported modules and prompts for credentials, and asks if the module should use MFA when authenticating.

PowerShell script
Use a PowerShell script to connect to different Office 365 services with the same credentials.

Microsoft enhances other authentication offerings

Microsoft also made other authentication-focused updates. The company continues to improve the Authenticator app, which can authorize MFA requests for non-Microsoft accounts, such as Facebook and WordPress. More recently, Microsoft added a feature called Phone Sign-In, which lets a trusted device approve access to Microsoft accounts. This streamlines the authentication process and enables users to approve or deny authorization requests with their phones.

Powered by WPeMatico