Blog

As more and more offerings are moved into the cloud under subscription-based licensing, it's both becoming easier for people to take advantage of software that previously may not have been as readily available, and more challenging to find a solution that doesn't involve storing your data one someone else's hardware.

Office 365 is a great example of this as it really does seem like the writing is on the wall for non-subscription licensing of the Office Suite for on-prem installation of much of the server software platform. Granted, Microsoft does make it remarkably easy to just switch over to their platform and to use all the pieces of the software suite that have been designed to seamlessly work together, but there is always a concern (even if it's tiny) that your data is in someone else's hands.

Let's look at cloud hosting from a data availability vantage point instead. The cloud makes it incredibly simple to access the platform from practically anywhere in the world – provided thie service is online. In early February 2020, there was a global outage of the Microsoft Teams platform which brought a lot of this to light. If you were already logged in prior to the outage, you were good to go. Anyone else trying to connect up after the fact was in trouble.

The cause of the outage? https://twitter.com/MSFT365Status/status/1224351597624537088

That's right, even an incredibly large organization that spends billions every year, such as Microsoft, can forget to renew their certificates occasionally. Within a few hours, the renewed certificate was deployed across their vast infrastructure and the Teams service was brought back online. While I doubt that this certificate will ever be forgotten in the future, maybe Microsoft should take the advice of one of the responders to their announcement - https://twitter.com/nunu10000/status/1224353813987053568

As a consumer, my biggest takeaways are this:

The Good: The Office 365 platform is always up-to-date. Any security vulnerabilities are likely patched within a matter of hours rather than waiting on a change window once a month. New features are released regularly.

The Bad: Any outage on-prem and I have a general idea how long things will take to bring it back online. With cloud services, any outage is at the whim of the service provider.

The Ugly: Knowing the above, once you're on-boarded onto a specific platform, it's usually impractical to evacuate that platform and move to another with any sort of regularity. What is the magic number for downtime to make it worth the cost of migrating services? What about if you were unable to easily or cheaply move existing data off that platform during the migration (i.e. online archive/journaling solutions)?


 

I had upgraded an older ESX 5.5 host for a customer to version 6.7. That night, when Veeam backup tried to run, it stated that the remote certificate was invalid.

The easy fix was to go to the Backup Infrastructure in Veeam and find the ESX host. Open the properties of the ESX host and "next" your way through the name and credentials pages. You will eventually get a pop-up about the untrusted certificate and asked if you "want to connect anyway". After accepting, the backups worked again.


 

Finding the right cybersecurity provider is not easy. While some services are like utilities where the options are very similar, the cybersecurity company that you choose is not just a matter of personal preference; you need a reliable provider because the potential risks to your business are much greater. As you consider your options, here are a few things you should consider to determine if a cybersecurity provider will protect your business.

Products

Full Coverage – When it comes to cybersecurity, many products have a specific specialty and only work for a certain kind of device. A good cybersecurity provider should be able to install and support a solution - like Security Information and Event Monitoring (SIEM) - that will aggregate multiple solutions to cover your entire network at a reasonable cost.

Complete Protection – Similar to products that only cover certain devices, there are solutions that only protect from attacks that come from the Internet and the cloud but are limited in detecting internal attacks. Be cautious of this and make sure you find a provider that will support solutions to detect and stop not only external threats but attacks from multiple sources. A layered approach to cybersecurity utilizing Intrusion Prevention Systems, Endpoint Protection, Email Filtering, Web Filtering, and Multi-Factor Authentication with comprehensive monitoring and reporting is ideal to provide complete protection.

Reports

A product like a SIEM will make meeting reporting and compliance requirements much easier. Most products generate reports or alerts from one type of device, which can be a headache when you are looking for a potential problem across your network, but a good SIEM solution can centralize your alerts and remove a lot of false positives. Ideally, your cybersecurity provider can provide guidance on the type of reports and alerts that are needed to satisfy your regulators.

Services

Expertise – Along with the product, cybersecurity providers should offer additional services in the form of expert analysis and guidance. This is a crucial aspect to consider. You might not have a lot of experience on the complexities of cybersecurity, but when a problem or question comes up, will you know what do to? How much pressure can you handle during a security incident? A good cybersecurity company will have a team of experts that understands your network and can customize a solution to meet your needs.

Monitoring and Notifications – A good cybersecurity company can provide 24x7 monitoring and notifications at a reasonable cost. In the past, having staff to monitor security full-time was only an option for the largest companies. Now there are many cybersecurity providers with Security Operations Center (SOC) services to ensure that when any unusual behavior takes place you will be notified. A good cybersecurity provider should provide a written service level agreement (SLA) on their response times.

Conclusion

In order to have the most complete and reliable cybersecurity coverage, you need a cybersecurity provider that will offer you all the product and service positives that we've discussed here. Our company, CoNetrix Technology, checks all the boxes. If you need a good cybersecurity company, contact us today!


 

I came across a system that was running very low on disk space.  Disk cleanup utility scans did not offer much to remove, even with system files checked.  When I looked at the drive with a graphical utility, I could see that a big chunk of space was being consumed in C:\Windows\Installer.

I came across a very useful utility called "PatchCleaner" which can be downloaded free from https://www.homedev.com.au/Free/PatchCleaner .  When it runs, it will give you the results about how many patch files are in use and how many are orphaned. 

From there, you have 2 options in the program.  Either move the unneeded files to another drive or delete them altogether.  I elected to move the patch files first and observed that it moved MSP patch install files.  It freed up many GB of space. 


 

When you enable SSLVPN or HTTP/HTTPS for Management on your WAN interface on a Fortigate, the Fortigate creates global system Local-In policies. These are built-in policies that allow all traffic to the ports and services for SSLVPN and management on the WAN interface by default.

When you put in a Geoblocking rule to block traffic to or from certain countries on your Fortigate under IPv4 Policies, that will not affect these system Local-In policies, even if you put in an IPv4 policy to block all inbound traffic from certain countries. There are a couple of ways to fix this.

The first option is the most restrictive and would probably be the best. This option is to specify only the addresses you want to have access to these services when setting them up, which will prevent a global system Local-In policy from being created. When setting up SSLVPN, instead of allowing access to all hosts, you can specify only the IPs or countries you want to have access to the SSLVPN ports from the outside. (You need to have already setup the address objects for the IPs or countries you want to have access).

To restrict management from the outside, under the WAN interface, simply don't enable HTTP or HTTPS. That will prevent the default Local-In policy from being created.

If you do need external management access, you'll then need to create a custom Local-In policy to allow access on those ports from the network from which you'd like to access it. We typically add the entire CoNetrix external subnet (204.138.94.0/24). Just be sure that this network is also added as a trusted host under your system administrator's account (System -> Administrators)
Custom Local-In polices can only be created via CLI. The following CLI commands will create this custom Local-In policy. These commands assume that you've already created address objects for your WAN IP named Wan1_IP and the CoNetrix subnet named CoNetrix, a service object for your web management port named MGMT, and assume that your WAN interface is wan1.

config firewall local-in-policy
edit 1
set intf "wan1"
set srcaddr "CoNetrix"
set dstaddr "Wan1_IP"
set action accept
set service "MGMT"
set schedule "always"
next
end

The second option is to just leave those default system Local-In policies in place, but then to create custom Local-In polices to block access to SSLVPN and management services from IP addresses or countries that you don't want to have access
Again, since this is a cusom Local-In policy it has to be added via CLI. The following CLI commands also assume that the address and service objects have already been created for your WAN IP, for the countries you want to block, for your SSLVPN and management services, and that the WAN interface is wan1.

config firewall local-in-policy
edit 1
set intf "wan1"
set srcaddr "Blocked Countries"
set dstaddr "Wan1_IP"
set action deny
set service "SSLVPN"
set schedule "always"
next
edit 2
set intf "wan1"
set srcaddr "Blocked Countries"
set dstaddr "Wan1_IP"
set action deny
set service "MGMT"
set schedule "always"
next
end


 

Windows released a tool called Windows Configuration Designer.  This allows you to automate new PC deployments. It can automatically uninstall all of the bloatware installed on the PC, skip the setup screen at the start, join the domain, and install programs. It will also allow you to place the PC in the correct AD organizational unit, allowing GPO's to apply instantly to the PC. After you configure a USB drive, all you have to do is plug in the USB to the new PC, and turn the pc on. WCD will do the rest for you.

https://docs.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-install-icd  


 

By:

CoNetrix recently assisted two customers with targeted phishing attacks in which the attackers attempted to redirect wire transfers. This activity is not new, however, some of the tactics utilized in the attack are noteworthy and provide insight into how organizations can better protect themselves.

How did the attackers gain entry into corporate accounts? 

The entry point for the attackers was corporate email accounts that were exposed to the Internet and accessed using a web browser. The email accounts of the victims were compromised by guessing passwords or reusing previously-compromised passwords. Once access was gained to the email accounts, mailbox rules were configured to direct emails about wire transfers to the "RSS Feeds" folder. This effectively hid the email messages from the victim, while allowing the attacker access to them.

Next, the attacker sent email messages from a domain name similar to the domain name of the compromised email account. The fake messages said the previous email messages concerning money transfers were in error and provided different destination bank routing and account numbers where the money would be accessible by the attackers.

Take steps to mitigate the risks of phishing attacks 

In these cases, the fraudulent email messages were noticed by the recipients and the attacks failed. However, these attacks are routinely successful, and it is necessary to take steps to mitigate the risk, especially when corporate email accounts are accessible using a web browser (e.g. Office 365, Outlook Web Access (OWA), cloud-hosted email, any email account that can be logged into using a web browser and public Internet access).

  • Review your organization's email services to see if Internet-facing email access is enabled. One way to do this is to ask the question, "can we log in to our email accounts using a web browser from any Internet connection (e.g. a coffee shop, at home, at a hotel)?"
  • If Internet-facing email access is enabled disable access for employees who do not need it.
  • For employees who need Internet-facing email access, enable dual-factor authentication.
  • Look for inbox forwarding or redirect rule changes. Logging for these changes can be enabled in the email system's administrative console.
  • On firewall or intrusion prevention devices, enable rules to block traffic that is sourced from countries where known malicious traffic originates.
  • Utilize security event monitoring technologies to monitor web server logs for abnormal login activity.
  • Do not rely solely on email or other electronic communications for initiating or modifying financial transactions. Implement out-of-band approval procedures such that financial transactions and changes to financial processes must be verified using a different form of communication. For example, if a request to change a receiving bank account number is initiated via email, it must be verified via a phone call to a number that is already on file.

 


 

CoNetrix strongly recommends all organizations implement the appropriate updates or mitigation measures for this confirmed vulnerability. CoNetrix has installed updates or implemented the mitigation steps for all affected CoNetrix Technology and Aspire customers.

On December 17, 2019, Citrix announced a directory traversal vulnerability in the Citrix Application Delivery Controller (formerly NetScaler ADC) and Citrix Gateway (formerly NetScaler Gateway) products. If exploited, this vulnerability could allow an unauthenticated attacker to perform arbitrary code execution. This is similar to the Fortigate vulnerability in 2019.

Citrix Security Bulletin: https://support.citrix.com/article/CTX267027, including information about updates to address this vulnerability.

If you cannot install the updates, Citrix has provided some configuration changes that mitigate the issue: https://support.citrix.com/article/CTX267679

How to Quickly Check for this Vulnerability

CoNetrix Security penetration testers were able to confirm the vulnerability by checking the response when browsing to a specific URL (https:// <IP address> /vpn/../vpns/cfg/smb.conf). If you perform the same action and are able to read the smb.conf file, this is confirmation that your system is vulnerable. If the mitigation is in place you will receive a 403 Forbidden error (or potentially some other error message). Also, CoNetrix Technology engineers discovered IDS/IPS signatures for this exploit, but they were not set to 'block' by default by the IDS/IPS vendor.

How to Mitigate this Vulnerability

This is being actively exploited in the wild, so we encourage you to install the fixed versions or apply the recommended mitigation steps as quickly as possible.

Steps to Take Post-Mitigation

Remember, it is important to validate the mitigation is working as expected after applying the configuration.

Citrix and FireEye have developed a scanner to detect if your NetScaler installation has been compromised: https://www.citrix.com/blogs/2020/01/22/citrix-and-fireeye-mandiant-share-forensic-tool-for-cve-2019-19781/

Once the mitigation steps have been implemented, here are a few addtional action items: 

  1. Review the systems active processes and connections to the Internet.
  2. Work with Citrix to review system logs for any potentially suspicious connections attempts.
  3. Work with your IDS and/or firewall vendor to review any potentially suspicious connections attempts.
  4. Check for newly created XML files in the /netscaler/portal/ /var/tmp/netscaler/portal/ directories and sub-directories.
  5. Search for and review any newly created files or scripts. Some exploit intel has indicated Perl scripts being added to the /netscaler/portal/scripts/ directory.
  6. Look for any CRON jobs that have been added to provide an attacker persistence even after the vulnerability is patched.

CoNetrix has installed the update for all CoNetrix Technology and Aspire customers. CoNetrix Security has reviewed data collected during penetration tests from the previous year and notified customers that had this vulnerability. If you are not a CoNetrix customer and would like additional information or assistance with implementing these mitigation steps, we encourage you to contact us.


 

Recently, we had received reports from several external parties that they were unable to send email to conetrix.com addresses. The NDR message reported "MX record not found for conetrix.com".
 
Simple solution, right? Not our problem. I checked several external and global DNS caches including OpenDNS, CloudFlare, and Google, and all successfully resolved records without issue. One aspect that all parties had in common was they were sending email via Gmail, specifically Google Apps accounts. I've got a Google Apps account on a personal domain, so I sent a test email that was delivered without any issues. At this point, we figured it was a transient issue and moved on.
 
Except it wasn't. Over a period of time, it became apparent that this issue was still occurring with fair regularity and that there was something still going on. So what if this actually is our problem? What could any possible solution be?
 
I had taken vacation during the troubleshooting period and came back to the office following my PTO with a mini-epiphany. We host our own DNS records. Could it be possible that these Google Apps customers couldn't connect to our nameservers to resolve the MX records correctly?
 
On a whim, we updated the geoblocking rules on our external firewall cluster to allow inbound DNS requests from any country (not any traffic, only DNS requests). After reaching out to the external parties to send us new email, those messages were successfully delivered and we have not seemed to have had any issues since then.

I don't know why unencrypted Google Apps DNS requests were routed through foreign countries – especially countries that were added to our geoblocking list as housing potentially malicious traffic – but it seems pretty likely that this was the case.
 

 

I came across a GPO that had a few proxy server related settings configured in "Extra Registry Settings" which I needed to remove.  The "Extra Registry Settings" configuration does not show up in GPMC for later OS versions to edit these settings.
 
Powershell can be used to remove "Extra Registry Settings" with the "Remove-GPRegistryValue" command to specify the GPO name, the registry key, and the value.