The Steam API Scam Symbiosis: Deception, Negligence & Accountability

1. Introduction: A Symbiosis of Calculated Negligence

Steam has always been entirely fine with every development—including any regulations and changes (for example, the trade holds or trade bans after changing nickname). These are forced measures, but they are ineffective and incomplete. Valve has no genuine desire to fight this, because they understand that their platform depends on both scams and gambling, as well as the rest of the shadow economy that Steam has bred, allowed to emerge, and exist for many years. It is not that they are attacking Steam; it is a symbiosis—mutually beneficial and understood by both participants of this symbiosis.

The notorious API scam (commonly known as offer swapping/replacement) originated a long time ago. Phishing has always relied on trade replacement. In its persistent form, it appeared around the spring of 2019 (prior to that, it existed as separate phishing, which eventually evolved into a replacement with duration limits of 1, 4, or 8 hours). By the spring of 2019, all the tools active on the scam market made the hijacked session 'mobile'. And that is how it lived through its hyper-popularity. By our most conservative estimates, this allowed the theft of at least $10 million and more. But you must understand that, in general, this breeds cybercriminals. Steam protects scammers by playing the game of 'skins are worthless.' The introduction of the trade hold came after the offer swap mechanism was already established. The endless 7-day trade hold was added abruptly and without reason. This is not anti-scam; it's regulation.

Let us explain how offer swapping works, and why Steam and its anti-scam attempts are a complete clown show (and always have been).

2. The 2017–2018 Blueprint: Five Private Algorithms

To understand the scale of the operation, we can look back at the private scam panels operating from 2017 to spring 2018. During this period, developers designed five distinct operational algorithms for the offer swap method. This private update included all five algorithms: the panel's bot logged into the user's account and operated according to one of the five algorithms below, bypassing 2FA with Guard validation. Scammers could configure these settings (sending games, minimum offer price filter, etc.) directly in their admin panel.

Offer swap, in one paragraph: the victim verifies a legitimate trade on the PC. Before the phone confirmation, an attacker-controlled session cancels it, copies the counterparty’s name and avatar, and sends a replacement offer. The victim then confirms the replacement in Steam Guard—often an offer that returns nothing. The Guard code is not broken; the offer underneath the familiar confirmation step is changed.

Technical appendix: offer-swap variants and panel evolution

Algorithm #1: The Classic Swap

• Checks the offer: is it from a trading website? If yes, it performs the actions below.
• Cancels the offer from the official trading bot.
• Parses the nickname, avatar, and trade message from the official bot's account and sets them all on the scammer's bot account.
• Sends the exact same offer, but from the scammer's account, with the same items, the same nickname, and the same avatar.

Algorithm #2: Delayed Swap

• Checks the offer: is it from a trading website? If yes, it performs the actions below.
• Does not cancel the offer from the official bot immediately, but waits for the user to accept it on their computer (not on the phone).
• Once the user accepts it (on the computer), the bot cancels the official offer.
• Parses the nickname, avatar, and trade message from the official bot's account and sets them on the scammer's account.
• Sends the exact same offer from the scammer's account, with the same items, the same nickname, and the same avatar.
• Accepts the offer (from the scammer's bot) on the computer.
• As a result, the user confirms the trade on their mobile app, thinking it is from the official bot, when in reality it is from the scammer's.

Algorithm #3: Outgoing Hijack

• The user sends an offer using the scammer's bot's trade link and goes to confirm it on their mobile app.
• The scammer's bot cancels the user's offer.
• Sends an offer from the user's account containing all of their items (eligible games can be selected in the admin panel) to the scammer's bot's trade link.
• The user then confirms this modified trade on their mobile app.

Algorithm #4: Dual Direction Swaps

• Incoming Offers:
  • When an offer is sent to the user asking only for their items, the swap occurs when the user goes to accept it on their phone (after accepting it on the computer) [using Algorithm #2].
  • When an offer is sent to the user for both their items and the counterparty's items, the swap occurs when the user goes to accept it on their phone (after accepting on the computer).
• Outgoing Offers:
  • When the user sends an offer to someone containing their own items, while they are heading to confirm it on their mobile app, the swap is executed. The verification of the user's mobile confirmation on the bot's side is handled via automatic trade acceptance.

Algorithm #5: Inventory Sweeper

• Identical to Algorithm #4, except that during the outgoing offer swap, it first adds the user's items that were already part of the trade, and then appends the entire inventory of the selected games underneath. Eligible games to be emptied can be chosen in the admin panel (CS, DOTA, H1Z1, PUBG).

3. Scam Panel Infrastructure & Admin Features

Scam networks are run like legitimate SaaS enterprises. Their admin dashboards include robust, multi-threaded features designed for rapid exfiltration and control:

• Detailed log table showing active SteamIDs under replacement: 'SteamID', 'Inventory ($)', 'Time left until the swap session expires', 'Offers Swapped', 'Operational Algorithm', 'Price Filter', 'Swap Session Start Time', 'Note', 'Actions'.
• User management features: pause, resume, delete, update trade link.
• Min-price threshold filter in USD (offers whose total item value is below this threshold will not be swapped, avoiding wasting time on low-value items). This option is accessible under the 'Settings' tab. Prices for CS, DOTA, H1Z1, and PUBG are updated daily between 5:00 AM and 7:00 AM.
• Manual trade link updates if the user changes their trade URL.
• Offer bot control (start, stop, restart).
• In-built Steam Browser.
• And many other features...

The Special 'maFile' Phishing Bundle

There is also a separate bundle targeting maFiles (Mobile Authenticator files). The core mechanic involves grabbing an SMS code, waiting out a 2-day cooldown, emptying the skins, and fully hijacking the account.

The victim authenticates on a phishing site with their username and password (validated in real-time). Following this, an SMS-code entry prompt appears (in place of Steam Guard), showing the last two digits of the phone number where the SMS was sent. Once a valid SMS code is supplied, the admin panel automatically generates a maFile. With this file, scammers can generate Steam Guard 2FA codes and accept trades directly. However, this newly generated maFile is subject to a 2-day trade restriction (hold): any trades initiated within the first 2 days since the maFile creation are held for 48 hours and can be canceled by the owner.

Once the new maFile is generated in the scammer's panel, the victim's old mobile authenticator will begin generating invalid codes, though to the victim, the app appears to be functioning completely normally. The text of the incoming SMS that the user receives reads: "The code to disable or move Authenticator is: 13204". The admin dashboard also features options to download the maFile, check its validity, generate 2FA codes (similar to Steam Desktop Authenticator - SDA), initiate an offer containing all inventory items with a single button, or execute an automatic offer with a 2-day hold immediately after maFile generation. Furthermore, the dashboard later added "auto-phishing" and one-click account hijacking features. For convenience, a visual countdown timer tracks the remaining hold duration directly next to the maFile.

3b. Operational Methods

1) Targeting Skin Theft:

• Delayed Exfiltration: Wait 2 days after the maFile generation, then send a trade offer to your destination account (a single button in the admin panel sends all skins to the target trade link). Requirements for success: the victim must not change their phone number or password during these 2 days (as doing so invalidates the maFile in the panel).
• Immediate Auto-Offer: Send an auto-offer containing all inventory items to the target trade link immediately upon maFile generation. Do not accept this offer right away so the items don't vanish from the victim's account prematurely. Simply wait 2 days and accept it. Under this method, changing the password or linking a new mobile authenticator won't stop the trade, though if the victim updates their authenticator, the hold resets, requiring another 2-day wait. Requirements for success: the victim must not manually cancel the pending trade offer over the 48-hour hold.

2) Targeting Account Theft (Phishing):

