WannaCry Ransomware Spread Halted by Webroot

WannaCry Ransomware: Webroot protects you.

Ransomware attacks continue to spread around the world this weekend, after the initial damage inflicted on healthcare organizations in Europe on Friday.

The criminals responsible for exploiting the Eternal Blue flaw haven’t yet been identified, but up to 100 countries have hit with WannaCry ransomware, with Russia, Ukraine and Taiwan among the top targets.

The ransomware first appeared in March, and is using the NSA 0-day Eternal Blue and Double Pulsar exploits first made available earlier this year by a group called the Shadow Brokers. The initial spread of the malware was through email, including fake invoices, job offers and other lures with a .zip file that initiates the WannaCry infection. The worm-like Eternal Blue can exploit a flaw in the Server Message Block (SMB) in Microsoft Windows, which can allow remote code execution. This flaw was patched in Microsoft’s March 2017 update cycle, but many organizations had not run the patch or were using unsupported legacy technology like XP.

What’s New

Today, Microsoft has released emergency security patches to defend against the malware for unsupported versions of Windows, including XP and Server 2003.

Overnight and today, it has become clear that a kill switch was included in the code. When it detects a specific web domain exists—created earlier today—it halts the spread of malware. You can learn more at The Register.

As a Webroot customer, are you protected? YES.

Webroot SecureAnywhere does currently protect you from WannaCry ransomware.

In simple terms, although this ransomware is currently causing havoc across the globe, the ransomware itself is similar to what we have seen before. It’s the advanced delivery mechanism that has unfortunately caught many organizations off guard.

In addition to deploying Webroot SecureAnywhere as part of a strong endpoint control strategy, it is essential you continue to keep your systems up-to-date on the latest software versions, and invest in user education on the dangers of phishing, ransomware, social engineering and other common attack vectors.

If you have any questions about your Webroot deployment, reach out to our Support Team now.

And, if you are not a Webroot customer, we encourage you to trial Webroot SecureAnywhere now.

Webroot Incident

Dear Webroot Customers,

You are a critical part of our business. Our Managed Service Providers have asked us to write you to explain why our Webroot SecureAnywhere Business Endpoint Protection experienced performance issues, and what we are doing to resolve those

issues as quickly as possible.

Yesterday, Webroot released a rule that categorized some legitimate files as malware. As a result, multiple legitimate business applications were quarantined and unable to function. This rule change was in effect for 13 minutes on Monday, April 24. To be clear, this rule change was caused by Webroot and not your Managed Service Provider.

Webroot is continuing to work diligently with our partners to restore functionality for our mutual customers. While the false positives that caused the incident have been stopped, we are still working on an automated fix to reverse the files affected. Any

resolution will be released immediately.

Webroot is a trusted partner of many Managed Services Providers and this incident is not representative of our high standards. We always strive to be open and transparent, and we are working tirelessly to fix the issue. Once Webroot has identified the root cause, we will ensure further controls are in place to prevent an

incident like this from happening again.

We apologize for the pain this has caused you. Webroot appreciates your business, and our entire team is dedicated to being your most trusted Partner.

Thank you for your patience as we work through this incident.

Yours sincerely,

Mike Malloy

Executive VP of Product & Strategy

Setup Ubiquiti USG Pro DSL PPPoE Failover Connection

This article will leave out the names of the internet providers to protect against defamation of character issues, but they include a local cable internet provider and a local reseller of DSL connections who also provide T1 lines. Had a client that recently changed from using a bonded T1 line to cable internet in order to get substantially better speeds. During the winter months they experienced the issues that are typical for remote installations of cable – downtime due to issues with the vendors hardware on the poles. After consulting with them, it was decided to go with a DSL PPPoE failover connection as part of some more expansive upgrades. Here is the setup that had to take place on the provided C1100Z modem / router and the Ubiquiti USG Pro.

Setup of C1100Z Modem Router

The modem / router defaults to router mode, which puts all traffic behind a Network Address Translation (NAT) router and allows this DSL vendor their usual practice of monitoring and reselling traffic information. I chose instead to change the settings to make the device into a standard modem in “Transparent Bridge” mode. You will need to contact the DSL vendor in question to get the PPPoE username and password before performing these steps to ensure that you can setup the Ubiquiti USG Pro later. Here are the steps from their website:

1. Open a web browser and go to http://192.168.0.1.

2. Login to your modem by doing the following:

Enter the Administrator Username
Enter the Administrator Password
Select “Apply”.

3. Select “Advanced Setup”.

4.. Select “WAN Settings”.

5. Select “Transparent Bridging”.

6. Select “Tagged-201” for the transport mode.

7. Select “Apply” to save your changes.

Setup of DSL PPPoE Failover Connection on Ubiquiti USG Pro

The second part of this is to setup the failover portion of the Ubiquiti USG Pro to use the PPPoE Connection.

Login to your Ubiquiti Controller
Choose the correct site from the list at the top right
Click on the Devices icon on the left hand column
Click on the Ubiquiti USG Pro device at that site to open up its properties
Click on Configuration
Expand the WAN2 connection and add the username / password acquired from the vendor earlier along with the preferred DNS then make sure to choose the Load Balancing type as Failover then Queue Changes and Apply Changes

This will setup the DSL PPPoE failover connection to be used whenever the primary WAN1 connection goes down. If your company is currently using an unreliable internet provider and need to setup failover, then contact us for assistance.

How to Care for an External Hard Drive

Care for an External Hard Drive At Affordable Computer Repairs and Service we obtain more jobs than we would like from customers desperately requiring data recovery from their non-functioning external hard drive. So many people believe that simply connecting and backing up on a portable hard drive is the complete solution to the safe storage Continue reading “How to Care for an External Hard Drive” →

Screen Time for Kids and Digital Technology

Digital Technology and Screen Time for Kids Should parents limit children’s daily use of digital technology – computers, laptops, TV? The Department of Health screen time recommendations limit the amount of screen time for kids based on the age range of the child. No more than 1 hour a day for children aged 2 to Continue reading “Screen Time for Kids and Digital Technology” →

Setup Azure to Unifi USG IPSec VPN

Had another tech firm that needed some Tier 3 assistance as they were having trouble with their VPN connection. I helped them setup Azure to Unifi USG IPSec VPN to connect their headquarters to the hosted RemoteApps server. This tutorial will go into detail about the creation of this tunnel starting with the Microsoft Azure side first using Resource Manager. It will be using the following parameters:

VNet Name: TestNetwork
Address Space: 10.10.0.0/16
Subnets:
- Primary: 10.10.10.0/24
- GatewaySubnet: 10.10.0.0/24
Resource Group: TestResourceGroup
Location: West US
DNS Server: Azure Default
Gateway Name: TestVPNGateway
Public IP: TestVPNGatewayIP
VPN Type: Route-based
Connection Type: Site-to-site (IPsec)
Gateway Type: VPN
Local Network Gateway Name: TestSite
Local Subnet: 10.20.20.0/24
Connection Name: VPNtoTestSite

Configure an Azure VPN gateway

This part takes the longest, so it should be done first:

Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Virtual Network Gateway” and click on the “Create” button.
Give the Virtual Network Gateway a name
Select matching Region to where Azure resources are located
Leave Gateway & VPN type the defaults
Choose a SKU <- These have changed since the article was created, so my “standard” now is WpnGw1 with Active / Active turned off (this is a good balance of performance and cost)
Choose or create a local network (not covered here) that matches internal resources
Choose or create a Public IP Address
Leave the remaining values as their defaults and then click the “Create” button. (Please note the reminder that this takes 45 minutes to create!)

Configure an Azure Local Network Gateway

This is a reference to your on-premise network so that subnets can pass traffic:

Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Local Network Gateway” and click on the “Create” button.
Give the Local Network Gateway a name
Select matching Region to where Azure resources are located
Specify the external IP address of the local on-premise site
Specify the on-premise address space (subnet)
Leave the remaining values as their defaults and then click the “Create” button.

Configure an Azure VPN Connection

This will create the tunnel from Azure to the on-premise site:

Click on the “+” icon at the top left hand side of the Resource Manager, then search for “Connection” and click on the “Create” button.
Choose “Site-to-site (IPSec)” as the connection type
Give the Connection a name
Select matching Region to where Azure resources are located
Leave the remaining values as their defaults and then click the “OK” button. On the summary screen click on the “OK” button to create the connection.
Choose the newly created Virtual Network Gateway
Choose the newly created Local Network Gateway
Specify a shared key
Leave the remaining values as their defaults and click the “Create” button.

This completes the setup of the Azure side of the VPN tunnel. Now to work on the Ubiquiti USG side.

Configuring an Ubiquiti USG VPN Network

This is a fairly simple process but it has to be precise:

Choose the Current Site from the top right hand side of the portal.
Click on the Settings gears down on the bottom left side of the portal.
Click on Networks then on the “Create New Network” button.
Give the connection a name, choose “Site-to-Site VPN” as the Purpose
Choose “IPSec VPN” as the VPN Type
Choose to Enable this Site-to-Site VPN
Add the Azure subnet under Remote Subnets
Get the newly created Virtual Network Gateway IP address from Azure for the Peer IP
Enter the on-premise external IP address for Local WAN IP
Enter the same shared key as used in the Azure VPN Connection for the Pre-Shared Key
Choose “Azure Dynamic Routing” as the IPSec Profile
Expand Advanced Options
Leave Key Exchange Version, Encryption, Hash & DH Group as default and uncheck the PFS & Dynamic Routing boxes.

That is all there is to it. If you have any difficulties with connection then delete and re-create the Ubiquiti USG side first (those two check boxes at the bottom of the Advanced Options will check themselves again, but don’t be fooled by this quirk in the software). If your company is currently using either Microsoft Azure or Ubiquiti USG routers and would like a VPN created, then contact us for assistance.

Using External Certificate for RemoteApps in .Local Domain

Recently did some Tier 3 support work for another technology company that was trying to setup a Windows Server 2016 RemoteApps server in Azure that would allow connectivity to remote users for their on-premise software. The process started with creating a VPN tunnel between on-premise and Azure, but that is a discussion for a future set of blog posts. Once this connection was in place, the company tried to use an external certificate for RemoteApps setup on the server. This would have been fine if the internal domain had not been a “.local” address scheme. This tutorial assumes that you have already installed Remote Desktop Services on a server and configured it to use the CA provided external certificate.

Change Remote Computer Name

One of the main sticking points that caused issues with security warnings for clients connecting is they would see the warning – “The remote computer could not be authenticated due to problems with its security certificate.” The fix for this has been graciously scripted in PowerShell by someone with the handle “TP” on Technet. The script is called Set-RDPublihedName.ps1 and is used as follows:

Set-RDPublishedName "remote.domain.com"

Proper Active Directory Group

There were then issues with the login process that caused the following error:

Remote Desktop can’t connect to the remote computer “<End Resource Name>” for one of these reasons:

1) Your user account is not authorized to access the RD Gateway “<RD Gateway Server Name>”
2) Your computer is not authorized to access the RD Gateway “<RD Gateway Server Name>”
3) You are using an incompatible authentication method (for example, the RD Gateway might be expecting a smart card but you provided a password)

This was coupled with Security Log messages – “The Network Policy Server was unable to connect to a domain controller in the domain where the account is located. Because of this, authentication and authorization for the RADIUS request could not be performed.” All this turned out to be the RD Gateway was not in the proper Active Directory Group, so added the server to the RAS and IAS Servers group.

Add URL to IIS

There was then an error about not being able to find the computer name, which turned out to be a setting in IIS. Looking under Sites > Default Web Site > RDWeb > Pages click on Application Settings and change the DefaultTSGateway to the URL of the CA external certificate for RemoteApps.

Fixing RS CAP & RAP

Last error that was received was the following:

Remote Desktop can’t connect to the remote computer “computername” for one of these reasons:

1) Your user account is not listed in the RD Gateway’s permission list
2) You might have specified the remote computer in NetBIOS format (for example, computer1), but the RD Gateway is expecting an FQDN or IP address format (for example computer1.fabrikam.com or 157.60.0.1).

