Blog

Yes, Your Hyper-V Host Should be Domain-Joined

There are two Hyper-V-related topics that I simply will not take questions on anymore. It’s not because I don’t like you or because I doubt that you’re truly in crisis. It’s because I believe that the cornucopia of warning signs has existed long enough that you could have easily avoided your predicament and that there will be no positive return on any time invested in helping you continue on your current path. The first of these topics is pass-through disks. Stop using them and you’ll stop having trouble with them; it really is as simple as that. The second is the topic of this post: Hyper-V hosts in workgroup mode. I have tried to find the poisoned wellspring whose judgment-clouding miasma has caused so many administrators to make this ill-fated decision, but have come up empty. I see a great many people explaining how to do it, which lends the practice an undeserved credibility. I realize that I have contributed to that as well; people wanted to know how to do it so I talked about how to do it. However, I can’t find anyone with any recognized level of authority claiming that a Hyper-V host should be excluded from the domain. It is time that we, as a community, start proclaiming that the act of placing Hyper-V hosts in workgroup-mode is poor practice.

Exceptions

Few things in this industry are fixed rules, and the domain vs. workgroup decision for Hyper-V is not one of the few. Here are a few solid reason for not joining a Hyper-V host to a domain:

  • You don’t have a domain. If not having a domain is working for you, I wouldn’t create one just for Hyper-V. Home systems are great examples. Very tiny networks are good examples. Networks where the Hyper-V host is the only Microsoft server system are good examples.
  • All the guests are in a DMZ and you don’t want to connect the physical unit to your internal network. I have done a fair bit with DMZ-based systems in my career and I don’t really believe that this reason is very solid. The Hyper-V host and its guests can be completely isolated from each other so that there is no meaningful risk of having the host exist on a protected internal network while one or more guests live entirely in a DMZ. That said, the principle is not entirely without merit and might be worth it if it makes your security officer happier. However, if the host is in the DMZ, then it must be treated like any other computer in the DMZ; that means that you cannot perform any of the security-reducing tasks that must be done to manage it remotely.
  • You have committed crimes against humanity and are seeking redemption. Remotely managing a non-domain-joined Hyper-V host by anything but RDP is ridiculously complicated and frustrating. It will work one day and not the next, just because. Every time you install an operating system update on any involved system, you’ll wonder if that’s the last time the remote connection will ever work. If you believe that you have done something so terrible as to deserve this fate, then I suppose I shouldn’t hinder you. But, I also shouldn’t help you, because that would defeat the purpose. Looking up the answers on the Internet is cheating. [Note: if you have actually committed crimes against humanity, then you are a bad person. However horrid the experience may be, using workgroup-joined Hyper-V will not absolve anyone of any atrocities.]

Even if one of the above situations applies to you, your solution should be to open the firewall on port 3389 to specified sources, enable Remote Desktop, and work with your host in an RDP session.

Responding to the Common Reasons for Leaving a Hyper-V Host Out of the Domain

Just as it’s tough to find any experts recommending this configuration, it’s surprisingly difficult to find people giving reasons for why they choose this route. I can’t tell if they think that everyone does it that way and that they’re just following the crowd or if they’ve locked themselves onto a particular course of action and reason and logic aren’t playing a part. I did find a couple of explanations, so we’ll tackle them head on.

Myth 1: Leaving a Hyper-V Host Out of the Domain Increases Security

Repeat after me: There is absolutely no condition in which a workgroup configuration is more secure than a domain configuration. It might be possible that your domain’s security is awful, but putting any connected system in a workgroup just makes everything more awful. If you then take the next step of configuring the host so that you can manage it remotely by MMC consoles, you have reduced its security below the already-pitiful protection of the workgroup system.

  • Using the TrustedHosts configuration at all lowers security. What this does is tell the system: “any computer, literally any computer, that claims to have a name on this list — trust it completely”. It is trivially simple to watch computer names travel across a network via broadcast, determine who is communicating with whom, and then spoof a name.
  • Authentication to remote workgroup-connected machines requires the full credential set to be passed to the target system on each connection. If the authentication communication is intercepted, it can be compromised. I don’t dabble much in black/white hat techniques so I wouldn’t know for sure, but I wouldn’t be surprised if simply duplicating the response packet would work just as well since machine authentication has been bypassed with TrustedHosts.
  • That tinkering that you have to do in DCOMCNFG? All of that is reducing security. I don’t even like granting read permissions to Anonymous, and here some of you are giving it administrative privileges.

I’m sure that this myth arose from some well-meaning place. Someone was probably thinking that if their Hyper-V host was compromised and a member of the domain, that the domain would similarly be compromised. Examine that for what it is. If it were true, then no computer should ever be joined to any domain for precisely the same reason. Think of what would happen if any domain member were compromised. The risks are the same. If your workgroup-connected Hyper-V host is operating even one domain-joined virtual machine, then a successful assault against the host makes its domain-joined status irrelevant. Maybe someone believed the opposite — that if the domain were compromised and the Hyper-V host wasn’t part of it, that the Hyper-V host would remain unaffected. All else being equal, cracking domain security is exceedingly more difficult than cracking workgroup security. If someone has broken into your directory, they’ll have your workgroup hosts as soon as they want them, especially if you’ve taken all of the security-reducing steps necessary for remote connectivity.

To expose this as a myth, if I were interviewing a systems administration job candidate and that person said that s/he chooses workgroup mode for anything except roles intentionally exposed directly to the Internet on the grounds that workgroup mode is more secure than domain mode, that person would not be hired. Qualifying it with, “but only for Hyper-V,” is nonsensical.

Myth 2: The Hyper-V Domain Controller Myths

I tackle issues in this category often, and I’m very disheartened that they do not appear to be losing force. If you’re not familiar with what I’m talking about, there are a few myths that involve Hyper-V and domain controllers, with the basic premise of all of them being that if a Hyper-V host cannot reach a domain controller, something critical will not work. Every single one of these notions is false. This is not the post in which I wish to have this discussion, so I’m just going to leave it with a few simple remarks. Hyper-V does not need a domain controller to start. It does not need a domain controller to start its guests. It does not need a domain controller to allow you to log on using local credentials. If the cached credentials feature is enabled in your domain, Hyper-V does not need a domain controller to allow you to log on using those cached credentials. The only time that Hyper-V ever absolutely requires a domain controller is when it is utilizing virtual machines on SMB 3 storage. Leaving the Hyper-V host out of the domain precludes it from using SMB 3 storage at all, so that is not a solution to the problem.

Not-Quite-Myth 3: The DMZ Issue

A lot of people leave Internet-facing systems, such as web servers and Exchange Edge servers, out of the domain. That makes sense because there is a greater-than-insignificant chance that the operating systems on such units could be compromised and any local credential stores cracked. Active communications sessions could also be compromised. Because some of these roles have traversal paths across the firewall into protected networks, compromised credentials or sessions would be extremely dangerous for the environment. In illustration:

Edge Traversal

Edge Traversal

