And somehow leave with admin access.
That seems to be the case with modern ‘AI’ solutions, embedding not only slop, but completely delivering compromise right to your organizations environment.
In this modern arms race of ‘what can we do to go faster’ we decided that allowing computer systems to install built in compromised land mines to an organizations environment is probably a good idea. (It’s not really a good idea)
Technology adapts around the world at generally the same pace, meaning if you hear something that is the ‘first’, it’s likely that it might be the first for that group of people but somewhere else in this big world , someone else is having the same idea.
So if Big AI Company in some country is doing something you can be assured that other countries are interested doing the same thing, an in some instances interested in compromising users of those systems. Especially if the developers are an easy target to compromise. This is focusing on the supply side of the materials.
A compromise there can propagate to every downstream customer.
I want to take a moment and talk specifically about Systems (with a capital ‘S’).
Systems are a group of interacting elements, that act according to a set of rules and constrains, that form a unified whole. A car is a system, the power plant is a system, the freeway is a system. A business is a system of systems, and that’s what we’re going to explore next.
Think of a house as an analogy for a computing system, the architect’s role is to create a design that meets the expectations of the homeowners while being practical for carpenters to construct using available materials.
Architecture can be thought of as a process that bridges requirements, constraints realized to a system, in this case an implementation. If we think about the actors in this scenario, and substitute a house for a computing system the architect produces a design that simultaneously satisfied the occupants of the house, and can be realized by the carpenters, using available materials.
The architect in this case is the software developer, the person who is committing with their SSH key to their code. The available materials is what the software can use and access. Delegating the signing with SSH key is quite a consideration, and I wholly would not let a system have that level of access to anything.
Now imagine if your architect was like hey let us go ahead and wire up some dynamite in your infrastructure you’d probably want that architect to not make those recommendations.
And you would hope that everyone else involved in the process would also say
‘Hey, wait this is a really bad idea!’.
But in this instance the machine of random hole shaped answers is susceptible not only to misuse but abuse.
But what about if nobody told the architect ‘No’, and when you called the other folks they also said,
“I don’t see a problem?”
Now I want to explore some ideas about architecture here, computers are systems of systems, generally most code is lines of text as a file, sometimes an object. These are broad generalizations but in most cases computers are made of these things, files and objects.
In this specific case a file with some configurations compromised the system.
There are ten questions worth while to put in your mental model about system thinking and computers, and specifically I want to focus on number 6 and 7.
- How does the technology work?
- What are the data inputs?
- What are the data outputs?
- When does the analysis occur?
- What are the analytical algorithms?
- How does it operate at scale?
- How can it be circumvented?
- How do humans interact with the technology?
- What are the user’s responsibilities?
- How does this interaction scale?
Lets think about this from the design perspective of the malicious actor:
Build something that looks safe, that will convince someone with a surface level understanding of the code-base would likely approve. A product that at first glance is readable, editable and utterly unremarkable.
The code also quietly performs other actions too, preventing detection by security tooling, and generally remains undetected until a human uses tools in a specific manner to find the miss-configuration and the obfuscation.
Over the course of human history, people, groups, actors, nations have been interested in finding ways to specifically answer questions number 6 and 7.
Getting specific about the ‘who’ is critical for this.
Who is it that writes the code for businesses?
It’s people, usually with the title software engineer, or software developer. They might use a tool like a random answer generation machine that embeds dynamite or other devices like caltrops across your code base, but don’t worry it’s cool. Just delegate your critical thought to the hole shaped answer generation machine, it will likely respond with something, canned. Because it cannot ‘think’.
The business might have a department that writes code, but it might also hire people to write code, and sometimes the organization can only do so much vetting, and if they have poor controls in place well what an easy way to slip in nefarious patterns that go undetected.
You say though, we’ve got the best security tooling, we’ve deployed all these secure systems and we are super secure!! we scored 100! We got green checks, we’re in compliance.
Remember in 2024 when Crowdstrike was at the core of outages?
A bad content update pushed to a trusted, vetted kernel driver. This was not with malicious intent, but the same systemic lesson: when a component sits inside your trust boundary, you stop scrutinizing its changes with the same rigor you’d apply to unknown code.
A DPRK-style insider or a poisoned dependency is the same trust boundary deliberately exploited. The attacker’s whole strategy is to get inside the perimeter where scrutiny drops off, whether via employment, an open-source contribution, developer, or a compromised package maintainer account.
Detection Engineering
What is it and how does it work:
• The ability to detect the adversary
• The cost of that ability to the cyber security organization
• The cost to the adversary to evade that detection
A detection is only durable if it’s cheaper for you to maintain than it is for the adversary to evade.
Signature-based detection (matching known strings/hashes) fails this test against runtime-decoded payloads like the tailwind.config.js
Lets put on our other hat though, the one where we were building software:
// What it looked like — a self-decoding string cipher:
var _$_ac0e = (function(scrambledInput, seed) {
// shuffles characters of scrambledInput using a seeded pseudo-random rotation,
// then does a final find-and-replace pass on placeholder characters
// (the %, #1, #0 markers below stand in for control bytes the real payload used)
...
return decodedArray;
})("c7c58842x6rd0a3017MKfJZ...", 5991173);
global[_$_ac0e[0]] = _$_ac0e[1];
global[_$_ac0e[2]] = _$_ac0e[3];
// What it actually resolved to, once decoded (values below are illustrative, not the real ones):
global['_t_1'] = 'T_EXAMPLE_TRON_WALLET_ADDRESS_HERE'; // a TRON wallet address
global['_t_2'] = '0xEXAMPLE_PRIVATE_KEY_OR_HASH_HERE'; // looked like a private key / hash// tailwind.config.js (excerpt — not the real payload, representative sample)
There are different ways to test a computer system
-
Paths for Data/Commands:
- The sum of all entry and exit points for data and commands in the application.
- Includes resource connection, authentication, authorization, activity logging, data validation, and encoding.
-
Protection Code for Paths:
- The code responsible for safeguarding the paths mentioned above.
- Encompasses measures like resource connection security, access control, and data validation.
-
Valuable Data:
- All valuable data utilized in the application, such as secrets, keys, intellectual property, critical business data, personal data, and PII (Personally Identifiable Information).
-
Protection Code for Data:
- The code responsible for protecting the valuable data.
- Includes encryption, checksums, access auditing, data integrity, and operational security controls.
If the systems lack conformity and the little nooks and crannies in system are rife with spots to hide. And if you let the machine of infinite words write to those directories any security mechanism you have considered, engineered or deployed is essentially unable, or in this case incapable of identifying these tool sets.
The author took some specific steps to unpack what was occurring
Reviewing the authors steps static analysis with lint/reformat and rename the variables to make the control flow legible.
Manually decoding the scrambler by hand, replaying the rotation logic
Dynamically passing in isolation, analysis occurred in a dockerized system with no network or file system to observe the behavior.
Layering the system:
Revealed the payload was making JSON-RPC calls to api.trongrid.io (TRON blockchain API), with a fallback call.
Since the entire payload is generated at runtime via a custom, seeded decoding routine, no malicious string or pattern ever exists in the static source file.
This is a classic technique for defeating pattern-matching detection: the “malicious” artifact only materializes in memory, transiently, after execution.
Additionally the local ‘git-reflog’ on your machine records every ref update including the pre-amend SHA, so you can diff what the commit looked like before versus after.
If you use node, and tailwind there are some considerations to put in to the toolkit to detect this style of compromise.
ps aux | grep node
Account for every process.
Scan code for long encoded strings
Check your tailwind and configuration files for scripts
Audit your git history for commits you don’t recognize
In Closing
I want to examine this as an engineering artifact.
This software, worked. It cleanly achieved its objective, it compromised the system, ran undisturbed and by the time it was noticed, it had been running for more than a month. Without ever triggering a detection.
That’s about as lean Six-Sigma as you can get. Works, as expected and does other things too without causing an interruption that is perceived.
The reporting on this seemingly took more than one month.
How long is a month in your operations? How long is a month in the promises you make to clients about the diligence behind your tooling?
A month is quite a long time, imagine how many credentials, transactions, records, how much data is there in a month?
And that’s the world that we’re living in today, skilled organizations are focusing on this. Specific exploits that can be implemented without detection and for a duration that is long enough they are able to get some meaningful information from you, your clients, your friends, the data of the system.
Even with tooling the systems didn’t identify this behavior as malicious. Because the system can only look for certain patterns and then do something when those patterns are detected. In this case this is a way of bypassing a security control on a system.
Now Lets explore an ‘Actor’
Every acting group has some objective, and motivation, they have a country of origin, they have members, they have leadership.
They are also focused on crafting really good tools that won’t trigger a response by what most people have in their toolkit.
And in this particular case, that is specifically what has happened. Their code got configured, installed and operational, until it was ‘too late’ and eventually well after the fact it was more clear that something had happened and in that case many other things happened too.
A brief bit about the org likely behind the attack, they are a North Korea Aligned threat actor
linked to both financial theft and state-sponsored intelligence operations. this group employs sophisticated social engineering tactics and custom malware to infiltrate organizations globally, who targets software developers specifically.
The core lesson isn’t really about TRON, or Tailwind, or even this specific payload.
It’s that detection built purely on pattern-matching has a structural ceiling, and adversaries who understand that ceiling will design specifically to stay under it.
Using tools that have dubious semantics, are likely to blindly integrate potential compromises to your code infrastructure is a specific choice that makes a wealth of opportunities for malicious actors.
Another round of tokens, bar tender.