A Huntress Labs Security Case Study :
Huntress has been hunting malicious actors across 50,000+ user accounts for 1,500+ small businesses enrolled in their Managed Detection and Response (MDR) for Microsoft 365 product.
This is a repost from Huntress Lab’s Security Blog, where they outline three recent cases, and how MDR was able to protect their partner’s accounts. Euclid Networks will begin offering MDR / Microsoft 365 tenant protection in the near future – Contact us today to learn more!
We’ve run into the issue of virtualized Primary Domain Controllers (PDCs) on Windows Server 2016/2019/2022 that fail to properly sync their clocks with global NTP time servers. In the following, we’ll outline the problem and show you how we’ve resolved this IT service issue for our partners.
In a normal functioning domain, properly configured time services are critical to the stability of the network – all domain-joined Windows computers by default will sync their clocks with the PDC.
Without valid time settings, all clocks on your network can be off as much as 8-15 minutes, or more – at best making your users late for meetings – or at worst, teleporting your entire office into an alternate dimension. 0_0;;
To verify Windows Time settings, log on to your domain controller as an administrator, and open an elevated CMD prompt. Once in, the following commands are useful for diagnosing.
Force synchronizing the time ASAP : w32tm /resync /nowait
Check NTP configuration : w32tm /query /configuration
Display time source : w32tm /query /source
Display list of all configured NTP servers and their status : w32tm /query /peers
Display service status (EG : Is time being synced from a CMOS clock, or external NTP server?) : w32tm /query /status
To check your current clock’s offset from a global time server, you can run : w32tm /stripchart /computer:time.windows.com /dataonly which may display something like the following, showing a 39 second offset.
Once you’ve discovered you have a problem, you can force your PDC to grab its time from an external source using :
w32tm.exe /config /manualpeerlist: “us.pool.ntp.org 1.us.pool.ntp.org 2.us.pool.ntp.org 3.us.pool.ntp.org,0x8” /syncfromflags:manual /update and run the above stripchart command once again.
However, on a virtual machine, after running the w32tm /query /source command you may see that your server is still using the VM IC Time Synchronization Provider as the source.
To resolve this and set the time service manually on a Hyper-V VM you have to change the VMICTimeProvider registry value from 1 to 0 by using the following command, allowing you to set a manual time source : reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t reg_dword /d 0 – and restart your time service with net stop w32time then net start w32time.
After doing the above, check your strip chart again to validate your time settings. Much better!
Finally, re-verify you’ve set your PDC’s clock as authoritative for clients with : w32tm /config /reliable:yes – and you’re done! Client machines should sync in the next several minutes, or on next login.
PS – If you bork your configuration, you can always reset it to the default with net stop w32time, w32tm /unregister, w32tm /register, net start w32time – registering and unregistering may require a reboot.
If this helped you, please share, and comment below!
As we onboard any new IT support partner, one of our security and network assessment tasks is to validate a client’s server and disaster recovery environment.
As part of this assessment, we often find a customer will have a single point of failure with their active directory environment – most small businesses don’t have the resources to afford multiple servers, and often times previous systems administrators will have not had the foresight to follow best practices regarding building server resiliency.
One example of a point of failure with a single-server environment that we see all too often is DNS. In many cases, the Primary Domain Controller (PDC) will serve as the sole internal DNS provider. Meaning, if a power outage occurs, or if a PDC goes down for any reason, the entire office will “lose” internet connectivity – often a costly outage until technical help can arrive!
Many of these clients do, however, have secondary “server”-like devices – NAS units, Linux machines, et cetera. While using these as a “backup” DNS provider is not a best practice, we aim to provide the best tech support we can while utilizing resources a client already has in place – thus saving them money!
In the following, we outline steps to convert a Synology NAS device into a backup DNS server for an Active Directory (Windows Server 2019) environment.
1. Install DNS Package on Synology NAS – straightforward, by opening Package Manager.
2. Set up a “Slave Zone” – Within Synology’s DNS manager, create a slave zone, set domain type to Forward Lookup Zone, and enter your PDC’s DNS information.
3. Set up DNS Resolution and forwarding on the NAS – In the below, we have enabled the resolution service, and also forwarders. In our lab, we actually do have a backup local DNS server (192.168.1.8 here), but also forward on DNS requests to Google (8.8.8.8/8.8.6.6) to allow for internet connectivity during PDC downtime.
4. Configure DNS Forwarding on PDC – On your server, open DNS, select your AD’s forward lookup zone, open properties.
4.1 Under Zone Transfers, ensure Allow Zone Transfers is enabled, to servers listed in the DNS Tab.
4.2 Under Notify – Ensure the same setting is enabled.
4.3 Add your Slave Name Server to the list of configured name servers. Important – ensure your server validates, with a green check once its FQDN is added.
5. Verify DNS records and Zone Transfer has completed – On the Synology DNS Manager, under ‘Zones’, select ‘Edit’ and open ‘Resource Record’ you should find propagated records.
Optional but recommended – repeat steps 2-5 for the Reverse Lookup Zone (EG, 1.168.192.in-addr.arpa) and _msdcs.yourlocal.domain. You *do* have a reverse lookup zone configured, don’t you? =)
6. Add your New DNS Server to DHCP – Don’t forget to configure your DHCP leases to include your new backup DNS server!
7. Test out DNS resolution – Finally, test your new server to ensure it’s resolving external domain names correctly, and test a failure of your PDC by taking it offline. Success!
If this writeup has been helpful to you, please share your comments below. And as always, if you’re looking for proactive managed IT service in Atlanta, Euclid is here to help!
Godaddy Domain and Subdomain Forwarding times out without forwarding, unexpectedly, when using a Sonicwall Firewall.
Domain Forwarding is typically used to redirect a user to a different website when they type in a URL in a browser. In this case, the forwarding will time out – with either a browser 404 error – or a CONNECTION_TIMED_OUT message. DNS resolution will work properly – subdomain.domain.com for example will return the correct A record, pointing to Godaddy’s IP addresses.
The domain redirect may work sporadically on some phones or computers where traffic is not directly passing through a Sonicwall firewall.
The reason for the failed domain forwarding is that by default the Sonicwall enables TCP Packet Sequence Randomization which causes Godaddy’s Domain Forwarding service to break. When doing packet analysis in Wireshark, we saw TCP ACK connections out of sequence and dropped connections.
To fix this issue:
Verify you can now access a Domain forwarded address. Note that servers behind the firewall will be slightly more vulnerable to host identification by disabling this TCP Sequence Randomization. But in this case, it would be a fairly targetted attack, so the overall risk is low.
Over the weekend, businesses, institutions, and individuals in 12+ countries have fallen victim to a ransomware program known as “WannaCrypt”, or a variant thereof. For those unaware, WannaCry is fast-spreading form of malware that remotely targets nearby computers running on unpatched or unsupported versions of Windows.
Once infected, computers with this malware being encrypting all the user files they can find on the network, displaying a red ransom note (below) demanding $300 for a decryption key, with the cost increasing as time goes on.
From a technical perspective, the malware spreads via SMB – that is the Server Message Block protocol – typically used by Windows machines to communicate with file systems over a network.
Microsoft released a fix for the exploits (MS17-010, used as a part of its March “Patch Tuesday” release), but unpatched Windows systems remain vulnerable. If you are certain your PCs were updated after March 28th, you should be safe – if you’re unsure and would like to schedule an assessment, please contact us today!
For current partners of Euclid Networks, our proactive monitoring and maintenance software ensures all computers on service plans have critical Microsoft patches regularly reviewed, whitelisted by our partner NOC, and deployed to our client’s machines. We strongly believe in a proactive approach to IT Support, and ensuring software is up to date on business systems is our top priority.
Due to the seriousness of this particular outbreak, we are also manually reviewing our partner’s machines to ensure Microsoft security bulletin MS17-010 has been implemented across the board.
Additionally, our Antivirus partner, Webroot, has announced they have deployed preventative measures for this ransomware – and our partners using Dell Sonicwall Firewalls with Comprehensive Gateway Security Suite licenses should rest assured they have another layer of protection, with Sonicwall having discovered this malware and its variants as of mid-April.
In today’s technology environment, having good preventative measures in place is only the first step to having a comprehensive disaster plan in place.
Ideally, you want to have a 3-2-1 backup strategy in place. This means having at least 3 total copies of your data, 2 of which are local but on different physical devices (such as external storage drives) and 1 of which is offsite – preferably cloud based, with versioning capabilities.
If you don’t have a backup strategy in place, or want to re-evaluate your current plan, please contact Euclid Networks for a consultation!
If you’re unsure of how to assess your current needs, just consider your ability to recover from the following scenarios:
Resilience against all of the above scenarios is not difficult, but it takes careful planning, and continually reassessing your technology environment!
If you own a legal practice, design firm, or other small business and have a decent grasp of technology, you might be tempted to “go it alone” – and handle the technical side of your business yourself. As a business owner, it’s only natural to try and do so – after all, you’re great at what you do! But, don’t think that your ability to solve problems and get things done is enough to keep your computer systems running in all cases – many technological problems can be complex and require a trained professional to solve.
At some point, a network glitch, virus or software issue will threaten to bring your entire business to a halt, costing you what you thought you’d save – or even more – by going it alone. Even a simple problem can require hours of troubleshooting and shift your focus away from other important business tasks, possibly leading to unplanned downtime and unnecessary expenses.
To keep your applications, network, servers, computers and other technology running, it’s worth considering contracting an IT provider. If you don’t have the money to hire a full time IT manager to work on staff, an outside provider can just as aptly handle the day-to-day management of your small business’ technological needs. Euclid Network’s Managed IT Support Plans do just this! A competent IT provider can offer deployment, maintenance and proactive IT management assistance, and will be there when you need solutions for simple but important questions and problems – all for a reasonable fee.
In many cases, an IT provider can help manage your technology better than you – a busy small business owner with many areas to supervise – can. The provider will minimize irksome tech issues that slow productivity and increase costs, and will look for ways to maximize your technological tools so that you can get the most for your IT spend, increase productivity, and help your business grow.
If you’re ready for a new technology partner for your Atlanta based business, give Euclid Networks a call – helping solve your tech problems is our forte!
Part time Desktop/Systems Support Technician needed for small but growing Managed
Service Provider in Atlanta, GA.
The primary role will be providing technical support and research assistance for our
Senior Systems Administrator. Job expectations will include providing courteous and
professional phone and onsite support for end-users, assistance with diagnostics and
support of Windows Server networks, software/hardware troubleshooting & installation,
trouble ticket management, timely remote support, technical documentation, and
providing research assistance and expertise on technical & company projects.
The ideal candidate will be self-starting and require little supervision, be enthusiastic
about working with and learning new technologies, possess excellent verbal and written
communication skills, and have strong attention to detail.
Hours will vary, with an expected average of 20/hours per week. A flexible schedule is
required. Initial schedule will be morning shift, (M – F, 9:00 am-1:00 pm). Opportunity
for the right candidate to become full time as company continues to grow.
For complete job listing and details, please click here to download job description.
Please provide cover letter and resume by emailing
resumes@euclidnet.com – no calls please.
We see this error typically when there is a network connectivity problem between Windows Update or Windows Defender, and Microsoft’s servers. This problem can occur even when the machine in question has access to the internet, if there is a problem with the windows firewall, erroneous proxy settings, or a corrupted Windows Update database.
For Windows 8, or 8.1, Microsoft has an automated tool that can help check on the status of the database, and in some cases resolve the issue outright. This tool can be found at : Microsoft Source : http://windows.microsoft.com/en-us/windows-8/windows-update-error-0x8024401c
If this automatic tool fails to resolve the problem, attempt the following :
As network support providers, we frequently come across come across scenarios where a computer on a business domain has a user profile that has old Offline File Cache data in it. Typically, the user account has moved to a new domain, or is pointing to an old server path, no longer in use. This can happen if the user account has redirected folders enabled on the My Documents or Desktop folders – and the server is no longer in use, or unreachable. This can result in low disk space, or in many cases, duplicate files.
You also may need to delete your offline file cache if you are receiving the error message : “Unable to merge offline changes on \\server_name\share_name. The parameter is incorrect.” in your sync center.
Fortunately, the fix is relatively simple.
Windows 7
Open an elevated command prompt (Start -> type CMD in search box -> Right Click, Run as Administrator)
type : “REG ADD “HKLM\System\CurrentControlSet\Services\CSC\Parameters” /v FormatDatabase /t REG_DWORD /d 1 /f”
Reboot computer – the Client Side Cache will be cleared on your next login.
THIS WILL DELETE ALL CACHED OFFLINE FILES – DATA WILL NOT BE RECOVERABLE, ENSURE YOU HAVE BACKUPS IN PLACE.
Microsoft’s Notes :
Make sure that files are synchronized before you add this registry entry. Otherwise, unsynchronized changes will be lost.
The actual value of the new registry key is ignored.
This registry change requires a restart. When the computer is restarting, the shell will re-initialize the CSC cache, and then delete the registry key if the registry entry exists.
Windoes 7 Reference : http://support.microsoft.com/kb/942974
If you have Windows XP, follow this procedure : http://support.microsoft.com/kb/230738
“Your computer could not be joined to the domain because : An attempt to resolve the DNS name of a domain controller in the domain being joined has failed.”
We run into this error a lot on improperly configured SBS 2008 domain servers. The issue usually has to do with improper DHCP settings on the domain controller – where an external DNS is listed before the domain controller’s IP address in your IPv4 settings. Check that your domain controller is listed as your primary DNS server – for instance DNS settings should look like this on your client computer :