A similar example is the web server/SQL server combination. The web server sits outside the domain but has a tunnel to an internal SQL server. It is definitely a valid security measure to leave these hosts off the domain so that domain credentials are (theoretically) never placed in jeopardy. There is one critical difference between leaving those out of the domain and leaving your Hyper-V host out of the domain: There are additional steps that administrators must take to ensure that no sensitive information is ever left on a web or e-mail host in the DMZ. No one who talks about leaving Hyper-V out of the domain ever brings up the topic of hardening the host against intrusion. All they talk about is crippling the security so that it can be remotely managed.

Unfortunately, some administrators have trouble with the full picture when those DMZ-based systems live on a Hyper-V host. In truth, the diagram is still exactly the same as above, provided that your network segmentation is done correctly. However, those administrators may not mentally separate the Hyper-V host from its guests; to them, a compromise of a guest is also a compromise of the host. This is not how virtualization works.

Myth 4: Workgroup Mode is the Only Way to Protect Hyper-V from Bad Group Policies

It’s no secret that there are a couple of group policies that can cause problems for Hyper-V. That’s hardly a reason to exclude it from the domain. Mitigating facts:

  • As I said before, these policies are not secret. Don’t override the Create symbolic links policy. In fact, most everything under User Rights Assignment is likely to break something somewhere, so just stay out of that branch when setting domain policies. If you’re using iSCSI, don’t enable the policy that forces it to be disabled.
  • Group policy settings that cause problems for Hyper-V cause problems for other things. If you have a policy that breaks Hyper-V, then it’s only a matter of time until it breaks something else. The proper answer is to fix the policy, not go leaving things out of the domain.
  • Active Directory has features that make these problems a non-issue. Look into Organizational Units and, if you’re really stuck, Block Inheritance. Ideally, your Hyper-V hosts will be in their own OU. If you can attach it directly to the root domain OU, that’s best. If you attach it to a sub-OU, that sub-OU can have policies that reverse those coming down from the parent.

Punishing yourself and reducing the security of your Hyper-V host is not the proper way to address a poorly configured domain. All those things do is add to your management burden which reduces the amount of time that you have available to fix your problems.

The Truths of the Domain and Hyper-V

To understand why everything is OK with plugging your Hyper-V host into the domain, you need to dig a bit into Active Directory, workgroup mode, and the basics of virtualization. I’m going to start with virtualization because it is the most important part and it explains why the DMZ issue is mostly a myth.

Virtualization is Segregation

The entire purpose behind placing systems into a DMZ is to keep them as separate as possible from your sensitive systems. Whether people realize it or not, it’s tough to have systems any more separated than they are in the inner space of a hypervisor. I often wish that the term partition hadn’t fallen out of favor in the hypervisor lexicon. This is how you should think of a hypervisor, its management operating system, and its guests:

Hypervisor Partitions

Hypervisor Partitions

These machines share nothing in common except the Hyper-V host. This is virtually like having a lot of physical servers in the same datacenter. This is what virtualization is. Yes, there’s the VMBus and whatnot, so the management operating system isn’t entirely disconnected from the guests, but are there any known exploits of VMBus? I have heard of one “possible” compromise that was patched out. If there are any surviving issues, what difference do you expect domain membership to make? The separation is at least as good as having all of your servers in the same room using common rack, cooling, power, and switching equipment. The following is a perfectly valid configuration:

Domain and DMZ Together

Domain and DMZ Together

In the above image, the only system that isn’t domain-joined is the web server. Its only access to the SQL server is via the firewall. Functionally, this configuration is no different than the Edge image that I showed you earlier. The only difference is that we’re talking about virtual systems instead of physical systems… as far as you know. The Edge system in the first image could very well be a guest of a domain-joined Hyper-V host that is sitting on a protected network. Although it’s not shown in these diagrams, you could certainly use dedicated NICs to host a DMZ-only virtual switch if you want. That way, the networking for the domain systems and the DMZ systems do not need to share any common physical network pathways. However, VLANs should work just as well.

The benefit of this build is that only the web server is exposed to the Internet. You don’t need to place your Hyper-V host in the DMZ at all. Should you decide to go that route anyway, make sure that you don’t make any of the security-lowering settings on the Hyper-V host so that it can be managed remotely. RDP is all you get.

The Reality of Workgroup Mode

Workgroup mode is inherently insecure. It is, in many ways, an anachronism from an era when there were no domain controllers. It survived into the early domain days for many reasons: Microsoft and backward-compatibility were once more or less synonymous terms, there was no hardware-sharing virtualization, and server-class hardware was so expensive that the phrase “entry-level server hardware” wasn’t even coined yet. Many companies just couldn’t afford the multi-thousand dollar expenditure of a domain controller, so they skipped it. Those were also the days when Microsoft’s operating system security deserved most of the ridicule that it received. Even so, Microsoft really only went far enough so as to allow members of a workgroup to share some things, like Word files. If they ever intended for one workgroup system to handle the task of managing or being managed by another, I certainly missed the memo. This was peer-to-peer networking in the truest sense of the word peer.

If all those things that you have to do in order to manage a remote workgroup system feel like dirty hacks, that’s because they are dirty hacks. In today’s era, when Microsoft has worked very hard to repair their security practices and processes, it’s simply not practical to expect them to allow anyone to break down the walls that they have spent so much time building. While they are making a few changes starting in 2016 that will coincidentally improve ease of remote workgroup management in some ways, you will still be enabling security-reducing dirty hacks in order to make Hyper-V host manageable in workgroup mode.

The Reality of the Domain

The domain is the way of the hierarchical Microsoft network. When Hyper-V is present with even one guest, the environment is automatically hierarchical. Nothing else comes close enough to even bother making comparisons. I think everyone knows this part.

With that said, each computer is still its own entity. That includes Hyper-V hosts. I know that this is a conceptual struggling point for a great many people; I have lost track of the number of times I’ve lost my temper trying to explain to vendors that if I place a domain account into the local Administrators group, then the account is a local administrator. I believe that lack of understanding around the Windows security model is what leads many administrators do some of the things that they do. When you join a computer to a domain, its local security is altered in a number of ways; Domain Admins become local admins, so on and so forth. However, local accounts remain. Services continue to run under the “LocalSystem” account. The identity of LocalSystem and other built-in accounts is unaltered. The local Security Accounts Manager (SAM) database remains, with some new entries. Group policies are enforced from the domain, but enforcement utilizes existing mechanisms on the local computer. In short, the local computer does not cease to exist as a unique entity just because it is part of a domain. Local credentials still work. Joining a domain allows you to leave the peer-to-peer network where you must compromise security in order to enable remote management and enter a hierarchical environment where you can easily establish superior/subordinate relationships without giving up any protections.

The Benefits of the Domain and Hyper-V

