Alert icon Keyboard navigation enabled.
Alert icon TAB or Shift+TAB to navigate across. Down ↓ to open menu. ESC to close menu.
Alert icon Down ↓ to select section. Right → to activate. Up ↑ / Down ↓ / Tab to traverse all. ESC to exit.
BeyondTrust
Skip to content Use space or enter to skip.

What can we help you find today?

Instant Results
  • Website Results
  • Technical Documentation

Filter Options

Focus your search

Filtering by

Your recent searches:

Contact Us Chat with Sales Get Support
  • English
  • Deutsch
  • français
  • español
  • 한국어
  • português
  • Home
  • Resources
  • Blog
  • Unsecured PCs Can Put Your Critical Infrastructure at Risk current page
Link copied

Unsecured PCs Can Put Your Critical Infrastructure at Risk

Oct 20, 2017
Author:
Russell Smith Bio Pic 2021 Square
Russell Smith
IT Consultant & Security MVP
Blog banner default
Unsecured PCs Can Put Your Critical Infrastructure at Risk
Russell Smith Bio Pic 2021 Square
Russell Smith
IT Consultant & Security MVP

In an ideal world, critical IT systems should never rely on the security of lesser devices. But in practice, computer networks are complicated and many dependencies exist, some of which are more desirable than others, and eliminating all unwanted dependencies is a difficult task.

Windows member servers – i.e. those joined to an Active Directory (AD) domain – and workstations depend on domain controllers (DCs) to manage certain aspects of their security. This is a necessary dependency where a less important device relies on a more critical system.

Unwanted security dependencies tend to appear on networks unexpectedly. For instance, a PC becomes infected with a virus because the user was tricked into running a malicious executable, and an unpatched vulnerability is exploited. As a result, the Exchange Server is also infected and subsequently shut down by the virus. Though we can argue both the PC and server should have been patched, in this situation the server was unlikely to have been infected if the PC had remained secure.

I was recently reminded about the DNS Changer trojan that first appeared in 2008 and mutated into various different forms. The virus attempts to change a PC’s DNS settings to redirect internet traffic, and failing that, scans the local network in an effort to discover the admin credentials and change the DNS configuration of gateway routers. This is an unfortunate example of where a critical network device becomes dependent on a PC for its security, in turn compromising the integrity of all devices connected to the router. Another variant of the trojan sets up a DHCP server on infected PCs and attempts to intercept DHCP requests on the local network and respond with bogus DNS settings to devices looking for valid DNS configuration.

To change DNS configuration on Windows, administrative rights are required; so a standard user account stops DNS Changer dead in its tracks. Secondly, with application allow listing in place, DNS Changer wouldn’t be able to run at all, preventing it from scanning the network for vulnerable devices.

While SANS Internet Storm Center issued reactive advice at the time to block traffic to IP addresses known to host the malicious DNS servers, a proactive approach to prevent PCs being infected in the first place is always preferable. Antivirus should also be capable of stopping DNS Changer, but why rely solely on AV to protect your systems, especially with the speed at which malware mutates and sophisticated techniques used to evade detection.

Users often think that what happens on their network-connected PC or other device cannot affect the security of other systems, let alone critical servers and network hardware. But as you’ve read in this blog post, users and management should understand that once a device is connected to the network it does not exist in isolation, and least privilege security and application allow listing technologies, are needed to protect the IT infrastructure at large.

Latest Posts
  • Hooked on Identity (Part 2): Abusing OAuth Trust Boundaries in Okta
    Jun 12, 2026 Hooked on Identity (Part 2): Abusing OAuth Trust Boundaries in Okta
    Blog
    7m
  • Hooked on Identity: Abusing SAML Assertion Inline Hooks in Okta
    Jun 9, 2026 Hooked on Identity: Abusing SAML Assertion Inline Hooks in Okta
    Blog
    6m
  • Joining Project Glasswing: Securing the Privilege Backbone of the AI Era
    Jun 8, 2026 Joining Project Glasswing: Securing the Privilege Backbone of the AI Era
    Blog
    5m
  • The Most Common & Most Dangerous Types of Shadow IT
    Jun 5, 2026 The Most Common & Most Dangerous Types of Shadow IT
    Blog
    19m
  • 14 Password Management Best Practices
    May 28, 2026 14 Password Management Best Practices
    Blog
    12m
Related
  • BeyondTrust Identity Security Insights: 2024 Wins and the Roadmap to Advanced Identity Security Posture Management
    Mar 5, 2025 BeyondTrust Identity Security Insights: 2024 Wins and the Roadmap to Advanced Identity Security Posture Management
    Blog
    9m
  • Extending Password Policy To UNIX and Linux
    Sep 21, 2011 Extending Password Policy To UNIX and Linux
    Blog
    1m
Share this Article
  • Link
Stay up to Date
Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

Keep up with BeyondTrust

Customer Support Get Started
  • LinkedIn
  • X
  • Facebook
  • Instagram
  • Add BeyondTrust as a preferred source on Google
  • Privacy
  • Security
  • Manage Cookies
  • Do Not Sell My Data
  • WEEE Compliance

Copyright © 2003 — 2026 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.

Prefers reduced motion setting detected. Animations will now be reduced as a result.