The previous post covered counter-intrusion. This one looks at intrusion itself. But after going through a week-long HW (HW / national-level red-blue exercise), let me start there first. If you’re not in the security industry, you probably have no idea what HW means — or how massive it was in 2019, the 70th anniversary of the founding of the People’s Republic of China.
HW Overview
Group Level (集团)
Key characteristics:
- Fast attribution speed
- Rich resources — tools, threat intel, infrastructure — with broad operational authority
- High degree of systemization within domains, but automation across systems is still low; analysts still manually query across different platforms
- Can grind through all-nighters
The reason I listed “can grind through all-nighters” is to point out that staying up all night isn’t the goal, and it’s not something worth glorifying as a culture. Some people do it out of fear of senior leadership, others for career advancement down the line. But the real substance comes down to two things: technology and people.
Technology
- Fairly complete data collection across asset categories
- Solid infrastructure build-out and high familiarity with internal systems
People
- Strong team cohesion (within and across teams), with timely information flow (intel, strategy, etc.)
- Clear division of labor and coordination. Fast ability to look up and contact the right person for any issue that surfaces.
That said, the Group only pushed out threat intel externally, and even that wasn’t accurate enough. There was little output going down to the BU level, and cross-communication was largely blocked. What output did exist was heavily human-dependent, which made the whole relay slow.
BU Level
When it comes to BUs, I’ll speak from my own BU’s perspective — Local Life Services. It wouldn’t be appropriate to comment too much on the others.
- Good familiarity with existing resources, enabling fast attribution
- Asset category data still incomplete, with some gaps in the data pipeline build-out
- Capable of quickly automating investigation steps and chaining cross-system queries into one-click lookups
- Detection and remediation strategies are more limited compared to what’s available at the Group level
The overall feeling: BUs lacked communication with each other. Rather than defending as a unified Alibaba system, each BU was doing its own thing. Maybe Alibaba wasn’t the primary attack target, but overall it wasn’t up to standard.
The idea had been to use HW as an opportunity to bring counter-intrusion people from across BUs together to improve the small CRO line’s risk governance capabilities. But a lot of what got said was just lip service — “co-building,” “co-building” — yeah right. Asking the small CRO line to surface problems became a problem in itself.
Often the scariest moment is when you don’t know where the problems are. Take jump servers (bastion hosts) — you treat them as a critical entry protection layer, but you don’t know what unknown 0-days are lurking. And sure enough, this HW saw quite a few 0-days drop for VPNs and jump servers. Facing 0-days means facing the unknown, and the core problem is not knowing where that unknown is coming from. That’s exactly what makes regular drills so important — jump server primary/standby failovers, network isolation drills, etc.
Anyway, getting off track. If the Group is willing in the next 1-2 years to genuinely co-build and uplift the small CRO lines’ capabilities — pushing out platformized products and operational ecosystem support — that could be a real path forward. But it’s hard to do that. So the bottom line: technology governance is easy (there’s honestly not that much novel stuff in either intrusion or counter-intrusion techniques), but people governance is the hard part. To some extent, what we saw was tactical diligence masking strategic laziness. There’s a saying for that — you can’t use tactical effort to cover up strategic laziness. A lot of things still have room to improve.
Intrusion
Now that HW is out of the way, let’s talk about intrusion. I originally meant to include this in the previous post but forgot and just submitted it.
ATT&CK with Kill-Chain
Most of what shows up in public discourse is web application-based penetration attacks. But the full range of attack methods is much broader. I still remember S2-045 back in the day — I didn’t totally understand it, but running it felt great. Same with Dirty Cow. And of course OpenSSL Heartbleed. These represent attacks coming from completely different layers of the stack. Then there’s Redis AOF shell — writing a shell via Redis to a local file and getting code execution. A lot of these techniques and concepts aren’t new at all; they’ve been around for years. And as new security products emerge, those products themselves can also have vulnerabilities.
From initial network access all the way to destroying infrastructure or exfiltrating data, the highest-level tradecraft is coming and going without a trace. (That doesn’t mean unattributable — given solid enough infrastructure, no one gets away.) The lowest-level stuff is script kiddies showing off. You kind of can’t take them seriously, but you also can’t completely dismiss them. (laughs)
The first article I saw after HW wrapped was https://bithack.io/forum/352, which started circulating in friend groups — written from an attacker-side (vendor) perspective. It covered asset discovery and distributed scanning, and targeting people via targeted or bulk social engineering. The main focus was on 0-days. And the author is right — 0-days can bypass blacklist-based defenses, but not whitelist-based ones. That’s just how it is.
Besides technical attacks, there’s also physical security. A week before the HW targeting Alibaba kicked off, we had discussions with the physical security team: tightening access controls, vetting contractor onboarding, screening suspicious individuals, and so on.
Back to the technical side — whether your apps, services, data, or the hosts and network infrastructure carrying them are externally exposed or not, you’re going to face attacks. Web applications are still the most common entry point for attackers. And the lower the layer, the more fundamental it is, the harder it is to defend. Defending against a web application compromise and defending against an infrastructure-level compromise are clearly in different categories — think Intel Spectre/Meltdown. That said, I’m not trying to spread panic here. Everything comes down to evaluating the actual exploit method and conditions before drawing conclusions. (The researchers digging into protocol, OS, and kernel vulnerabilities — genuinely impressive.)
Internal Network Penetration, Lateral Movement
This section can be skipped. My own internal network pentesting experience is limited — fewer than 5 times total, and 2 of those I was already inside the network. So to avoid misleading anyone, take this with a grain of salt.
Breaking it down into production network internal vs corporate office network internal — the office network is generally easier to get into. From my own experience getting in from the outside: weak passwords on some OA (office automation) systems, GitHub credential leaks, and one case where after dropping a shell, SSH keys had already been pre-placed on the production network. All pretty basic stuff.
Once inside the office network: project management systems with credentials in plain text, no access controls, unpatched systems, and no internal network access controls to speak of. Internal network pentesting is easier than production network, and most companies pay little attention to this side of defense. At startups, sometimes there’s not even a guest WiFi — you come in for an interview and you can roam the entire internal network. Then there’s the classic USB drop. Awareness is weak, so it’s easy.
There are also second-order techniques — for example, an attack attempt gets blocked but the logs get collected, and a payload in the logs fires when someone goes to review them. Stuff like that.
Other Thoughts
Ground through a week of HW, completely drained. Daydreaming a bit — penetration testing should be teamable too: split roles from 0-day discovery, to POC validation, to tooling. Clear division of labor, one-click reverse shell, persistence, data exfil, and trace cleanup. Bingo, done.
From what I observed, setting aside technical skill variance, high-level people here pretty much all have high EQ, know how to play politics, and keep their emotions in check. They can always make things sound high-minded.
Recently reading Principles by Ray Dalio — almost done with the first section on his personal journey (business trips mean early mornings, which means faster reading). One thing that stuck with me:
Having the basics — a comfortable bed, good relationships, good food, a good sex life — is the most important thing. And those things don’t change much based on how much money you have.
We spend so much chasing our desires. Knowing your place in the world might actually be the most important thing.