The summary of all of the above works itself out as several benefits that you get from joining the domain as opposed to leaving it out:

  • Drastically simplified remote management. Everything just works. The pages and pages of instructions and frustration are just not necessary. The firewall ports are automatically open, the accounts are already there, and you don’t have to do much of anything except follow industry best practices.
  • Drastically improved security. The control that your domain can exert over a Hyper-V host is the same as for any other member server. You can have a group policy that locks the host down the moment that it becomes a member. You can add and remove domain accounts and manipulate local accounts without ever directly touching the Hyper-V system again. You can authenticate with expiring Kerberos tickets instead of transmitting user name/password combinations that are valid until someone remembers that they should change passwords occasionally (read: never). When your Hyper-V host accepts a connection from a remote machine, it has the assurance of the domain controller that the remote computer is who it says that it is. Secure DNS registration works.
  • The incentive to use Hyper-V Server or Windows Server Core as opposed to GUI Windows Server is stronger. With so many things being controlled centrally, the need to directly access any individual Hyper-V host is nearly eliminated. We’ve all been told, and should understand, that a GUI-less system provides security benefits. With the plethora of historical evidence indicating that remote management of a workgroup system is going to break at some point, how comfortable will you be if your only control option is RDPing to a command line?
  • All of the features work. Shared Nothing Live Migration requires domain membership. SMB 3 shares require domain membership. Assigning SSL certificates to a domain member from your Enterprise Certificate Authority so that it can participate in secure Hyper-V Replica takes a fraction of the time of any other method.

    Source :
    https://www.altaro.com/hyper-v/domain-joined-hyper-v-host/

One Attacker Outpaces All Others

Starting April 28th, we saw a 30 times increase in cross site scripting attack volume, originating from a single attacker, and targeting over a million WordPress sites. We published research detailing the threat actor and attack volume increase on May 5th. By the time we published, the attack volume had dropped back down to baseline levels.

As of May 11, 2020, attacks by this same threat actor have once again ramped up, and are ongoing. This attacker has now attacked over 1.3 million sites in the past month. As of May 12, 2020, attacks by this threat actor have outpaced all other attacks targeting vulnerabilities across the WordPress ecosystem.

The chart below describes the attack volume we are seeing.

Attacks by this threat actor vs all other sources
These attacks are targeting the same vulnerabilities as the previous wave, with a heavy focus on older XSS vulnerabilities. Additionally, we have been able to link this threat actor to previously described attacks as far back as February 9, 2020.

A History of attacks

Our Threat Intelligence team has been able to link this threat actor to previous attacks with payloads hosted at domains: collectfasttracks[.]com and destinyfernandi[.]com.

Our logs show that this attacker has been ramping up attack volume, sustaining the attack over a two day period, and then reducing volume to a trickle. Each of these surges has progressively increased in volume as the attacker becomes more aggressive.

The earliest attacks containing the destinyfernandi[.]com payload occurred on February 9th and 10th, 2020 and targeted over 200,000 sites with 3.8 million requests.

On March 14 and 15, 2020, attacks containing the collectfasttracks[.]com payload ramped up and targeted over 500,000 sites with more than 7 million requests. That is an approximate doubling in attack volume and number of sites targeted from February to March.

What has changed?

Previous attacks appeared to be spaced roughly a month apart and had much lower volume. Comparatively, the last 30 days have seen 4 attacks of increasing size, cumulatively targeting over 1.3 million sites.

While this threat actor is not targeting different vulnerabilities, the new wave of attacks is hosting the initial malware payload on a different domain:

https://css[.]digestcolect[.]com/stm

The script hosted on the new domain is similar to the one previously hosted at count[.]trackstatisticsss[.]com.

There are a few changes that indicate the attacker is refining their technique. They fixed a bug in the previous version of their PHP backdoor that would have prevented it from being usable on most sites. They have also added two additional backdoor variants, one of which is similar to the backdoor used in a previous attack campaign.

The screenshot below has three chunks of PHP code, each starting with a <?php tag. These are three separate malware variants that the attacker embeds in infected sites. The first loads code from the attacker’s domain and the second and third malware variants allow the attacker to manually execute malicious code by sending a request containing a password and encoded data to execute.

Partially deobfuscated PHP backdoors
*The PHP backdoor variants in this screen shot have been partially deobfuscated for readability

When the older backdoor attempted to execute the payload located at https://stat[.]trackstatisticsss[.]com/n.txt, it tried to use the PHP include() function to include the payload source code. This was a bug because include() expects a file. The attackers should have been including the temporary file containing the payload. We spotted this bug during our previous research but neglected to mention it in our earlier post in order to avoid reporting bugs to malware authors.

The threat actor has now fixed this bug and the current backdoor correctly includes the payload located at http://css[.]digestcolect[.]com/m.txt.

The two additional backdoors, shown in the screenshot above, allow attackers to maintain access to the site, even if the payload URL is taken down due to an abuse complaint.

New Indicators of Compromise

While previous indicators of compromise still apply, the updated final payload also uses the following string to determine whether the site is already infected. It can do this because this is the name of the variable that it attempts to insert into every JavaScript file on the infected site:

mndfhghjf

The presence of the following domains in your database or filesystem should be considered an indicator of compromise:

digestcolect[.]com
trackstatisticsss[.]com
stivenfernando[.]com
collectfasttracks[.]com
destinyfernandi[.]com

As with most attack campaigns, the attacker frequently rotates IP addresses. At the moment, we are seeing attacks from these top 10 attacking IP addresses.

5.187.34.95
91.121.106.106
94.23.3.130
54.36.197.5
46.37.172.252
104.238.222.178
2001:41d0:2:482::
104.236.133.77
2001:41d0:c:c3d::
151.80.25.182

What should I do?

As with the previous attacks, the majority of vulnerabilities being targeted are Cross-Site Scripting (XSS) flaws. The Wordfence Firewall’s built-in XSS protection provides protection from these attacks. Nonetheless, we strongly recommend updating any outdated plugins or themes. We also recommend deactivating and deleting any plugins installed on your WordPress site that have been removed from the official WordPress repository.

If you are running the Wordfence plugin, our scanner will alert you if have any plugins or themes with known vulnerabilities, or that have been removed from the WordPress repository. If you are a Wordfence Premium customer, the real-time blacklist will detect and block access to your site from these malicious IP addresses.

Source :
https://www.wordfence.com/blog/2020/05/one-attacker-rules-them-all/?utm_campaign=Wordfence%20Blog%20Emails&utm_source=hs_email&utm_medium=email&utm_content=87850880&_hsenc=p2ANqtz-9lEkvPw6bT49NMTdlKA-HDGgzWZ9DM4ZTKadCpqSTs0nrKPLtzlaeelrU61WmFcNlwxZHEbmdq55xpk0XSuzvspi6IcA&_hsmi=87850880

Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows

Applies to:

Windows Server 2012, all editions
Windows Server 2012 R2, all editions
Windows Server 2016, all editions
Windows Server 2019, all editions
Windows 7, all editions
Windows 8.1, all editions
Windows 10, all editions

Introduction

This article contains recommendations that may help an administrator determine the cause of potential instability on a computer that is running a supported version of Microsoft Windows when it is used together with antivirus software in an Active Directory domain environment or in a managed business environment.

Note We recommend that you temporarily apply these settings to evaluate system behavior. If your system performance or stability is improved by the recommendations that are made in this article, contact your antivirus software vendor for instructions or for an updated version or settings of the antivirus software.

Important This article contains information that shows how to help lower security settings or how to temporarily turn off security features on a computer. You can make these changes to understand the nature of a specific problem. Before you make these changes, we recommend that you evaluate the risks that are associated with implementing this workaround in your particular environment. If you implement this workaround, take any appropriate additional steps to help protect the computer.

More information

For computers that are running Windows 7 and later versions of Windows

Warning This workaround may make a computer or a network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend this workaround but are providing this information so that you can implement this workaround at your own discretion. Use this workaround at your own risk.

