Pots and kettles
>> Microsoft tracks as a China-based state-sponsored actor
https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/
Let's have a report into how much spying that MS has done for the American regime.
A Chinese state-backed cybergang known as Flax Typhoon spent more than a year burrowing inside an ArcGIS server, quietly turning the trusted mapping software into a covert backdoor. Researchers at ReliaQuest say that the espionage outfit, which Microsoft tracks as a China-based state-sponsored actor, modified a legitimate …
I know, I know, it's simply *terrible*: when a government compels a company to do something by law, compared to a government that breaks into business & personal computers with malware and vulnerabilities for fun and profit.
Next thing you know, your "truth" won't have much "voice", and then what will you ever do??
@El Reg -
Why do you allow the above VoiceOfTruth Kremlin propaganda account to post here? Can you not be bothered to implement even basic IP user filtering? If you look at the NCSC propaganda updates regarding Russia, this VoiceOfTruth account posts exactly the Kremlin line article after article, day after day. Youve done nothing for years. The person isn't mentally ill, it's a Russia shill account. Your rag needs to sort itself out.
Banning people, even malicious "state actors," is not only useless (they'll just pop up again in a different guise), it's often counterproductive.
We saw what Twitter and Facebook bans did.
A certain well known (perhaps even over known) public figure I shall not name was banned for spreading misinformation and worse and only made that person stronger by turning them into a martyr.
You can pretty clearly see where that got us.
While disinformation can be annoying, frustrating, and downright destructive, I think the best weapon against these trolls and dolts isn't suppression but facts, used lucidly and repeatedly.
If I had a magic potion, I'd make them all go away.
But, then, do you trust me (or anyone else) with that magic potion?
The article acts like this attack is a novel technique or somehow different, using sentences like these:
"It also highlights how attacker sophistication increasingly lies less in weaponization and more in subverting trust – turning the target’s own system into the attack vector."
"These latest findings underline how even legitimate, widely used software can become a long-term espionage tool when misused. For defenders, it’s another reminder that persistence doesn’t always come from exotic malware – sometimes it’s hiding in the apps you trust most."
Let's simplify the talks about SoEs and backups for a minute. Here's what happened. The attacker broke into an admin account that was inappropriately configured, wrote some malicious code, and installed it on the server. Exactly the same way that they would if it was running as a separate process, but they wrote theirs as a plugin to something already running on the server. It's still custom malware; this was not embedded into ArcGIS. It was not part of something public installed by the admins themselves. It was written and installed by the attacker. This is not so new.
"Do not scan anything in any of our locations"
How often did I see that over the years allowing malware to sit undetected - only found when an upgrade was going to be applied and the user copied all the folders over to another location without the exclusion when then triggered the AV into having an hissy fit.
I may have misunderstood TFA but I think it's saying that they got in to add the code to malware to server application code in a repository, not breaking into a single server instance. If that's the case then any arcGIS servers with that plug-in enabled will be running it. If that's right it's potentially quite a serious issue because utilities run this kind of stuff so the risk is that it's let them in to all sorts of infrastructure.
The article didn't make it very clear, hence my clarification. Here's the relevant part of the report:
Initial Access
Working with ArcGIS, we found the attackers compromised a portal administrator account and deployed a malicious SOE.
They note that they mostly can't tell the details because it was present for long enough that they didn't have detailed logs. This wasn't a supply chain attack, not that those would be particularly new either. This was just implementing malware as a component of something that was supposed to be there so it's harder to find. Since it was new code, a typical scan for known bad files wouldn't have found it anyway, and it wasn't particularly sneaky in operation because it created its own secret directory for storing incremental data which could be later retrieved. It was clever hiding, but the article acts like this was a compromise of ArcGIS or something similarly pervasive. It wasn't.
That's not a surprise.
How many of us carry out checksums on all of the various objects on our servers to make sure that they are as they should be?
It seems as if this should become a standard security screening procedure and run often.
To be sure, the principal sin of the infected company was allowing anyone unauthorised to get a portal admin account.
If you let ne'er-do-wells in, it is not a surprise when you find the well-hidden hole that they make for themselves to let them back in.
Yeah, can't wait for the buzz of juicy agentic vibrator coding to broadly spread its magic touch and deeply penetrate such extensible application software stacks' sensitive rabbit hole SOEs ... it'll be so gloriously OrGaSmIc! </bzzt-bzzt!> ;) 8) &~O 8O O% O!: ;) (or not! ...)
Read-only is a nice if you happen to be able to do it, and nearly impossible in most situations. There is a reason application control (aka whitelisting) hasn't taken the security world by storm. Outside of fixed function devices... just doesn't work in practice. But even that doesn't actually stop so-called 'in memory' attacks. Scripting existing binaries together without needing to write to the disk is very much a thing in many modern attacks.
I tried a demo of ArcGIS on a project (converting ancient map data for my HOA) and it was, to put it nicely, complete garbage. A bag of hackish python scripts with no error detection or reporting. They still send me a beautiful, thick magazine full of pictures every few months. I guess we know where all that sweet government money goes: glossy brochures.
I'm not surprised it has a few holes in it.
and, its the global standard for GIS software in science and such. My son is a ****ogist, and they studied ARCgis in undergraduate school, and virtually everything is done in ARCgis. I tried to show him postGIS and what you could do with a little simple python scripting, and he was like 'this is the industry standard'.
"Enterprise software suite" is a synonym for "expensive price tag and well-compensated sales team". It is not a synonym for high software quality and enhanced security, an expensive enterprise software suite can still be essentially some base software coming with a bag of hacky scripts.
Surely there is some mistake. This can't be the same Chinese state that are not a threat to the UK, that are best buddies, trading partners and all round good eggs. Most probably the Chinese state were sponsoring this outfit to do an ethical hack to highlight the vulnerbilities.
https://www.bbc.co.uk/news/articles/c0ex172rxwzo
Nothing to see here. Move along now.
Yes, I read the article.
Yes, I agree that proprietary software labelled as "FOSS" with a similar insecure design would have been similarly vulnerable.
Free software is generally reasonably designed without insecurity like granting a server remote code execution by default.
Software of all kinds often implements the multi-server approach where users can access one server which can compute on another one. It's totally normal in software from all licenses, perhaps the most common example being the web server and database server being different boxes but having a connection that allows computation on and extracting data from the latter even though it's probably not available from the internet directly. Just like this example, the important part is hardening the connection between those things so that disruption of one doesn't immediately conquer the other, not generally done for or doable for you by the software author, and securing the outward facing server, which the operators of that server did not do properly.
You're using a chain of arguments, and most if not all links in that chain are flawed. Servers operating in a cluster is not insecure by default, and yes, that involves "remote code execution", although since they're supposed to be executing code for each other, the term can be misleading. Free software has, fortunately for us, often recognized the utility of clusters and therefore does often support it, including running code on other machines. This was insecure configuration, and insecure user configuration at that (they did not need to run this as root, but they did, they didn't need to have an easily-broken-into admin account, they did). Neither free software nor proprietary software can be relied upon not to have an insecure default config, but when you let users at it, either can be degraded if they choose to set too easy entrance methods. False credit does not help your preferred people.