This turned out to be related to the RD Client Access Policy (CAP) & Remote Access Policy (RAP) under the RD Gateway Manager tool and DNS. For RD CAP, make sure that Domain Users is listed, and that Client Computer Group membership is blank. FTor RD RAP, make sure that Domain Users is listed, and that it is set to allow connection to Any Network Resource (This allows remote access). For DNS, make sure it contains a Forward Lookup Zone that points to the URL of the CA external certificate for RemoteApps and has an A record for the internal IP address of the RD server.

If your company is currently moving some of your resources to the Azure cloud or wanting to properly setup your RemoteApps server, then contact us for assistance.

Cisco Meraki Ticking Time Bomb

A series of recent security bulletins from Cisco, on February 2nd, detail an issue that has been discovered in several of their devices. Here is a summation:

Cisco ASA Security Appliances

FN-64228 : ASA 5506, ASA 5506W, ASA 5506H, ASA 5508, and ASA 5516 – these models all use the same clock signal part from the same vendor which has been found to degrade over time. After 18 months of continued operation this component will fail and cause the device to stop functioning, no longer boot, and will not be recoverable.

“Customers with affected products that are under warranty or covered by any valid service contract as of November 16, 2016 should go to the Clock Signal Component Issue page and follow the instructions in order to request replacements.” These replacements will be prioritized based on time in operation.

Meraki Router & Wireless APs

Meraki Notification – MX 84 & MS350 Series – these models all use the same clock signal part from the same vendor which has been found to degrade over time. After 18 months of continued operation this component will fail and cause the device to stop functioning, no longer boot, and will not be recoverable.

” Meraki will reach out to customers via email and on the dashboard to arrange replacement and the return of affected units.”

If your company is currently using one of the affected devices and have not heard from your current IT services provider about the replacement schedule, then contact us for assistance.

Information Security while Traveling

The SANS Institute has been putting out the OUCH! newsletter for some time now in a project called Securing the Human. In the most recent Issue, they discuss some best practices and practical advice for traveling. Here are some highlights:

Minimize Possible Losses

Here are a few tips to protect information from the hazards of traveling and possible theft:

Remove any data that is not needed on the device
Use full disk encryption & strong passwords
Perform a complete backup before leaving
Install tracking software on the device
Update OSes and Antivirus

Lost/Stolen Devices

Although crime is more of a factor in some third world nations or those in active conflict, the human element of losing the device is 100x more likely. Keep inventory of your devices before, during and after transporting from one location to another. Do not leave your device in the hotel room, have the hotel front desk put it in their safe or locked administrative offices.

Public WiFi

If you have to connect to the internet in public spaces and/or cannot afford mobile data on your trip, then make sure to do the following:

Never use public computers for sensitive information, especially banking sites
When on public wifi, only surf to sites with HTTPS:// secure connections
Consider connecting to a VPN service to further encrypt communications

If your company is requires traveling or you are planning to remotely work while on vacation, then contact us for assistance. We would be happy to walk you through the full disk encryption process, update / secure your devices and configure a company VPN service to connect to on the go.

Oregon Cyber Task Force – Cyber Attack Mitigation

During a recent briefing from the FBI’s Oregon Cyber Task Force in Medford, OR they detailed best practices and industry standards for cyber attack mitigation. FBI special agents started with information and statistics about the most recent threats giving specifics of how the attacks were executed. Security Architect from the State of Oregon then outlined the specifics of how to mitigate these threats properly. Here is a summation:

Current Threat Landscape

Business Email Compromise (CEO Fraud): Involves cyber criminals posing as business executives at companies that regularly perform wire transfers. After compromising the executive’s email, the criminal requests employees to perform wire transfers to the criminal’s bank account. FBI Internet Crime Complaint Center (IC3) has reported over $3 billion of losses worldwide due to this threat.

Ransomware: Ransomware is a form of malware that targets weaknesses in networks to deny the availability of critical data by encrypting it and demanding a ransom for the encryption keys to decrypt the data. Ransomware is frequently delivered through spear phishing emails to end users.

Point of Sale (PoS) Malware: Cyber criminal steals payment card data by remotely infecting PoS systems with malware without the need to physically access the cards or the devices used to process them. This allows criminals to compromise PoS systems on a large scale with larger victim base.