Note Windows Defender automatically performs virus scanning for you, beginning in Windows Server 2016 (and Windows 10). See Configure Windows Defender Antivirus exclusions on Windows Server.

Notes

  • We are aware of the risk of excluding the specific files or folders that are mentioned in this article from scans that are made by your antivirus software. Your system will be safer if you do not exclude any files or folders from scans.
  • When you scan these files, performance and operating system reliability problems may occur because of file locking.
  • Do not exclude any one of these files based on the file name extension. For example, do not exclude all files that have a .dit extension. Microsoft has no control over other files that may use the same extensions as the files that are described in this article.
  • This article provides both file names and folders that can be excluded. All the files and folders that are described in this article are protected by default permissions to allow only SYSTEM and administrator access, and they contain only operating system components. Excluding an entire folder may be simpler but may not provide as much protection as excluding specific files based on file names.

Turn off scanning of Windows Update or Automatic Update related files

  • Turn off scanning of the Windows Update or Automatic Update database file (Datastore.edb). This file is located in the following folder:
    %windir%\SoftwareDistribution\Datastore
  • Turn off scanning of the log files that are located in the following folder:
    %windir%\SoftwareDistribution\Datastore\Logs

    Specifically, exclude the following files:

    • Edb*.jrs
    • Edb.chk
    • Tmp.edb
  • The wildcard character (*) indicates that there may be several files.

Turn off scanning of Windows Security files

  • Add the following files in the %windir%\Security\Database path of the exclusions list:
    • *.edb
    • *.sdb
    • *.log
    • *.chk
    • *.jrs
    • *.xml
    • *.csv
    • *.cmtx

    Note If these files are not excluded, antivirus software may prevent proper access to these files, and security databases can become corrupted. Scanning these files can prevent the files from being used or may prevent a security policy from being applied to the files. These files should not be scanned because antivirus software may not correctly treat them as proprietary database files.

    These are the recommended exclusions. There may be other file types that are not included in this article that should be excluded.

Turn off scanning of Group Policy-related files

  • Group Policy user registry information. These files are located in the following folder:
    %allusersprofile%\

    Specifically, exclude the following file:

    NTUser.pol
  • Group Policy client settings files. These files are located in the following folder:
    %SystemRoot%\System32\GroupPolicy\Machine\
    %SystemRoot%\System32\GroupPolicy\User\

    Specifically, exclude the following files:

    Registry.pol
    Registry.tmp

Turn off scanning of user profile files

  • User registry information and supporting files. The files are located in the following folder:
    userprofile%\

    Specifically, exclude the following files:

    NTUser.dat*

Running antivirus software on domain controllers

Because domain controllers provide an important service to clients, the risk of disruption of their activities from malicious code, from malware, or from a virus must be minimized. Antivirus software is the generally accepted way to reduce the risk of infection. Install and configure antivirus software so that the risk to the domain controller is reduced as much as possible and performance is affected as little as possible. The following list contains recommendations to help you configure and install antivirus software on a Windows Server domain controller.

Warning We recommend that you apply the following specified configuration to a test system to make sure that in your specific environment it does not introduce unexpected factors or compromise the stability of the system. The risk from too much scanning is that files are inappropriately flagged as changed. This causes too much replication in Active Directory. If testing verifies that replication is not affected by the following recommendations, you can apply the antivirus software to the production environment.

Note Specific recommendations from antivirus software vendors may supersede the recommendations in this article.

  • Antivirus software must be installed on all domain controllers in the enterprise. Ideally, try to install such software on all other server and client systems that have to interact with the domain controllers. It is optimal to catch the malware at the earliest point, such as at the firewall or at the client system where the malware is introduced. This prevents the malware from ever reaching the infrastructure systems that the clients depend on.
  • Use a version of antivirus software that is designed to work with Active Directory domain controllers and that uses the correct Application Programming Interfaces (APIs) to access files on the server. Older versions of most vendor software inappropriately change a file's metadata as the file is scanned. This causes the File Replication Service engine to recognize a file change and therefore schedule the file for replication. Newer versions prevent this problem.
    For more information, see the following article in the Microsoft Knowledge Base:

    815263 Antivirus, backup, and disk optimization programs that are compatible with the File Replication Service
  • Do not use a domain controller to browse the Internet or to perform other activities that may introduce malicious code.
  • We recommend that you minimize the workloads on domain controllers. When possible, avoid using domain controllers in a file server role. This lowers virus-scanning activity on file shares and minimizes performance overhead.
  • Do not put Active Directory or FRS database and log files on NTFS file system compressed volumes.

Turn off scanning of Active Directory and Active Directory-related files

  • Exclude the Main NTDS database files. The location of these files is specified in the following registr subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\DSA Database File

    The default location is %windir%\Ntds. Specifically, exclude the following files:

    Ntds.dit
    Ntds.pat
  • Exclude the Active Directory transaction log files. The location of these files is specified in the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Database Log Files Path

    The default location is %windir%\Ntds. Specifically, exclude the following files:

    • EDB*.log
    • Res*.log
    • Edb*.jrs
    • Ntds.pat
  • Exclude the files in the NTDS Working folder that is specified in the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\DSA Working Directory

    Specifically, exclude the following files:

    • Temp.edb
    • Edb.chk

Turn off scanning of SYSVOL files

  • Turn off scanning of files in the File Replication Service (FRS) Working folder that is specified in the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Working Directory

    The default location is %windir%\Ntfrs. Exclude the following files that exist in the folder:

    • edb.chk in the %windir%\Ntfrs\jet\sys folder
    • Ntfrs.jdb in the %windir%\Ntfrs\jet folder
    • *.log in the %windir%\Ntfrs\jet\log folder
  • Turn off scanning of files in the FRS Database Log files that are specified in the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\Currentcontrolset\Services\Ntfrs\Parameters\DB Log File Directory

    The default location is %windir%\Ntfrs. Exclude the following files.

    Note Settings for specific file exclusions is documented here for completeness. By default, these folders allow access only to System and Administrators. Please verify that the correct protections are in place. These folders contain only component working files for FRS and DFSR.

    • Edb*.log (if the registry key is not set)
    • FRS Working Dir\Jet\Log\Edb*.jrs
  • Turn off scanning of the NTFRS Staging folder as specified in the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\Currentcontrolset\Services\NtFrs\Parameters\Replica Sets\GUID\Replica Set Stage

    By default, staging uses the following location:

    %systemroot%\Sysvol\Staging areas
  • Turn off scanning of the DFSR Staging folder as specified in the msDFSR-StagingPath attribute of the object CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DomainControllerName,OU=Domain Controllers,DC=DomainName in AD DS. This attribute contains the path to the actual location that DFS replication uses to stage files. Specifically, exclude the following files:
    • Ntfrs_cmp*.*
    • *.frx
  • Turn off scanning of files in the Sysvol\Sysvol folder or the SYSVOL_DFSR\Sysvol folder.

    The current location of the Sysvol\Sysvol or SYSVOL_DFSR\Sysvol folder and all the subfolders is the file system reparse target of the replica set root. The Sysvol\Sysvol and SYSVOL_DFSR\Sysvol folders use the following locations by default:

    %systemroot%\Sysvol\Domain
    %systemroot%\Sysvol_DFSR\Domain
    The path to the currently active SYSVOL is referenced by the NETLOGON share and can be determined by the  SysVol value name in the following subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Netlogon\Parameters
  • Exclude the following files from this folder and all its subfolders:
    • *.adm
    • *.admx
    • *.adml
    • Registry.pol
    • Registry.tmp
    • *.aas
    • *.inf
    • Scripts.ini
    • *.ins
    • Oscfilter.ini
  • Turn off scanning of files in the FRS Preinstall folder that is in the following location:
    Replica_root\DO_NOT_REMOVE_NtFrs_PreInstall_Directory

    The Preinstall folder is always open when FRS is running.

    Exclude the following files from this folder and all its subfolders:

    • Ntfrs*.*
  • Turn off scanning of files in the DFSR database and working folders. The location is specified by the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\Currentcontrolset\Services\DFSR\Parameters\Replication Groups\GUID\Replica Set Configuration File=Path

    In this registry subkey, "Path" is the path of an XML file that states the name of the Replication Group. In this example, the path would contain "Domain System Volume."

    The default location is the following hidden folder:

    %systemdrive%\System Volume Information\DFSR

    Exclude the following files from this folder and all its subfolders:

    If any one of these folders or files is moved or is put in a different location, scan or exclude the equivalent element.

    • $db_normal$
    • FileIDTable_*
    • SimilarityTable_*
    • *.xml
    • $db_dirty$
    • $db_clean$
    • $db_lost$
    • Dfsr.db
    • Fsr.chk
    • *.frx
    • *.log
    • Fsr*.jrs
    • Tmp.edb