• Direct Account Sale: Sell the account pre-loaded with its maFile. After generating a maFile, the victim is far less likely to suspect foul play compared to traditional phishing, which often triggers an immediate Red Sign lock on the account. Consequently, scammers have a wider window to flip the account on markets. However, there is always a risk that the victim attempts to log in from a new browser/PC and regenerates the maFile on their phone, or resets their password.
• Auto-Phishing: After the maFile is captured, the account is automatically queued for automated credential stripping and locked with a Community Ban. Phishing combined with maFile generation targets and strips only the mobile Steam Guard.
• One-Click Phishing: Installs a Community Ban and triggers automatic stripping of credentials on command.

Additionally, this bot can be integrated with OPSkins cookie parsing and 2FA verification. The backend is multi-threaded and capable of processing countless accounts per second.

4. The Anatomy of Deception

How does the fraud actually unfold? A kid receives a link on Steam (the domain could masquerade as a tournament, an airdrop, or a skin-trading site). The page features an authorization button and highly sophisticated sign-in interfaces: a fake browser-in-browser pop-up window that literally displays the 'official Steam domain' (using about:blank tricks or custom windows to hide the actual phishing URL). Or, rather than a visual window overlay, it opens a full-screen, perfectly cloned Steam login page hosted on a spoofed domain. The kid authenticates directly, typing in their username, password, and Steam Guard code. And that's it. Nothing happens—the phishing site either redirects them somewhere else or simply displays the login form again.

4a. But What Actually Happened Behind the Scenes?

On the attacker's server, a live session is spawned immediately after authentication—essentially establishing a fully authorized account session. The script then immediately requests an API key for the account (via steamcommunity.com/dev/apikey). Scammers would later introduce integrated headless browsers inside active sessions, alongside automation for auto-spamming, closing support tickets, and more.

To run this operation, scammers require ready-to-use bot accounts with active trading privileges and no community limits. These are automated bulk-registered accounts (pre-loaded with exactly $5, aged for 14 days to unlock trading). Yes, they are registered completely automatically using registration software. Steam, of course, sees and detects these registrations (even with proxies); it is fully aware of the software-driven activity patterns—accounts funded with exactly $5 to lift the limit, with the funds sitting completely untouched. Once purchased, these accounts are plugged into the scam panel. From that point on, the entire attack operates almost exclusively via raw API requests. The only exception is selling the stolen items: typically, they manually access the browser, list the skins, transfer the funds, and cash out (though some claim to have achieved complete end-to-end automation, where a bot supposedly lists the skins, executes sales, and automatically payouts workers, spammers, and traffic drivers).

The authentication originates from a brand-new IP, and the software-made session comes from a static hosting/ISP pool—predominantly Ihor. PhishDestroy's preserved data and files from one such product show more than one coincidentally overloaded address: some Ihor IPs were consecutive, including addresses ending .156, .157 and .158, and each carried more than 1,000 active hijacked sessions at once. This is not an outside estimate; it comes from the infrastructure examined in the product files. A separate scheme later appeared on the receiving-bot side: one bot received one IP slot; replacing the bot in that slot retained the address, effectively assigning it for about a month. Yet a server login could still create an API key and an indefinite parallel session. Is that normal player behavior?

Furthermore, on Steam, your API key remains completely indefinite. Even if you manually delete or change it, your session will automatically regenerate it upon any background action (such as session health checks, inventory valuation, or routine timer-based checks, which scam panels ran by the thousands). This persistent session access ensures scammers can monitor accounts in real-time before users notice. It's rare for users to catch on: typically, once they are phished, their session eventually dies or is discarded. But if a victim merely deletes or changes their API key, the script immediately recreates it using the active session.

