security model

Robert J. Hansen rjh at sixdemonbag.org
Sun Jul 13 05:42:00 CEST 2025


> Both *should* be of concern, since a targeted attacker could certainly 
> use "drive-by" techniques, both to evade detection and possibly your 
> defenses, if you are so focused on targeted attacks that you miss 
> something.

Jacob, please don't tell me what should be of personal and professional 
concern to me.

You don't know what my risk environment is. For all you know I'm part of 
a security operations center at their APT desk, and the drive-bys are 
handled by a different unit. All I said is: my area of personal and 
professional interest is in targeted attacks by people who know what 
they're doing.

That said: yes, professionals and amateurs can run the same exploits. 
*Why* they are running the exploits, and their long-term goals in 
running the exploits, will differ.

I'm having a hard time thinking of something that would justify a 
targeted attacker doing a low-skill smash and grab without persistence. 
If the haul is valuable enough to justify that, then isn't it also 
enough to do the job *well*, including keeping it under the radar and 
persisting?

> If Mallory only wants a smash-and-grab...

Professional Mallory doesn't want a smash-and-grab.

Professional Mallory wants a haul. There's some trove of data that 
justifies the time, resources, and expense of Professional Mallory. If 
Professional Mallory has any choice in how to gain access, Professional 
Mallory will persist the access: because if this box has a top-flight 
haul today, who knows what it will have in six months?

Professional Mallory persists. Count on it.

> Client exploits typically do *not* produce log entries in the 
> first place, so there is nothing to clean up.

Consider the simplest form of drive-by, the stolen credential. Are you 
telling me Mallory's connection and exfiltration aren't going to appear 
in SFTP logs? Or that these logs don't need scrubbing?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250712/573ca89f/attachment.sig>


More information about the Gnupg-devel mailing list