Turn off scanning of DFS files

The same resources that are excluded for a SYSVOL replica set must also be excluded when FRS or DFSR is used to replicate shares that are mapped to the DFS root and link targets on Windows Server 2008 R2-based or Windows Server 2008-based member computers or domain controllers.

Turn off scanning of DHCP files

By default, DHCP files that should be excluded are present in the following folder on the server:

%systemroot%\System32\DHCP

Exclude the following files from this folder and all its subfolders:

  • *.mdb
  • *.pat
  • *.log
  • *.chk
  • *.edb

The location of DHCP files can be changed. To determine the current location of the DHCP files on the server, check the DatabasePath, DhcpLogFilePath, and BackupDatabasePath parameters that are specified in the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DHCPServer\Parameters

Turn off scanning of DNS files

By default, DNS uses the following folder:

%systemroot%\System32\Dns

Exclude the following files from this folder and all its subfolders:

  • *.log
  • *.dns
  • BOOT

Turn off scanning of WINS files

By default, WINS uses the following folder:

%systemroot%\System32\Wins

Exclude the following files from this folder and all its subfolders:

  • *.chk
  • *.log
  • *.mdb

For computers that are running Hyper-V based versions of Windows

In some scenarios, on a Windows Server 2008-based computer that has the Hyper-V role installed or on a Microsoft Hyper-V Server 2008 or on a Microsoft Hyper-V Server 2008 R2-based computer, it may be necessary to configure the real-time scanning component within the antivirus software to exclude files and entire folders. For more information, see the following article in the Microsoft Knowledge Base:

961804 Virtual machines are missing, or error 0x800704C8, 0x80070037, or 0x800703E3 occurs when you try to start or create a virtual machine

Source :
https://support.microsoft.com/en-us/help/822158/virus-scanning-recommendations-for-enterprise-computers

Why Securing Remote Work is Crucial To Ensuring Business Continuity

If you had asked them in January, most organizations would probably have said things were humming along smoothly. Economic growth was strong, and in most cases budgets and security plans were being created and carried out without any need or intention to disrupt the status quo.

Then the entire world changed.

Within the space of a couple weeks, bustling offices were deserted one by one as federal, state, provincial and local governments issued stay-at-home and shelter-in-place orders, and employees boxed up their essential belongings and became part of the rapidly expanding global remote workforce.

While these moves were necessary to stem the spread of COVID-19, the disruption that this sudden change brought with it introduced a set of problems most businesses were ill-equipped to manage.

Companies that previously felt confident in their cybersecurity strategy suddenly found that they didn’t have the capacity or licenses to secure a full-scale mobile workforce. Worse, they needed to manage employees ill-prepared for the transition, many of whom didn’t understand the additional precautions required for safe remote work.

For hackers, though, these are the salad days — and the combination of inexperienced employees and unprepared businesses has brought them out in force. According to Reuters, hacking activity targeting corporations in the U.S. and elsewhere more than doubled in March, and preliminary reports show much the same for April. These threats highlight the urgent need for scalable Secure Remote Access and VPN license capacity to handle the new influx of remote employees while offering the same level of security offered on-prem.

Greater capacity for increased security

To help small- and medium-sized businesses (SMB) handle a rapidly expanding remote workforce, SonicWall has improved the scalability of its SMA 210 and 410 appliances — the 210 can now manage up to 200 remote VPN users, and the 410 can now support 400.

Many enterprises, governments and MSSPs are facing issues with scalability, too. To handle the influx of remote users on large distributed networks, the SonicWall SMA 1000 series allows these organizations to scale up to a million remote VPN users.

To scope which SMA solution is right for your organization, review the SonicWall Secure Mobile Access data sheet.

New public cloud options for the ‘new business normal’

The remote-work revolution coincides with another major shift in how enterprises work — the ongoing cloud transformation. The benefits of moving to a public cloud are myriad — including cost savings, greater agility, maximum uptime and quick and easy deployment.

While SonicWall has long supported private clouds, such as VMware ESXi and Microsoft Hyper-V, SonicWall SMA 500v and SMA 8200v virtual appliances can now be launched on AWS or Microsoft Azure, allowing businesses to realize these benefits at a time when they may need them the most.

Protect remote workers with special offers on SMA, VPN

Right now, budget concerns are at the forefront for many businesses. To help both new and existing customers implement necessary security during this time of crisis, SonicWall has launched several new ‘Work From Home Securely’ promotions to ensure organizations can implement comprehensive security in a cost-effective way.

With SonicWall’s new Work From Home Securely special offers on SMA and other solutions, there’s never been a better time — or a more crucial time — to secure your remote workforce

Source :
https://blog.sonicwall.com/en-us/2020/04/why-securing-remote-work-is-crucial-to-ensuring-business-continuity/

Working at Home? How to Protect Against Phishing During a Pandemic with Cisco Umbrella and OpenDNS

In the wake of this unprecedented global health crisis, cyber attackers have shown no mercy. Earlier this week it was reported that hospitals in the U.S. and Europe, which have been struggling for weeks with an influx of patients, are now dealing with yet another issue: a surge of phishing and ransomware attacks. Even amidst a pandemic, attackers are looking for ways to exploit our most critical institutions and take advantage of vulnerable people with malicious campaigns.

If we look back to the beginning of March, there were relatively few domains that even mentioned the words “COVID” or “Corona.” This is how quickly things have changed over the past month: On Friday April 3, 2020, there were more than 117,000 domains that included these keywords. Of those, more than 75,000 domains were phishing or otherwise malicious in nature. That means at least 65% of all domains with “COVID” or “Corona” are malicious!