Insider Threat: An insider is a current or former employee who has access to an organization’s network and intentionally misuses that access to negatively affect the company. IC3 has recorded business losses from insider threat to be between $5,000 to $3 million.

Internet Extortion: Victims are threatened by cyber criminal with Distributed Denial of Service (DDoS) attack that will make access to their e-commerce site severely degraded or impossible if they victim does not pay to appease them. These can be real or fake with price tags in the neighborhood of 50 bitcoin or about $30,000.

Cyber Attack Mitigation

Here is a list of items that will need to be addressed to comprise a complete mitigation plan:

Create company policy in regards to how wire transfers are handled that require verbal or in-person authorization from multiple company executives
Create company policy restricting details that can be shared about job duties and company hierarchy on social media
Review National Institute of Standards and Technology (NIST) Cybersecurity Framework and adopt risk management processes
Create, implement and keep up-to-date an incident response plan
Create company policy and implement lawful network monitoring
Have proactive relationships with law enforcement agencies – silence is letting cyber criminals win

Practical Security Best Practices

Network Segmentation – keep the guest wireless separate from the local network, keep payment processing in its own network and keep web servers in the Demilitarized Zone (DMZ) of the network.
Use firewall access rules, Active Directory Group Policy and physical security measures to limit unsecure access to every segment of your network.
Restrict usage of administrator level access by creating alternative accounts for these purposes that are not used for local login. Keep these accounts monitored.
Implement automated patching and managed virus scanning on all systems. Remove any unsupported / non-updateable software or sytems on the network.
Restrict remote access to the network to specific users and use only secure protocols like RDP through VPN
Conduct periodic testing of all security measures to identify weakness or failing procedures and adjust systems accordingly

Advanced Mitigation Processes

Use multi-factor authentication wherever possible
Establish baseline of applications used then implement application whitelisting
Standardize encryption for data both at-rest and in-transit
Conduct perimeter filtering via Intrusion Detection System (IDS)
Regularly backup system logs in a segregated portion of the network to prevent tampering

If your company is going to use full disk encryption or has compliance requirements that you need consulting for, then contact us for assistance.

Tech Blog

WannaCry Ransomware Spread Halted by Webroot

WannaCry Ransomware: Webroot protects you.

What’s New

As a Webroot customer, are you protected? YES.

Webroot Incident

Setup Ubiquiti USG Pro DSL PPPoE Failover Connection

Setup of C1100Z Modem Router

Setup of DSL PPPoE Failover Connection on Ubiquiti USG Pro

How to Care for an External Hard Drive

Screen Time for Kids and Digital Technology

Setup Azure to Unifi USG IPSec VPN

Configure an Azure VPN gateway

Configure an Azure Local Network Gateway

Configure an Azure VPN Connection

Configuring an Ubiquiti USG VPN Network

Using External Certificate for RemoteApps in .Local Domain

Change Remote Computer Name

Proper Active Directory Group

Add URL to IIS

Fixing RS CAP & RAP

Cisco Meraki Ticking Time Bomb

Cisco ASA Security Appliances

Meraki Router & Wireless APs

Information Security while Traveling

Minimize Possible Losses

Lost/Stolen Devices

Public WiFi

Oregon Cyber Task Force – Cyber Attack Mitigation

Current Threat Landscape

Cyber Attack Mitigation

Practical Security Best Practices

Advanced Mitigation Processes

Recent Posts

Archives

Categories

Tech Blog

WannaCry Ransomware: Webroot protects you.

What’s New

As a Webroot customer, are you protected? YES.

Setup of C1100Z Modem Router

Setup of DSL PPPoE Failover Connection on Ubiquiti USG Pro

Configure an Azure VPN gateway

Configure an Azure Local Network Gateway

Configure an Azure VPN Connection

Configuring an Ubiquiti USG VPN Network

Change Remote Computer Name

Proper Active Directory Group

Add URL to IIS

Fixing RS CAP & RAP

Cisco ASA Security Appliances

Meraki Router & Wireless APs

Minimize Possible Losses

Lost/Stolen Devices

Public WiFi

Current Threat Landscape

Cyber Attack Mitigation

Practical Security Best Practices

Advanced Mitigation Processes

Recent Posts

Archives

Categories

Evaluation Signup