The bots are bulk-registered accounts with a $5 balance. The market is massive, and competition is so fierce that the accounts are sold almost at their raw cost of $5. Steam clearly sees, for instance, that a kid's phone—the active session containing the Steam Guard authenticator—is located in the US; it sees their computer and browser in the US. And simultaneously, it sees an active session originating from Russia or the Netherlands (the provider Ihor was the main hub for a long time, as it was packed with these specific IPs).

Yes, the theft began at scale. Steam commented on nothing. When kids wrote to support, Steam didn't even instruct them to change their password; instead, support sent generic boilerplate replies stating that the skins were gone and it was 'not our problem.' Later on (around 2021–2022), scammers began automatically closing support tickets themselves: a child would open a ticket, and the panel's automated script would immediately close it. The kids believed it was Steam support dismissing their cases. It wasn't. But Steam essentially stood by and allowed it to happen.

The hypocrisy of Steam and its 'anti-scam' updates is staggering, considering how much data Steam stores: it tracks countries, IP histories, and device fingerprinting. Steam consciously hid the fact that accounts were actively compromised. And then, there were incidents where Steam issued mass community bans to the accounts of the victims who were caught in active swap sessions. Wow, great job, Steam! Steam slapped locks on victim accounts simply because they shared a proxy IP with other sessions, instead of, say, terminating the unauthorized sessions. And when victims contacted support to appeal the bans, support played dumb, pretending they couldn't see or know anything. But we know they see everything: your devices, hardware IDs, transaction logs, history of changes, previous passwords, phone numbers, emails, and exactly when and from which device they were modified (this is the funniest part: Steam knows when an account is hijacked—it logs the exact device ID, timestamp, and IP address of the attacker).

4b. The Trade Hold Illusion

So, a terrified kid writes to Steam Support: "Aaa, help, my skins were stolen! I was sending them to my friend, or a trader, or a trading website, but they went to a completely different account with the exact same nickname and avatar, not the one I accepted in the trade!"

How did this actually happen?

Indeed, the replacement doesn't hijack the trade instantly. In your browser, you review the original trade offer, click 'confirm'—items for items, or sent to your friend's verified account. You verify the details, and everything matches. But in the brief window of time between accepting the trade on your PC and opening your phone to confirm it—that is when the scammer's bot, cloned with the same name and avatar, cancels the legitimate trade and sends its own.

Yes, on your phone screen, you are looking at the swapped trade. Initially, it shows your outgoing items, but at the bottom, you receive absolutely nothing in return. And users ignore the warnings because they already verified everything on their computer. The psychological precision of this scam and the vulnerability of the user base are stunning, especially since victims fully believe they are executing a safe transfer. Yet Steam's servers observe a session, created weeks or months ago from a completely different IP address, cancel an active trade and immediately initiate and accept a new one—and treat it as a completely normal, legitimate transaction. Seems highly legitimate, doesn't it?