Fortunately, the recent global events have demonstrated the resilience of the cybersecurity community to combat new threats. Security professionals have come together quickly to share knowledge and combat these bad actors. I’m proud to share that we have recently made a number of updates to the Cisco Umbrella and OpenDNS services to ensure that we are protecting our users against pandemic themed cyberattacks.

What are you doing to stay safe online at home?

As many of us are now working and spending a lot more time at home, it’s important to think about how you can stay safe online. The good news: Cisco can help.

To protect your family and home network, OpenDNS makes the web a safer place with customizable parental controls and basic security protection. And I should mention that it’s free and simple to get started with at home!

For enterprises, Cisco Umbrella delivers flexible, fast and effective cloud security so you can secure your remote workers, even in a matter of minutes. Cisco Umbrella combines multiple security functions into a single cloud-delivered service — helping you deliver the right level of security anywhere your users work.

How we protect against attacks

Our global cloud infrastructure resolves over 200 billion DNS requests daily, far more than any other security vendor, giving our researchers a unique view of the internet to better identify threats faster. We also have a team of industry-renowned researchers that are constantly finding new ways to uncover fingerprints that attackers leave behind, so that we have visibility into the bad neighborhoods on the internet. If a webpage you are trying to reach is malicious, we will stop the connection at the earliest possible point and give you a block page instead. Easy peasy!

How we block COVID-19 related phishing attacks

Our phishing category leverages indicators derived from multiple sources, including Cisco Talos intelligence, lexical clustering of domains, a natural language processing model, and a spike rank model, which detects sudden spikes of traffic to particular domains. Now, this phishing category also includes a blacklist of vetted COVID-19 URLs, domains, and IP addresses.

We update the phishing category continuously with the latest malicious indicators of compromise as provided via the COVID-19 Cyber Threat Coalition (CTC). This incredible organization is a global volunteer community of 2,500+ security professionals who are focused on stopping these bad actors, by carefully vetting IOCs for the security industry and sharing intelligence in this time of crisis.

All Cisco Umbrella enterprise users and OpenDNS consumer users, are now getting protection from COVID-19 themed cyberattacks.

Click with caution: phishing tips to protect you

Now, more than ever, it is important to stay vigilant online. We see very sophisticated spam in these pandemic themed attacks. Generally speaking, the guidelines for identifying a phish have evolved. Think before you click, and keep in mind these helpful tips:

  • Don’t count on an obvious spelling mistake or grammatical error in order to identify that it’s a phishing email.
  • Avoid strangers by checking names and email addresses.
  • Keep in mind that the email could seemingly come from someone you know. Be wary of unusual requests, even from known senders.
  • Be extra cautious before you click! Hovering over links will not always show you the final destination of a URL. It could issue several redirects, which could result in landing on a different website.
  • Do not trust a website just because you see HTTPS. Threat actors can obtain certificates for creating HTTPS websites.
  • Never give out personal or financial information from an email request.

Get protection at home for free

It only takes one wrong click for cybercriminals to get a foothold into your network. Take steps to ensure that you are safely connecting to the internet.

Get started with the OpenDNS free home service or the Cisco Umbrella free trial today!

You can easily get protection in minutes. Also, you can extend the initial Cisco Umbrella 14-day trial period to 90 days by contacting the Cisco sales team. This offer will be available from now until July 1, 2020. Check out this blog for more information on additional security offerings Cisco is providing for free during this time of need.

Source :
https://umbrella.cisco.com/blog/working-at-home-how-to-protect-against-phishing-during-a-pandemic-with-cisco-umbrella-and-opendns

#CyberSelfCare: Reinvest Your Commute Time with Cybersecurity Training and Education

This is the second article in our set of #CyberSelfCare blogs to help you educate yourself, your coworkers, family, and friends about how to protect their digital presence.

In last week’s blog post, we talked about how to maintain your sanity while working from home. Working from home has a lot of challenges, but it has major benefits, too. When you work from home, your commute time is greatly reduced. Instead of driving your car, riding a train, riding a bike, or walking to the office, all you have to do is turn on your computer and start working. Anyone who has ever had a long commute can appreciate this.

For my first job, I commuted on the train to New York City from a small town in the suburbs. Every day, I spent more than 4 hours on my commute — just traveling to and from the office — and this was before the days of WiFi on public transit. Later, I switched to commuting by car, but with unpredictable traffic, it wasn’t much better. It’s not quite that bad everywhere, but anyone who works in a major metropolitan area like San Francisco, London, or Los Angeles will agree – commuting is exhausting and stressful!

One of the single biggest benefits of working remotely is spending less time traveling to and from the office. If you’re new to working from home, you might find yourself with more time in your day. How will you spend it? With that time, you can focus on things that you might not otherwise have time to do if you were still commuting. Sure, you can spend that extra time sleeping and watching reality shows, but what about setting a goal to invest some of that extra time in cybersecurity training?

In this week’s post, we’ve curated a list of educational resources you can use to learn more about cybersecurity on your own schedule.

Read Cybersecurity Blogs

You’re already reading our blog, so why not start reading a few more? In these blogs, you get immediate access to some of the best minds in cybersecurity research and threat hunting.

  • Krebs on Security is written by Brian Krebs, a former Washington Post reporter and well-known cybersecurity expert.
  • Schneier on Security is written by Bruce Schneier, a Harvard fellow and internationally renowned cybersecurity guru.
  • Cisco Talos Blog is written by one of the largest commercial threat intelligence teams in the world, made up of world-class researchers, analysts and engineers.

Listen to a Security Podcast

If you used to have a long commute, you may already listen to podcasts. Podcasts are a great way to stay up to date on a topic that interests you, and are especially good for listening when taking a walk or during a workout. There’s a podcast for everyone, and that includes people interested in security threats.

  • Talos Takes — join Cisco Talos researchers and analysts as they cover everything from breaking news to the latest trends in cybersecurity.
  • Beers with Talos — listen to the security experts from Talos as they dive into topics like emerging threats, hacking, and other security issues over beers. Shhh… we won’t tell anyone if you enjoy an adult beverage while you listen.
  • Security Stories — enjoy an interview-based podcast full of insights from CISOs and featuring unique, strange, and often hilarious stories about leading cybersecurity efforts in an organization.

Attend a Live or On-Demand Webinar

Our security experts deliver virtual talks on a wide range of topics, with options for technical and non-technical audiences. There are plenty of live and on-demand webinars to choose from, including:

Want to listen to a webinar, but don’t have a lot of time? We have the answer for you! Our Dip in the Deep End series of mini-webinars packs a treasure trove of information into 10 short minutes. Check out some of our recent topics:

Read a Cybersecurity Book

Maybe you prefer reading a book to listening to a podcast or webinar. The Cisco Umbrella team has published a vast library of cybersecurity ebooks for you to read, and they’re short enough to read in one sitting.

Complete a Cyber Ops Certification

If you have a lot of spare time and a desire to challenge yourself, consider the new Cisco Certified Cyber Ops Associate certification. This credential is designed to prepare you for associate-level job roles in a security operations center (SOC).

The program consists of a training course and exam that cover the foundational skills, processes, and knowledge you need to prevent, detect, analyze, and respond to cybersecurity incidents. At the time of writing this blog post, all Cisco certification exams can be completed online from the comfort of your home.

