If your Automatic Tank Gauge (ATG) can be reached from the open internet, assume someone will try it. A recent federal advisory warned that attackers are actively targeting internet-exposed ATG systems, and Shadowserver tracking showed over 1,000 exposed devices—909 in the U.S. These aren’t “IT problems.” ATGs sit close to safety, compliance, and real money. And yes—attackers can change what you see on the screen without changing what’s actually in the tank, which still creates regulatory and operational risk.
What an ATG really does (and why exposure changes the risk)
An Automatic Tank Gauge (ATG) system is the “truth source” a lot of station decisions get built on. It’s an electronic monitoring device that tracks what’s happening inside underground storage tanks—fuel (and sometimes chemicals), hour by hour—without someone physically sticking a tank. Federal reporting describes ATGs as tools that automate inventory control, environmental leak detection, and regulatory compliance .
That matters because ATGs don’t sit in a back-office spreadsheet world. They sit next to safety controls, environmental obligations, and daily operations.
The job an ATG is doing at your site
Most operators experience the ATG as a screen and a few reports. Behind that, it’s supporting things like:
- Inventory monitoring: tank levels, product volume, and changes over time (what you think you have vs. what you sold).
- Leak detection: catching patterns that can signal a leak (or at least “something’s off”) so you can investigate before it becomes a bigger event.
- Compliance and documentation: data you may rely on for regulators, inspections, and internal audits.
These systems show up at gas stations all the time, but the same tech also shows up in industrial environments that store chemicals . In both places, the ATG becomes a decision engine: order fuel, dispatch a tech, respond to an alarm, document a finding.
Why “publicly reachable” is the danger line
Here’s the shift: when an ATG is internet-exposed, it stops being “a local operations tool” and becomes an online target.
Threat actors don’t need to know your business hours. They can scan the internet 24/7 looking for ATG systems answering on specific ports—Shadowserver reported 1,061 IPs seen on port 10001/tcp, with 909 in the U.S. . That’s the part many operators miss: the attacker doesn’t have to find you. Exposure makes you findable.
Once an ATG is reachable from the open internet, the risk isn’t abstract “cyber” stuff. It’s that someone can get close enough to interfere with the data you depend on for leak detection and operational choices—without stepping on your lot.
If you’ve ever set up remote access “just so the vendor can check something,” and it never got turned off, you’ve seen how this happens. One change in connectivity can quietly turn an ATG security issue into a daily, always-on risk.
How attackers are getting in: the short list that keeps working
Once an Automatic Tank Gauge (ATG) system is reachable remotely, attackers don’t need a complicated plan. The federal advisory summary was blunt: they’re exploiting a handful of repeatable weaknesses—then using that access to modify systems through command execution .
Here’s what those paths mean in plain operator language.
1) Hardcoded credentials
Hardcoded credentials are usernames/passwords baked into the device or software. You can’t fully control them, and attackers trade them around. If your ATG model has known hardcoded logins, “changing the password” might not close the door the way you expect .
2) Default or weak passwords
This one is painfully common: the ATG (or its remote access gateway) still has a factory password, or something easy to guess. A May report cited breaches where attackers got in with weak or nonexistent passwords .
3) Authentication bypass
An authentication bypass is when a flaw lets someone access pages or functions without a valid login—like walking around the lock instead of picking it .
4) SQL injection
If the ATG interface talks to a database (logs, users, settings), SQL injection is a bug where an attacker can type “special” input that the system accidentally treats as a database command. That can expose data or change records, depending on the weakness .
5) OS command execution
OS command execution is the scary one because it can jump from “I can view the ATG” to “I can run commands on it.” The advisory notes attackers compromising internet-exposed ATG systems and then modifying them through command execution .
6) Privilege escalation
Even if an attacker starts with low-level access, privilege escalation is how they become “admin.” After that, changing configuration, users, alerts, and services gets a lot easier .
The “temporary vendor access” trap
A lot of exposure starts with a practical decision: a vendor needs remote access to troubleshoot, so someone opens a port or sets up remote connectivity “for a week.”
Weeks turn into months. Passwords don’t get rotated. No one’s watching logs. And now the same remote path that helps support can also be used by anyone scanning for ATG systems and trying the short list above.
Post-compromise: what it looks like when the ATG is lying to you
Getting into an internet-exposed ATG is step one. The real problem is what happens after—when someone can quietly change what the system tells your staff, your vendor, and sometimes your compliance paperwork.
Federal agencies warned they’ve observed attackers compromise internet-exposed ATG systems and then modify them through command execution . Translation: this isn’t just “they logged in.” It’s “they can start changing behavior.”
The most realistic outcomes operators should worry about
These are the post-compromise moves that create real-world risk:
- Disabled alerts (alarms go silent): CISA cautioned that after a successful compromise, attackers could disable system alerts, which increases the risk of leaks or equipment failures .
If your leak detection warning doesn’t fire, your response doesn’t happen. - Leak detection gets muted or mis-tuned: Attackers don’t need to cause a leak to create a leak event. If they can change thresholds, schedules, or test settings, you can end up with:
- missed warnings (false negatives)
- constant nuisance alarms (false positives)
- staff learning to ignore the screen because “it’s always wrong”
- Settings altered via command execution: Once someone can run commands on the system, they may be able to modify configuration beyond what a normal user account could do .
That can include changing logging, disabling services, or weakening security so they can come back later. - Equipment stress and “permanent damage” risk: The advisory language doesn’t sugarcoat it—CISA warns compromises could contribute to equipment failures and even permanent damage to targeted tank systems .
Even if the tank itself is fine, you can still be dealing with a damaged monitoring/control setup and a painful recovery.
The clean example: when the screen is wrong but the tank isn’t
A May report tied to Iranian-linked activity described attackers breaching ATG systems connected to the internet at multiple U.S. gas stations and manipulating the display readings without changing the actual fuel levels .
That’s the nightmare scenario for operators because it flips your decision-making upside down:
- You reorder fuel based on bad numbers.
- You investigate “loss” that isn’t real (wasting time and money).
- You miss the moment when a real issue starts, because your baseline data is already compromised.
Even without physical damage, that kind of tampering can still undermine automated fuel leak detection and other safety-related functions .
Operator-focused ATG security: the fixes that actually reduce risk this week
If the risk is “someone can get in and change what the ATG tells us,” the near-term goal is simple: stop direct internet exposure and make every remote action traceable.
The joint guidance from CISA/FBI/NSA/DOE points to a practical baseline: restrict remote access, put controlled access in front of the ATG, fix credentials, patch, monitor, and use MFA where you can .
The 7-day ATG security checklist (high impact, low drama)
1) Remove direct internet exposure (today)
- Confirm the ATG is not reachable from the public internet.
- If it is, shut it off at the edge: no open inbound ports to the ATG network segment.
This aligns with the advisory’s core recommendation to restrict remote access to ATG systems from the Internet as soon as possible .
2) Put a “front door” in place: firewall + VPN + ACLs
If remote access is required:
- Force access through a VPN (not port-forwarding).
- Use a firewall to limit who can reach the ATG.
- Apply ACLs (access control lists) so only approved source IPs/users can connect.
Federal guidance explicitly calls out controlled access through firewalls, VPNs, or access control lists .
3) Kill defaults and weak passwords (this week, not “when we get time”)
- Change any default passwords on the ATG, its remote access device, and any web/admin interface.
- Use strong, non-shared passwords (one per site/device, not one per chain).
The advisory recommends replacing default passwords with strong credentials .
4) Patch and update what you can
- Apply vendor security updates for the ATG and any supporting software/remote gateway.
This is also directly recommended in the guidance .
5) Turn on MFA where possible
- If your remote access method supports it (VPN portal, jump host, remote support tool), enable multi-factor authentication (MFA).
The advisory: implement MFA where possible .
6) Monitor for unauthorized changes (focus on “settings drift”)
You don’t need a full SOC to get value here. Start with:
- A simple configuration snapshot (users, alert settings, network settings).
- A weekly diff: “What changed since last Monday?”
Federal guidance specifically calls for monitoring systems for unauthorized changes .
Vendor access without the long-term hangover
Remote vendor access is where good intentions go to live forever. Put basic rules in writing:
- Time-box access: 24–72 hours, then it expires.
- Named accounts only: no shared “vendor” login.
- Log everything: successful logins, failed logins, and config changes.
- Review cadence: a quick “who changed what, when” check weekly (10 minutes beats a surprise inspection problem).
If you want one principle to hold onto: remote access should be a controlled event, not a permanent condition.
