The MO is that they are a state attacker, not a one trick pony.

Until proven otherwise, you should assume that in addition to what you know they did, they did everything you can think of that is within their known capabilities. Super fancy BIOS rootkits are not outside their known capabilities.

Also monitoring egress traffic is easier said than done. For example you could have a special gmail account that you connect to over https while the user is actively using the computer. This account receives and sends commands as email messages. Since it is normal for that computer to connect to gmail, and the connection is normally encrypted, that communications channel could be rather hard to detect.

Sorry, I should have stated that better. I'm not talking about, "best practice for an advanced attack from an unknown perpetrator". I absolutely agree with you in general.

I'm saying that, this particular attacker, is a known, identifiable actor. They have names, they have huge reams of files in manilla envelopes. If you are privy, you get to know their actual names, see photos of them.

They have a very specific methodology which they use. You use that methodology to determine the extent of what they've accomplished. This specific actor is not using any super fancy BIOS rootkits.

If one of their campaigns ever gets to the point that they are unable to obtain repeatable persistent access, that campaign is sent to a different actor (with a completely different big manilla envelope about) who will then attempt a more advanced campaign.

The tools and tactics for these intrusions are very specific to the actual actors responsible.

Your reply has a lot of very specific information about the attack, attacker, and state of the compromise that I find rather dubious and cannot find in the article. Do you have a source that you would care to share?

Furthermore in this case we've been told that the attacker managed to achieve a rather thorough compromise of the network. And managed to persist through multiple attempts to remove them. Even if the attack proceeded by the rules that you describe, it would be foolhardy to assume that they were not subjected to the advanced campaign.

You aren't assuming, you are looking on all machines for IOC's (specifically machines that have been compromised before), and hopefully making use of all that fancy network security monitoring technology you paid entirely too much money for.

And you're monitoring outbound connections to any of the places which are known to be "bad neighborhoods", as well as any other suspicious traffic.

In the gmail example you used, it would indeed be difficult to see that on the network. If that was sent out by some BIOS rootkit it would indeed be very difficult to detect.

I have no idea why we don't see more of that stuff (I suppose you could argue that we wouldn't recognize it even if we did), but that's not been the level of attack associated with these actors.

I suppose the main reason they don't do that is because they don't need to. They will just keep sending malicious emails over and over again until they get someone to click on one.

Or, if the company does a good job with protecting email, they'll compromise another company that partners with the target company (which is what ensnares a lot of small companies today, who are partners with larger defense contractors) and exploit a trust relationship there.

It might just be that the five guys they have who can write BIOS rootkits are all busy being used on projects that have more strategic importance. The shortage of good programmers isn't just a problem in the west.

I was trying to figure out how you think you know all of this when I clicked on your profile. Then the thought suddenly hit me that publicly disclosing details about how we think they work, and what we actually look for in cleaning up, might not be the best thing to do on a forum that is world accessible.

Also if you're right, I'm depressed that they don't in practice use ideas that have been publicly known for decades.

One final thought. The gmail approach would leave fingerprints in Google's system. The actor in question could easily have some paranoia about doing that, even though Google would be unlikely to notice.

So I've tried to be careful to not discuss anything on here that I wouldn't give in a talk in a public forum (we are working on sharing nonclass information, as many of the companies in my area are all particular targets for these attacks. It's almost like a 12-step program.)

And I share your sadness that we're still dealing with these types of attacks, when we could make things so much more difficult for attackers by just implementing the things we've learned in the past thirty years.

I feel a little torn, though, because I also worry about what unintended consequences would arise if we actually replaced all of our infrastructure with things like hardware roots of trust, and trusted network connect implementations (which are systems which really provide very little value unless everything on your network uses them). Whether that's just moving the ball ten yards forward, when we still struggle to engineer large systems in a secure manner.

If that depresses you, I worry how you'd react when most organizations balk even at the prospect of a mass password reset. How many try to argue why can't they just reset the ones that you "know" are compromised? Or how long it takes to get said password reset signed-off and put into the change management process.

For what it's worth, I work a lot now with TPM's, and even the places that have actually gone through the trouble of rolling out bios measurements and signed firmware, are still getting breached.

> but don't match up with the M.O. of the perpetrators in question

Oh, the hubris.

This statement may be true (and probably is), but the perpetrators might also be running a BIOS rootkit at the same time - unless you actually pull the bios chip out and read it in another machine, you cannot tell. If you haven't already, read Ken Thompson's "Reflections on Trusting Trust", and mentally replace every occurrence of "C compiler" with "BIOS" and "login" with "Hypervisor".

> It can take several times before you sound an "all-clear".

I seriously hope no one takes this as security advice. You should read on "covert channels" (e.g. in Tannenbaum's OS book) - this advice is rubbish if you are dealing with a targeted attack (which is known to be the case here).

It's probably acceptable advice against "drive by" and other opportunistic malware.

An important pillar of real (rather than perceived) IT security is that once a system has been compromised, you can hardly trust anything about it anymore. Things were simpler in the past, when BIOS was an EPROM (not rewritable by software), CPUs had no virtualization support (so you knew what you see from the inside is what's really there), and the world wasn't as connected.

Nowadays, if you really care about targeted attacks, and you trust your suppliers (a given; if you don't, you can't use a computer), it is always cheaper to replace a system than attempt to verify it clean.

I don't disagree with anything you've written, but remediation from these attacks almost never involves replacing any of the hardware (with the possible exception of when a laptop belongs to an executive, and it becomes easier to just set them up with a new one and swap it out).

> remediation from these attacks almost never involves replacing any of the hardware

That's true. But it should, if you care about security.

Equivalent: Proper backup procedures are seldom made or tested. They should (and they do happen once there's enough CYA involved, or one of the involved parties has experienced some previous catastrophic event)