Even if you’re not pursuing a career in cybersecurity operations, a certification is a great option for anyone who wants to do a deeper dive into cybersecurity topics and prove their knowledge to current and future employers.

Knowledge is Power

At Cisco, we’re always learning, and our researchers are pushing the boundaries of threat research and security best practices. It’s harder than ever to keep up with the constant changes in the network security world. Spending just a few minutes per day on continuing education can make you into the trusted cybersecurity expert at your company!

Source :
https://umbrella.cisco.com/blog/cyberselfcare-reinvest-your-commute-time-with-cybersecurity-training-and-education

Zero-Day Warning: It’s Possible to Hack iPhones Just by Sending Emails

Watch out Apple users!

The default mailing app pre-installed on millions of iPhones and iPads has been found vulnerable to two critical flaws that attackers are exploiting in the wild, at least, from the last two years to spy on high-profile victims.

The flaws could eventually let remote hackers secretly take complete control over Apple devices just by sending an email to any targeted individual with his email account logged-in to the vulnerable app.

According to cybersecurity researchers at ZecOps, the bugs in question are remote code execution flaws that reside in the MIME library of Apple's mail app—first, due to an out-of-bounds write bug and second, is a heap overflow issue.

Though both flaws get triggered while processing the content of an email, the second flaw is more dangerous because it can be exploited with 'zero-click,' where no interaction is required from the targeted recipients.

8-Years-Old Apple Zero-Days Exploited in the Wild

According to the researchers, both flaws existed in various models of iPhone and iPad for the last 8 years since the release of iOS 6 and, unfortunately, also affect the current iOS 13.4.1 with no patch yet update available for the regular versions.

What's more worrisome is that multiple groups of attackers are already exploiting these flaws—for at least 2 years as zero-days in the wild—to target individuals from various industries and organizations, MSSPs from Saudi Arabia and Israel, and journalists in Europe.

"With very limited data, we were able to see that at least six organizations were impacted by this vulnerability – and the full scope of abuse of this vulnerability is enormous," the researchers said.

"While ZecOps refrain from attributing these attacks to a specific threat actor, we are aware that at least one 'hackers-for-hire' organization is selling exploits using vulnerabilities that leverage email addresses as the main identifier."

iphone hacking zero-day exploit

According to the researchers, it could be tough for Apple users to know if they were targeted as part of these cyber-attacks because it turns out that attackers delete the malicious email immediately after gaining remote access to the victims' device.

"Noteworthy, although the data confirms that the exploit emails were received and processed by victims' iOS devices, corresponding emails that should have been received and stored on the mail-server were missing. Therefore, we infer that these emails were deleted intentionally as part of an attack's operational security cleanup measures," the researchers said.

"Besides a temporary slowdown of a mobile mail application, users should not observe any other anomalous behavior."

To be noted, on successful exploitation, the vulnerability runs malicious code in the context of the MobileMail or maild application, allowing attackers "to leak, modify, and delete emails."

However, to remotely take full control over the device, attackers need to chain it together with a separate kernel vulnerability.

Though ZecOps hasn't mentioned any detail on what kind of malware attackers have been using to target users, it did believe that attackers are exploiting the flaws in combination with other kernel issues to successfully spy on their victims.

Beware! No Patch Yet Available

Researchers spotted in-the-wild-attacks and discovered the related flaws almost two months ago and reported it to the Apple security team.

At the time of writing, only the beta 13.4.5 version of iOS, released just last week, contains security patches for both zero-day vulnerabilities.

For millions of iPhone and iPad users, a public software patch will soon be available with the release of the upcoming iOS update.

Meanwhile, Apple users are strongly advised to do not to use their smartphones' built-in mail application; instead, temporarily switch to Outlook or Gmail apps.

In a piece of separate news, we today reported about another in-the-wild iPhone hacking campaign where Chinese hackers have been caught targeting Uyghur Muslims with exploit iOS chains and spyware apps.

 

Source :
https://thehackernews.com/2020/04/zero-day-warning-its-possible-to-hack.html

Dell Releases A New Cybersecurity Utility To Detect BIOS Attacks

Computer manufacturing giant Dell has released a new security tool for its commercial customers that aims to protect their computers from stealthy and sophisticated cyberattacks involving the compromise of the BIOS.

Dubbed 'SafeBIOS Events & Indicators of Attack' (IoA), the new endpoint security software is a behavior-based threat detection system that alerts users when BIOS settings of their computers undergo some unusual changes.

BIOS (Basic Input Output System) is a small but highly-privileged program that handles critical operations and starts your computer before handing it over to your operating system.

Protecting the BIOS program is crucial because:

  • Changes to the system BIOS settings could allow malicious software to run during the boot process,
  • Once a hacker takes over the BIOS, he can stealthily control the targeted computer and gain access to the data stored on it,
  • Malware in BIOS remains persistent and doesn't get away even when you format or erase your entire hard drive,
  • Attacks against the BIOS are typically hard to detect because they are invisible to antivirus and other security software installed on the system,
  • With stealth access to one of the compromised systems in an enterprise IT network, sophisticated attackers could move laterally throughout the infrastructure.

According to Dell, the controls offered by SafeBIOS can quickly mitigate the risk of BIOS tampering by bringing them to your attention timely, allowing you to quarantine infected PCs.

"Organizations need the ability to detect when a malicious actor is on the move, altering BIOS configurations on endpoints as part of a larger attack strategy. SafeBIOS now provides the unique ability to generate Indicators of Attack on BIOS configurations, including changes and events that can signal an exploit," David Konetski, VP Client Solutions Group CTO at Dell said in a blog post.

"When BIOS configuration changes are detected that indicate a potential attack, security and IT teams are quickly alerted in their management consoles, allowing for swift isolation and remediation. SafeBIOS Events & IoA provides IT teams the visibility into BIOS configuration changes and analyzes these for potential threats – even during an ongoing attack."

The company says the SafeBIOS Events and Indicators of Attack tool is currently available for Dell commercial PCs through its Dell Trusted Devices solution.

 

Source :
https://thehackernews.com/2020/04/dell-bios-protection.html

https://blog.dellemc.com/en-us/dell-technologies-bolsters-pc-security-todays-remote-workers/

Change your Microsoft Office product key

This article applies to Office Home & Business, Office Professional, and individually purchased Office apps.If you bought multiple copies of Office and used the same Install button to install Office on multiple PCs, activation fails on the other PCs. This happens because each Install button is associated with a unique product key that can only be installed on one PC. To fix this, you can change the product key for the other PCs where you installed Office.

Note: After you change your product key, we recommend that you create a list to manage the product keys that you've installed. To learn how, see Manage multiple one-time-purchase Office installs that use the same Microsoft account.

Select your Office version below.