I want to highlight that long before Steam introduced its clumsy, ineffective updates, third-party trading sites stepped up to take action. They valued their reputation, and perhaps they simply felt sorry for the defrauded children. For instance, the site tradeit.gg implemented a system where if their official trade offer was canceled, a massive "CANCELED" alarm blasted on the user's screen. This was a real solution, which is why we recognize them as pioneers who actually tried to do something. So, an external site utilizing the Steam API could detect a trade swap in real-time, but Steam itself couldn't? Or did they simply refuse to terminate an unauthorized session that obviously had zero relation to the legitimate user? Yes, Steam's support tickets repeatedly claimed: 'Your items are gone, we cannot help,' and the scammer's receiving bots were rarely even banned (and if they were, it was long after the fact). Even after trade holds were introduced, the average ban rate for active scam bots (locks that ultimately benefit Steam's economy rather than returning items to victims) hovered around 15–25% at peak times. Meanwhile, the hosting provider where the bots operated remained Ihor, and these automated sessions never utilized residential or mobile rotating proxies.

4c. Proof of Static Infrastructure

We can prove this. As you know, PhishDestroy is a radical anti-phishing project. We flooded phishing forms with fake seed phrases at scale to exhaust their servers' loading and processing capacities. This is actually where we originated the concept: Steam enforces rate limits on login attempts per IP address. Years ago, we executed this using free public proxies, sending endless invalid login attempts or targeting accounts protected by email Steam Guard. Eventually, Valve began blocking these attempts, and since we weren't purchasing commercial proxy networks, it proved less viable over time. However, as we now realize, it could have been highly disruptive, yet in Valve's twisted logic, interfering with scammers' operations was deemed 'unethical.'

By driving the scammers' authentication forms offline for hours, we established that they were not using a vast residential proxy network but static proxies or VPS addresses. The preserved product files confirmed two distinct models: hijacked sessions pooled 1,000+ per Ihor IP, while receiving bots used stable slots—one bot per IP. Replacing a bot in the same slot retained the IP; the address was effectively assigned for about a month.

The Bottom Line: An Open Crime Scene

Steam saw everything, knew everything, and simply remained silent instead of acting to protect its users. What a platform that claims security is its top priority.

Furthermore, an attacker with an active browser session could concurrently monitor your account, read your chats, or modify your profile (for instance, staging a fake 'VAC Ban' notice) to panic you into quickly transferring all your items to a friend or a 'safe' alt account—driving them directly into the offer swap trap. Yes, they could actively read your private chats with friends and view your media in real-time right alongside you. Apparently, Steam considers parallel sessions from entirely different countries to be standard behavior for a gaming platform (perhaps reasoning that since Family Sharing exists, 'it's fine if they steal, as long as they aren't playing CS:GO simultaneously').

5. The API Key Trap: Changing Your Password Is Not Enough

Even if you changed your password but forgot to revoke the active API key, scammers could still rob you. Yes, without an active session, their script could no longer navigate your profile or auto-accept trades. However, the official Steam API still allowed them to execute the most critical actions: monitoring your account activity and canceling pending trades (via CancelTradeOffer).

Armed solely with your API key, the bot would instantly detect and cancel your legitimate trade, and immediately dispatch a fake clone offer from its own account (directed to your trade link). From that point, the script simply waited. It couldn't click confirm on your behalf. The entire scam relied on you opening your mobile app and voluntarily confirming the swapped trade in Steam Guard. And it worked flawlessly.

There is a critical technical nuance: with only an API key (and no active session), the script cannot inject a trade directly into your Steam Guard confirmations. It must send a new incoming trade offer. This means you have to manually click 'Accept Trade' on your PC first, before it populates in your Steam Guard app.

One would think this extra step reduces the scam's success rate—after all, when accepting a new trade from a stranger, Steam displays massive warnings ('You are not friends', 'This account has been flagged'). But the scammers exploited human psychology and muscle memory. Because the victim had initiated the original trade themselves, they were already mentally prepared to part with their items. When they saw the trade suddenly cancel and a new one immediately arrive with the exact same items, nickname, and avatar, they assumed: 'The site lagged and re-created the trade.'

The user mechanically clicked through Steam's warnings on autopilot, accepted the fake trade, and confirmed it on their phone. The scam succeeded not by bypassing Steam Guard's security, but by weaponizing human inertia.

6. The Verdict: Complicit by Design

Our main message remains: we owe a special thank you to Valve and their support staff, who found it incredibly convenient to 'see nothing and know nothing.'

They love to claim that they technically lack the tools or capability to assist. But the reality is completely different. To recover a hijacked account, support does not actually need some ancient, dusty CD key from ten years ago. Steam captures a vast array of other parameters that are deliberately ignored during recovery disputes. We are talking about your unique device identifier. This isn't a simple HWID, a hard drive serial number, or a BIOS version—it is a unique hardware fingerprint that Steam retrieves, likely at the same kernel/deep system level as their VAC anti-cheat.

So when Valve refuses to restore your account simply because you 'lack a CD key,' it is not a technical limitation. It is a business strategy. It is the desire to force you to purchase your games all over again, and a flat-out refusal to return control over high-value inventories of skins.

It is unethical, but it is deeply 'Steam-like.' The same goes for their support system—a cheap, outsourced customer service operation whose internal policies are designed to avoid providing actual help or even basic courtesy. Everything is reduced to scripted copy-paste replies and terminating tickets unilaterally.

But Steam is completely fine with that.

7. Questions Congress Must Put to Valve

Congressional / regulatory brief

Do not ask about baseball cards. Follow the money and the item ledger.

If Valve appears before Congress or a regulator, analogies are not evidence. Ask for sworn, auditable answers about the value it immobilizes, the victims it refuses to restore, and the controls it chooses to enforce.

How much player value is locked?

How many CS2 and Dota items sit in trade- or community-banned accounts? What percentage of circulating supply and what market value do they represent, broken down by year, restriction type, item rarity and time frozen?

Demand: Aggregate totals, methodology, age buckets, an independent audit and inspectable disclosure of banned-bot inventories. If the figures rebut the allegation, publish them.

Why is the evidence hidden?

When an inventory or profile becomes non-public after a restriction, what security purpose does that serve? Did the visibility policy change around 2020, and why hide the ledger instead of displaying a prominent public warning similar to a VAC notice?

Demand: The policy history, internal rationale, access rules and appeal path.

Why are bot pipelines not stopped at birth?

Steam itself says malicious users commonly operate dummy accounts and uses a $5 threshold. What detects automated registration, phone and authenticator provisioning, funding at exactly the threshold, no game activity, long dormancy, then machine-like item flows?

Demand: False-positive and false-negative rates—and whether bans occur before the account has value or only after valuable items arrive.

Is “duplication” still a credible excuse?

The duplication rationale dates back to restoration practices and support-abuse stories from the mid-2010s. A modern item has a unique record, a known transfer chain and trade holds. Why would revoking that same item from a proven illicit recipient and reassigning it to the verified prior holder create a copy? At what exact step does a second item appear in 2026?

Demand: The policy history since 2014, a reproducible technical explanation and the number of actual restoration-caused duplicate incidents since 2019.

Under what authority is the item immobilized?

Does Valve treat a skin as property, a license, or merely a database entitlement? Which contract clause and legal theory allow permanent immobilization after theft while denying restitution to the verified prior holder? Property recovered from a thief does not become police revenue; why does the digital equivalent remain under the platform's exclusive control instead of returning to the victim?

Demand: Notice, evidence disclosure, human review, appeal, time limits and the precise rule governing each item's final disposition.

Who does the ban protect—and how much has Valve already earned?

Valve's official FAQ lists a 5% Steam Transaction Fee plus a 10% game-specific fee for CS2 and Dota, paid by the buyer on Community Market sales. Steam Wallet proceeds cannot be withdrawn to a bank or transferred to another account. The defensible question is therefore not whether Valve receives the full nominal price again on every resale, but how much closed-loop money and cumulative fee revenue was attached to an item before it was locked—and how removing supply affects the scarcity and price of everything left.

Demand: Lifetime fees collected on every item later frozen, victim-restitution and pre-loss intervention rates, and a model of the price effect of frozen supply. Do not count a ban without restitution as help to the victim.

Does Valve defend a presumption of guilt?

A skin restriction is not a prison sentence; the analogy tests the procedure. If Valve or its executives faced an unexplained penalty, undisclosed evidence and a nominal appeal answered with “read the law,” would its lawyers call that justice? Yet for high-value inventories Valve can appear to be accuser, adjudicator and custodian of the frozen value. What independent check addresses that conflict?

Demand: The exact rule, alleged act, evidence summary, human reviewer, reasoned decision, independent escalation and disclosure of how frozen value is treated.

Why is a meaningful appeal inaccessible?

A boilerplate response and a broad link to the Steam Subscriber Agreement are not a finding of fact. Why can an ordinary consumer be denied the allegation and evidence, then face technical, legal and financial barriers that make challenging an automated or mistaken restriction impractical?

Demand: Free human appeal, a plain-language decision, response deadlines, external dispute access, and statistics on automated bans, human reviews, reversals and repeat template replies.

Community, recovery and the session Valve chose not to kill

What is the “community” in Steam Community?

After New York’s Attorney General sued Valve in February 2026, Valve published a Steam Support statement aimed at users and invoked effects on users and the public process. But when platform decisions affect those users’ valuable inventories, what formal power does this “community” have—votes, reasons, policy consultation, oversight or even visibility into report outcomes?

Demand: Define the community’s governance rights and publish consultation records, report outcomes and an independent user-oversight mechanism—or admit that “community” is branding, not representation.

Why does ordinary enforcement inherit VAC secrecy?

Keeping anti-cheat detection signatures secret can protect a detection method. A community or trade restriction is different. What security risk prevents Valve from naming the rule, timestamp, alleged action and evidence category? How many user reports and bot reports lead to action, and what integrity controls cover staff, contractors and volunteers?

Demand: Error and reversal rates, report-to-action statistics, independent integrity audits, conflict-of-interest rules and aggregate disciplinary outcomes.

Is account recovery designed around evidence users are unlikely to retain?

Steam says a retail CD key may establish ownership and recommends keeping it; it also says a verified phone gives additional recovery options. Why demand a decade-old physical key when Valve may hold payment, historical email and phone, device and login records? PhishDestroy internally estimates that 15–20% of claimants do not complete recovery after such a demand, although some still write from the longstanding provider and computer and control the email or phone. Valve can rebut that estimate by publishing its data.

Demand: Attempts, approvals, rejections and abandoned procedures by evidence type; results for claimants retaining an email, phone or device; and an auditable explanation of signal weighting.

Why punish the victim instead of revoking the hostile session?

In the examined infrastructure, several consecutive Ihor IPs—including addresses ending .156, .157 and .158—each held 1,000+ active hijacked sessions while owners remained on known devices elsewhere. Those sessions could recreate API keys, wait, alter trades and read chat in parallel. The Steam Subscriber Agreement threatens account termination for IP proxying that disguises residence, including “for any other purpose.” Why does a server proxy holding a thousand unrelated accounts not trigger even a session revocation?

Demand: Automatically revoke a hosting session, its API key and confirmations when it pools unrelated accounts at mass scale; then require clean reauthentication without restricting the victim.

Seven years, 79 Steam staff and 1.16 million nominal hours: failure or business model?

PhishDestroy can substantiate pools of 1,000+ sessions on one IP, consecutive addresses at one provider and separate stable IP slots for receiving bots. Yet the server-side pattern did not trigger the obvious response: revoke the hosting session, invalidate its API access and require clean authentication from the owner. Valve already enforces concurrent-use rules around game sessions. Why was equivalent risk logic not applied when a Russian hosting address sat between the owner and Steam while holding a thousand unrelated accounts?

A 2021 organization snapshot accidentally exposed through the Wolfire antitrust litigation in 2024 reportedly listed 79 people in Valve's “Steam” category and $76,446,633 in aggregate gross pay—about $968,000 per listed employee as a category average, not an individual salary. That snapshot does not prove that 79 security engineers worked on offer swapping, that the headcount stayed constant, or that all employee time was available to this problem. It does establish the scale Valve must explain.

≈88 monthsPersistent mobile-session offer swapping from spring 2019 to this publication: roughly 2,700 days

79 peopleReported 2021 Steam-category snapshot—not a security-team count

1,162,880Illustrative capacity-hours: 79 × 14,720—not claimed fraud-investigation hours

Run Liability Audit Simulate Attack Sequence

Parallel Session

Trade Flow

Security Response

To: The Victims of Asset Theft and Valve's Deceptive Legal Team

You have been trying to convince courts and players alike that item theft is solely the fault of 'stupid children' and that your platform's architecture bears no responsibility. Let us drop the corporate masks and explain, in the simplest terms, why your highly sophisticated, highly profitable phishing ecosystem exists solely due to Steam's architectural loopholes. Phishing is merely the act of stealing a key to a front door. But the fact that behind this door lies an completely unguarded vault controller—that is entirely the fault of Valve's developers.

Let us examine some analogies for your security model to understand the sheer magnitude of this failure.

1. You are not GitHub (The Developer Fairytale)

Valve justifies its insecure API by claiming that Steam is an 'open platform for developers.' Okay, let's compare you to GitHub. What happens when you try to generate a Personal Access Token (PAT) on GitHub?

• The system forces you to re-enter your password.
• It prompts you for a 2FA code.
• It obligates you to explicitly check off scope permissions (privilege separation) for the token.
• Crucially, it asks you to set an expiration date (TTL) for the token.

And what does Steam do? It silently issues an infinite, omnipotent key with a single click, requiring zero confirmations, granting unrestricted read/write access to cancel and replace trade offers forever. You are not an open platform for developers; you are an open gate.

2. You are worse than sanctioned crypto-mixers (The Tornado Cash Syndrome)

If Steam isn't a platform for developers, then perhaps it's a financial exchange? Let us compare you not to legitimate stock exchanges, but to the shadow crypto-mixers and sanctioned platforms that the US Treasury and the FBI dismantle for money laundering (such as Tornado Cash, Bitzlato, or Garantex).

Do you want to know the ultimate irony, Gabe? Even illegal, sanctioned dark-web crypto laundries enforce better API security than Steam! Even the administrators of underground mixers understand that to generate an API key capable of managing user balances, they must force the user to input a 2FA code, confirm via email, and bind the key to specific IP addresses. Yet, Valve—a legal, multi-billion-dollar American corporation—allows an invisible script running on a server in Russia to gain permanent, confirmation-free access to user inventories worth tens of thousands of dollars in a single click. Do cybercriminals actually enforce higher security standards than your million-dollar salaried developers?

3. Grey markets proved smarter than a multi-billion dollar corporation

The funniest part is the third-party skin gambling and trading marketplaces (like OPSkins or the old BitSkins) that Valve so aggressively targeted. Back in 2017, they faced the exact same API Offer-Swap substitution problem. And do you know what they did? They—a small group of independent developers without multi-billion dollar budgets—simply fixed it in days by adding confirmations, instantly breaking the scammers' schemes.

Meanwhile, Valve spent 7 years conducting experiments on children, watching how long users would keep purchasing new skins to replace stolen ones, and how much illicit capital scammers could wash through this loop.

4. Brilliant crutches instead of actual fixes

Instead of closing the vulnerability, Valve introduced 'brilliant' crutches. A 7-day trade hold. A 4-hour trade lock for changing your nickname. For 7 years, you treated an open fracture with a band-aid. A stolen knife was never returned to its victim; it was simply frozen forever on a banned bot, artificially reducing circulating supply and driving up market value. It was the perfect business cycle: scammers steal, Valve bans, supply drops, prices rise, and Gabe collects a lucrative transaction fee on every new sale.

The main question Valve cannot answer:

STEAM, WHY IN THE WORLD COULD YOU NOT JUST ADD A MANDATORY CONFIRMATION OR MOBILE PUSH IN STEAM GUARD TO GENERATE AN API KEY—AN OMNIPOTENT TOOL THAT CONTROLS THOUSANDS OF DOLLARS IN VIRTUAL ASSETS?!

You force users to confirm the sale of a 3-cent trading card on their mobile app. Yet, for 7 years, you allowed an invisible script to gain permanent control over their entire inventory without a single notification. This is not 'phishing.' This is deliberate, calculated negligence, and your users paid the price.

The Cryo-Chamber Chronicles: What Valve Missed in 7 Years Hover to read

Text hidden. Hover cursor to reveal

If Valve’s executive management subjected its security engineers to illegal cryogenic freezing experiments in the spring of 2017 and only woke them up today—we retract all our claims. That would explain everything. Science requires sacrifices (in this case, user inventories).

But if your employees were fully conscious and receiving their paychecks over these 7 years, we have bad news. While your developers spent 1.16 million hours trying to secure API keys without implementing a simple Steam Guard confirmation, here is a brief excursion into what the rest of humanity managed to achieve while you were in stasis:

Technological and Scientific Breakthroughs of Humanity (2017–2024):

• The AI Revolution: Humanity invented generative neural networks. OpenAI launched ChatGPT, which passed bar exams, learned to write complex code, diagnose diseases, and paint photorealistic art, completely transforming the global economy.
• Space Exploration: NASA successfully landed the Perseverance rover on Mars, flew the Ingenuity helicopter in the Martian atmosphere, and deployed the James Webb Space Telescope, looking back to the beginning of time. SpaceX mastered catching falling 50-meter rocket boosters out of mid-air with giant mechanical arms.
• Medicine: The world faced the COVID-19 pandemic. In record time, scientists sequenced the virus's genome, developed and tested revolutionary mRNA vaccines, and immunized billions of people to stop the pandemic.
• The Quantum Leap: Google and IBM officially achieved 'quantum supremacy,' building quantum computers capable of solving in seconds equations that would take classical supercomputers thousands of years.
• Hardware Revolutions: Apple abandoned the processor architecture it relied on for decades and designed its own high-performance M-series silicon from scratch. Meanwhile, Valve itself managed to design, manufacture, and release the innovative Steam Deck console.

Steam Security Team 'Achievements' Over the Same 7 Years:

• Added a 7-day trade hold (failed to stop thefts).
• Spent 5 years thinking, then banned item trading for 4 hours after a nickname change (drawing laughter from scammers).

Summary: In the time it took humanity to reach Mars, invent artificial intelligence, overcome a global pandemic, and build quantum computers, Valve—a multi-billion-dollar corporation—could not manage to add a single pop-up box with a 'Confirm in Mobile App' button to the dev/apikey page.

Gentlemen from Valve, welcome to the future. Your cryogenic sleep is over. Humanity has leaped far ahead. Let's finally attach 2FA to your API so children stop losing millions of dollars due to your corporate laziness. Or should we wait another 7 years for Elon Musk to colonize Mars?

The Steam API Cover-Up: How Valve Legalized Silent Espionage

Valve has spent the last 7 years shifting the blame for the massive API trade substitution scam onto its users. Steam Support’s standard response dismisses victims by claiming they simply fell for phishing and compromised their own accounts.

This is a calculated corporate lie. What Valve calls 'account theft' is, in reality, an uninterrupted, automated Man-in-the-Middle (MITM) surveillance operation facilitated by their own broken infrastructure.

Account Theft vs. Silent MITM Espionage

The Steam Terms of Service strictly forbid the use of automated scripts. Yet, Valve’s backend turns a blind eye when these exact scripts hijack user sessions.

• Standard Theft: A login from an unauthorized device triggers a Community Ban, locking the account and preserving the user's inventory.
• API Espionage: A malicious server establishes a parallel connection, monitoring the account in the background 24/7 without triggering any alerts or bans.
• The Interface Lie: During a trade, the Steam mobile app displays a legitimate transaction, forcing the user to authorize a trade that an invisible script cancels and replaces in milliseconds.

The Phantom Agreement: How Steam Lies About Your 'Consent'

Let’s talk about Steam Support’s favorite excuse when they refuse to return your stolen items: 'You are responsible for your account security and the actions taken on it.'

They imply that you, the user, agreed to the terms that allowed this theft to happen. Really? You never saw this developer agreement page: https://steamcommunity.com/dev/apiterms. You never clicked 'Agree'. A hacker accepted this contract on your behalf, fractions of a second after authorizing into your account from a Russian IP address.

So, we challenge any lawyer or Valve representative to show us exactly where in the Steam Subscriber Agreement it says: 'By using Steam, you consent to 24/7 background surveillance of your or your child's account by an automated server located in Russia.'

In 90% of trade substitution cases, the victim doesn't even know what a Web API key is. They have never used one. Yet Valve has comfortably sat on their hands for 7 years, completely ignoring a solution that the community has been screaming about since day one: Just add a mandatory Steam Guard confirmation to generate the API key!

Steam, Children Shouldn't Be Forced to Sponsor Hackers

Imagine an ordinary teenager from Europe. They play games, save up for their favorite skins, and at some point, they make a mistake—they log into a phishing site. In a normal digital ecosystem, the protocol is simple: the account is automatically locked (Community Ban), passwords are reset, and access is safely restored. The kid realizes their mistake, but the system protects them from fatal consequences.

But in Steam, everything works differently. Instead of blocking the suspicious activity, Valve silently opens a hidden door. A server from a sanctioned jurisdiction (Russia) gains parallel, unauthorized access to this kid's account. Without any secondary confirmation, without a single Steam Guard prompt, an alien script generates a Web API key. It accepts legal agreements on the user's behalf and begins monitoring their chats, trades, and inventory 24/7.

A teenager from the EU never consented to hidden surveillance. They are not obligated to sponsor hackers from an OFAC-sanctioned territory just because a multi-billion-dollar corporation is too lazy to secure its own API. By keeping the stolen skins and refusing to restore them, Valve is covering up its infrastructural negligence, effectively legalizing the drain of European citizens' digital assets into sanctioned territories.

Why Steam’s API & Token Security Violates the Law

Steam allows third parties to generate API keys and hijack session tokens via MitM proxies without ANY user alerts or 2FA checks. This negligence directly violates major data protection and consumer laws:

• 🇪🇺 EU GDPR (Art. 25 & 32): Demands 'Security by Design' and adequate technical protection. Generating critical access keys without 2FA is a severe security failure.
• 🇺🇸 US FTC Act (Sec. 5): Punishes 'Unfair Practices' and lack of 'Reasonable Data Security.' The FTC routinely acts against platforms lacking MFA for critical account actions.
• ⚖️ EU Directive 2019/770: Digital services must meet baseline consumer security expectations. Steam’s 7-year-old API vulnerability fails this completely.
• 🛡️ NIS 2 Directive: Mandates strict cyber hygiene, including mandatory MFA for access management, which Valve ignores for API generation.

Bottom line: When a platform hands over your API keys to a proxy session without a single alert or confirmation, it’s not just a flaw—it’s a major compliance violation.

Ready to Fight Back? Generate Your Notice of Dispute

Don't accept their automated Terms of Service rejections. Hold Valve legally accountable under international consumer and data protection laws. Use our free, interactive generator to compile a formal legal Notice of Dispute (PDF) for your region instantly.

Generate Notice & Save as PDF

Does Valve retain session-level logs for authentication, API-key creation, offer cancellation and replacement, confirmations, IP history and support actions? If those records exist, could Valve prove when it first saw the Ihor pools and why it left them active? If they do not exist, why did a platform handling high-value inventories fail to preserve the audit trail required to investigate a known attack class?

Across roughly 88 months, how many users—including minors where known—opened tickets specifically about offer replacement? How many tickets showed a foreign parallel session but received a scripted response instead of immediate revocation? How many cases resulted in prevention before loss, actual item restitution, or a receiving-bot ban attributable to that ticket or report rather than a later unrelated detection? PhishDestroy's review of public victim reports and Reddit discussions found no case that could be confidently tied to a victim's report; that is not proof that none exists, and Valve can correct the record by publishing its internal totals.

The money question also requires exact accounting. For a CS2 or Dota Community Market sale in which a seller receives 100 units of Steam Wallet value, the buyer pays roughly 115 after the listed 5% Steam fee and 10% game fee, subject to rounding. The extra 15 is a fee; the seller's 100 is Wallet value, not another 100 of commission, so “115% profit” would be inaccurate. But if that item is later stolen and frozen without restitution, Valve still controls the closed-loop funds, has collected the fee and has removed the item from circulation. What are the aggregate buyer payments, Valve fees, Wallet liabilities, frozen-item value, price effects and restitution amounts for this attack class?

Demand: Publish the actual security and support headcount by year; hours and budget assigned to offer-swap prevention; the full timeline of reports, decisions and missed mass pools; ticket-to-session-revocation, ticket-to-bot-ban and restitution rates; preserved request/action logs; and an audited comparison of Steam payroll and platform profit with user losses, fees collected, Wallet value and items frozen. Answer on the record: was this a staffing failure, a support-policy failure or a deliberate business choice?

Outsourced support and privileged access

Can an outsourced agent query any Steam user worldwide?

Valve's Privacy Policy says third-party support providers may receive personal data only as necessary. PhishDestroy knows the field set and access model of the interface examined; Valve is asked to confirm or deny it on the record. Can a contractor agent in Ireland—or elsewhere—open a user in the US, Germany, Australia, China or Russia? Can they see current and historical email, phone, IP and device records, sessions, account changes, transactions or private chats? Is an assigned ticket required?

Demand: A processor and subprocessor register, every processing country, a role-by-field access matrix, regional restrictions, ticket-scoped just-in-time access, and a clear answer on chat and historical identifiers.

Does Valve know the human behind every privileged lookup?

A contractor’s employee may have personal, political or governmental ties unknown to the user. What prevents an operator from being bribed, coerced or tasked by the FSB—or any other intelligence or law-enforcement body—to retrieve a person’s IP history, activity times, contacts or account changes? Does Valve identify each natural person, prohibit shared credentials, record every search and field view, detect access outside an assigned case, block bulk export and require all government demands to pass through Valve’s legal process?

Demand: Individually attributable audit logs, hardware-bound authentication, anomaly alerts, periodic access reviews, log-retention periods, insider-abuse statistics, contractor-originated government-request totals, disciplinary outcomes and a public transparency report by country.

Evidence recovery commitment

Will Valve claim that the bots and victims can no longer be found?

If Valve tells a hearing that its interface, security and support failed—or shifts the failure to an outsourcer—and then promises restitution, “we can no longer identify the bots or victims” cannot become the next excuse. PhishDestroy is prepared to submit preserved SteamIDs of receiving bots and associated trade and theft records from the principal product examined. Our current internal estimate is that matching this material against Valve's complete trade ledger could identify roughly 80% of classic offer-swap victims—not maFile, credential-phishing or RAT cases; exact coverage can be established only through reconciliation. Two other panels existed: one set of developers may now be difficult to locate, but other participants and researchers may be able to supply additional lists.

If Valve tells Congress that large-scale frozen skin inventories have no effect on supply, scarcity, prices or platform revenue, while its internal data show otherwise, that would be a false statement to Congress. Assertions are not enough: require the underlying data and an independent impact model. Time matters. Offer swapping is losing relevance as Steam scams shift toward RAT payloads and fake VAC-ban lures delivered through files; the people behind the older products may disappear with the evidence.

Independent verification path

Anticipating the ‘trust’ excuse: the 213,000 offer-swap bot ledger

We anticipate Valve’s standard defense: ‘We cannot blindly trust a list of victims provided by a third party.’ We respect that skepticism. That is why we are not offering a list of victims. We are offering a verifiable list of the receiving bots used by the classic offer-swap panels.

We have the means to secure databases covering approximately 80% of historical classic API offer-swap volume—the mechanism that cancelled a legitimate trade offer and sent a replacement—if Valve genuinely commits to restitution rather than PR damage control. This estimate does not cover maFile theft, ordinary credential phishing, RAT payloads or other scam types: those flows could use limited or concealed bots and cannot be reconstructed with the same confidence. We can ask the scam-panel authors directly. They are accessible coders: we can contact at least one immediately and have a path to the other. The objective is not a witch hunt against individual developers, but to force Steam to correct a seven-year systemic failure. Compared with Valve’s corporate silence, the panel developers have at times shown more humanity and transparency.

≈213,000‘Unlimited’ receiving and liquidation bot accounts · classic offer-swap only · PhishDestroy internal estimate · some already bannedBot IDs supplied → Valve verifies inside its own ledger → victims and items

Even if the authors refuse to share their logs, we possess alternative forensic methods for identifying bot networks deployed exclusively for this specific offer-cancellation and replacement mechanism. Under that exclusive-use criterion, every incoming trade to a verified panel receiving bot is a documented theft.

No one is asking Valve to hand its internal logs to PhishDestroy. We will provide SteamIDs or account logins for bots used only to receive and liquidate items stolen through offer replacement; Valve can keep its ledger inside its own environment and perform the match itself. Many of these bots successfully sold stolen items, some are already banned, and the volume of incoming trades is enormous.

The verification evidence is Valve’s own: bot-only account behavior, the timing of a legitimate offer being cancelled and a replacement being sent, incoming-item and liquidation history, the documented Ihor infrastructure, and confirmation from affected users. For an account verified as an exclusive offer-swap receiving bot, every incoming trade in its operating period is a theft record—not normal player activity.

Direct question to Valve: Do bot-operated receiving and automated liquidation of stolen skins violate the Steam Subscriber Agreement and platform rules—or only when enforcement is convenient for Valve? Is organized skin theft commercial activity, or does that definition also change when convenient?

Valve does not need to trust our victim assessment. It only needs to cross-reference the estimated 213,000 bot identifiers with its own ledger and independently verify their function. Once verified, identifying victims and restoring items is a database query. We will do everything in our power to deliver the list. The only missing element is Valve’s willingness to act.

PhishDestroy commitment: If Valve genuinely begins restitution, we will make every possible effort to obtain, preserve and securely deliver the available lists. Demand to Valve: preserve internal logs now without handing them to us, open a protected channel for bot identifiers, and reconcile SteamIDs and trades inside its own ledger, notify identified victims and publish the number of restored items.

Real money has already entered Steam's closed loop, and Valve collected fees as the item circulated. If its history remains fully traceable, the prior holder is known, and Valve then freezes it permanently while refusing restitution and hiding the inventory, the question is unavoidable: why should the public see that as protection rather than monetization of the platform's own vulnerability? A ban that leaves the victim empty-handed is not restitution.

Editorial note: The operational Ihor claims are based on PhishDestroy's preserved data and files from one examined product and can be submitted for independent review. Aggregate totals, selective enforcement and economic motive require Valve's records. References to Ireland, Russia, the FSB or another state describe a threat model; they do not accuse a named contractor or operator of disclosure without evidence. The 79-person and $76.4 million figures are reported from a court-filed 2021 category table exposed before corrected redaction. The 1,162,880-hour figure is an illustrative staffing-capacity calculation—not a claim that 79 people were security engineers or spent those hours on this fraud.