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?

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel

Reply via email to