Office 2019, 2016 Office 2013 Office 365 Command line
  1. Sign in to your Services & subscriptions page with the email and password associated with the Microsoft account that was used to install Office.After you sign in, you should see a list of Office products that are associated with your Microsoft account.
  2. For the first product that's listed on the page, select View product key. Copy or write down the product key. This is likely the product key that was used multiple times to install Office.
  3. Select View product key for the remaining Office products and copy or write them down. These are likely the keys that you'll use to replace the key that was used multiple times.
  4. On a PC where Office activation is failing, open the Command Prompt as described below:
    Windows 10 and Windows 8.1 Windows 7
    1. Select the Start button Windows Start button in Windows 8 and Windows 10 (lower-left corner).
    2. Type Command Prompt.
    3. Right-click the Command Prompt icon, and select Run as administrator.
    1. Select the Start button Windows 7 Start button (lower-left corner).
    2. Right-click Command Prompt and select Run as administrator.
  5. From the drop-down list below, select your Office version and Windows version (32-bit or 64-bit) and run the commands as described.

    Tip: If you get an Input Error: Can not find script file... message, it means that you used the wrong command. Don’t worry, running the wrong command won’t hurt anything. Double-check your Office and Windows versions and try a different command.

    1. Copy the following command, paste the command into the Command Prompt window, and then press Enter. cscript "C:\Program Files\Microsoft Office\Office16\OSPP.VBS" /dstatusThe command prompt displays the last five characters of the product key that was used to install Office on the PC. Our example below uses XXXXX to represent these characters.

      Command Prompt showing last five digits of product key

    2. Copy the following command, paste the command into the Command Prompt window, and replace XXXXX with the last 5 digits of the product key that was shown in the previous step. Press Enter to remove the product key.cscript "C:\Program Files\Microsoft Office\Office16\OSPP.VBS" /unpkey:XXXXX
    3. Copy the following command, paste the command into the Command Prompt window, and replace XXXXX-XXXXX-XXXXX-XXXXX-XXXXX with an unused product key from your list. Press Enter to change the key.cscript "C:\Program Files\Microsoft Office\Office16\OSPP.VBS" /inpkey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

    Tips:

  6. Now start an Office app, such as Word, and select Next to activate Office over the Internet.

  7. Repeat this process for each PC where activation is failing.

Source :
https://support.office.com/en-us/article/change-your-office-product-key-d78cf8f7-239e-4649-b726-3a8d2ceb8c81?omkt=en-001&ui=en-US&rs=en-001&ad=US#ID0EABAAA=Command_line

Beware of ‘Coronavirus Maps’ – It’s a malware infecting PCs to steal passwords

Cybercriminals will stop at nothing to exploit every chance to prey on internet users.

Even the disastrous spread of SARS-COV-II (the virus), which causes COVID-19 (the disease), is becoming an opportunity for them to likewise spread malware or launch cyber attacks.

Reason Cybersecurity recently released a threat analysis report detailing a new attack that takes advantage of internet users' increased craving for information about the novel coronavirus that is wreaking havoc worldwide.

The malware attack specifically aims to target those who are looking for cartographic presentations of the spread of COVID-19 on the Internet, and trickes them to download and run a malicious application that, on its front-end, shows a map loaded from a legit online source but in the background compromises the computer.

New Threat With An Old Malware Component

The latest threat, designed to steal information from unwitting victims, was first spotted by MalwareHunterTeam last week and has now been analyzed by Shai Alfasi, a cybersecurity researcher at Reason Labs.

It involves a malware identified as AZORult, an information-stealing malicious software discovered in 2016. AZORult malware collects information stored in web browsers, particularly cookies, browsing histories, user IDs, passwords, and even cryptocurrency keys.

With these data drawn from browsers, it is possible for cybercriminals to steal credit card numbers, login credentials, and various other sensitive information.

AZORult is reportedly discussed in Russian underground forums as a tool for gathering sensitive data from computers. It comes with a variant that is capable of generating a hidden administrator account in infected computers to enable connections via the remote desktop protocol (RDP).

Sample Analysis

Alfasi provides technical details upon studying the malware, which is embedded in the file, usually named as Corona-virus-Map.com.exe. It's a small Win32 EXE file with a payload size of only around 3.26 MB.

Double-clicking the file opens a window that shows various information about the spread of COVID-19. The centerpiece is a "map of infections" similar to the one hosted by Johns Hopkins University, a legitimate online source to visualize and track reported coronavirus cases in the real-time.

Numbers of confirmed cases in different countries are presented on the left side while stats on deaths and recoveries are on the right. The window appears to be interactive, with tabs for various other related information and links to sources.

It presents a convincing GUI not many would suspect to be harmful. The information presented is not an amalgamation of random data, instead is actual COVID-19 information pooled from the Johns Hopkins website.

To be noted, the original coronavirus map hosted online by Johns Hopkins University or ArcGIS is not infect or backdoored in any way and are safe to visit.

The malicious software utilizes some layers of packing along with a multi-sub-process technique infused to make it challenging for researchers to detect and analyze. Additionally, it employs a task scheduler so it can continue operating.

Signs of Infection

Executing the Corona-virus-Map.com.exe results in the creation of duplicates of the Corona-virus-Map.com.exe file and multiple Corona.exe, Bin.exe, Build.exe, and Windows.Globalization.Fontgroups.exe files.

Corona-virus-Map

Additionally, the malware modifies a handful of registers under ZoneMap and LanguageList. Several mutexes are also created.

Execution of the malware activates the following processes: Bin.exe, Windows.Globalization.Fontgroups.exe, and Corona-virus-Map.com.exe. These attempt to connect to several URLs.

These processes and URLs are only a sample of what the attack entails. There are many other files generated and processes initiated. They create various network communication activities as malware tries to gather different kinds of information.

How the Attack Steals Information

Alfasi presented a detailed account of how he dissected the malware in a blog post on the Reason Security blog. One highlight detail is his analysis of the Bin.exe process with Ollydbg. Accordingly, the process wrote some dynamic link libraries (DLL). The DLL "nss3.dll" caught his attention as it is something he was acquainted with from different actors.

Corona-virus-Map

Alfasi observed a static loading of APIs associated with nss3.dll. These APIs appeared to facilitate the decryption of saved passwords as well as the generation of output data.

This is a common approach used by data thieves. Relatively simple, it only captures the login data from the infected web browser and moves it to the C:\Windows\Temp folder. It's one of the hallmarks of an AZORult attack, wherein the malware extracts data, generates a unique ID of the infected computer, applies XOR encryption, then initiates C2 communication.

The malware makes specific calls in an attempt to steal login data from common online accounts such as Telegram and Steam.

To emphasize, malware execution is the only step needed for it to proceed with its information-stealing processes. Victims don't need to interact with the window or input sensitive information therein.

Cleaning and Prevention

It may sound promotional, but Alfasi suggests Reason Antivirus software as the solution to fix infected devices and prevent further attacks. He is affiliated with Reason Security, after all. Reason is the first to find and scrutinize this new threat, so they can handle it effectively.

Other security firms are likely to have already learned about this threat, since Reason made it public on March 9. Their antiviruses or malware protection tools will have been updated as of publication time.

As such, they may be similarly capable of detecting and preventing the new threat.

The key to removing and stopping the opportunistic "coronavirus map" malware is to have the right malware protection system. It will be challenging to detect it manually, let alone remove the infection without the right software tool.

It may not be enough to be cautious in downloading and running files from the internet, as many tend to be overeager in accessing information about the novel coronavirus nowadays.

The pandemic level dispersion of COVID-19 merits utmost caution not only offline (to avoid contracting the disease) but also online. Cyber attackers are exploiting the popularity of coronavirus-related resources on the web, and many will likely fall prey to the attacks.

Source :
https://thehackernews.com/2020/03/coronavirus-maps-covid-19.html