security model

[Jacob Bachmeyer]

On 7/13/25 00:36, Robert J. Hansen wrote:
> [...]
>> Persistence and evading detection are a tradeoff for the attacker.
>
> They are not. Often, evading detection assists in persistence by
> reducing the amount of evidence that might trigger a sysadmin's 
> attention.
>
> If you mean to say persistence always increases the signature that must
> be concealed, there I'd mostly agree.

That is the tradeoff I was referring to:  tampering the system to enable 
or improve persistence leaves artifacts for the sysadmin to discover.

>> Further, Mallory may not have the goals you assume.  If Mallory is a
>> professional, making the attack look like a low-skill smash and grab
>> could, for example, be a strategy to avoid raising alarm at the 
>> targets that they *are* targets.
>
> I don't understand. Executing a successful high-profile exfiltration
> from a target which is sure to be spotted by the sysadmin ... avoids
> letting the sysadmin know they've been targeted?
>
> Targeted *by whom*, maybe. Changing TTP for misattribution purposes is
> definitely a thing. With that change, I agree.

That is more-or-less what I was saying:  if it looks like an 
opportunistic attack, the target is less likely to expect a repeat 
performance.  While any half-competent sysadmin is going to treat the 
incident as a wake-up call to tighten security, getting management to 
agree without evidence of an ongoing threat can be difficult.

Therefore, Professional Mallory can benefit from making a targeted 
attack *look* like an opportunistic attack.

>> Logically, the box is most likely to have about the same, except that 
>> a second copy of the same haul is valueless to Mallory.
>
> Why should this be the default assumption? This is a computer, not a
> cuneiform tablet: data is added and removed constantly. If right now it
> has valuable data, it's at least as possible that in the future it will
> continue to receive valuable data.

Not entirely the same, but the question I was getting towards is "how 
much additional value will Mallory expect from hitting the same target 
again in six months?"  Now, if the cost of coming back in six months is 
basically nil, Mallory's cost-benefit calculation is skewed accordingly 
and you can expect a return even if there is unlikely to be new data.

>> In short, there is no amount of persistence that can save Mallory's 
>> access once the target becomes aware of it and gets serious about 
>> kicking Mallory out.
>
> Salt Typhoon would appear to be a counterexample.

As far as I can tell, Salt Typhoon reliably gets kicked out; they just 
keep finding new targets and/or pulling off new intrusions. (I consider 
"backdoor found; backdoor removed" to be "Mallory kicked out" although 
that does *not* preclude Mallory from finding another way in... perhaps 
the same way that backdoor had been planted...)

Salt Typhoon/GhostEmperor is also an example of why I would not expect 
logs to exist in the first place.  While they *do* escalate (and how), 
the remote filesystem access is provided by their malware instead of 
using system facilities that would keep logs. Malware executing in an 
unprivileged context could do the same with the user's files.

>> If Mallory expects to get back in just as easily six months from now, 
>> why leave something that an attentive admin might notice
>
> Great question (zero sarcasm). My answer would be, "in the example you
> give, the access is already a persistent access, so the persistency
> objective is already done for Mallory by the negligence of the sysadmin."

Or reluctance by management to allocate needed resources---apparently 
that server had been getting hit repeatedly since before I worked 
there.  I was explicitly told to *not* bother tracing how the IRC bot 
had gotten in, just remove it and consider the box secured.  8-(

>> Clients keep SFTP logs?  Are you assuming that Mallory steals the 
>> user's password and then connects to sshd on the user's box to make 
>> off with the user's files?
>
> Remote access, yes.
>
>> I have been talking about attacks on clients, not servers, because 
>> GnuPG is most typically run on client nodes.  Indeed, as far as I 
>> know, the PGP security model is focused on clients---the boxes 
>> physically used by the users. Servers are categorically untrusted in 
>> PGP.
>
> In today's environment, you have to work really hard to even have a
> meaningful network perimeter. I'm unconvinced it makes much sense
> nowadays to talk about clean client/server distinctions at the machine
> level. At the app level, maybe.

I agree that there is a serious problem with loose default 
configurations.  In particular, a box used with keyboard and local 
display probably should not be running sshd, but it seems that most 
distributions enable sshd by default.

In other words, on my "client" boxes, there are no SFTP logs because 
there is no SFTP listener.  Mallory cannot exploit a service that is not 
running.  :-D


-- Jacob