> So it seems like a catalogue of (possible?) exploits in commonly-available executables, libraries and scripts that may already be present on a target machine
That is pretty correct, but it is not necessarily an exploit or vulnerability in the binary. More often than not, it is a quirk or a way to use the binary which is unknown/uncommon, but might not appear on a defenders' radar.
We generally try to (ab)use functionality in pre-existing software to avoid security mechanisms (like AppLocker) and detections (like AV/EDR, or rules created by a SOC when analysing execution logs in a SIEM). Often we discover that a target computer has been hardened in some form or fashion, and we have to get "creative" when trying to download, execute or exfiltrate data during security assessments.
Yep, and to make it even more clear as an author of one of these LOLBins (Squirrel.exe), I have to underscore this point again - this list doesn't apply to normal Windows installations, it is only meaningful in the context of Blue teams trying to create their own hardened security boundaries via AV/EDR/AppLocker, and Red teams trying to evade said tools
(inb4 the comments, Squirrel itself attempts to strike a balance between usability and security, running only as the current user without admin limits its potential to be exploited, since any "I can hack Squirrel to run my code" trick is "Rather Involved Being On The Same Side Of The Airtight Hatch", as Raymond Chen would say)
It’s dual use, like Metasploit. It’s hard to predict whether black hats or white hats will use it more often or not. I think your conclusion is more intuitive, but let me play devil’s advocate.
LotL is too advanced for script kiddies to pull off. You’re already dealing with an adversary with some sophistication, who likely have the time, skill, and resources to create their own LOLbins (or buy them on darknet forums). Infosec is an asymmetric conflict: the adversary has a much easier job IMO. It’s always easier to break something than to build it.
Blue/purple teams have little incentive to build their own LOLbins. There is another asymmetry here: blue teams are developing these to target only their networks. Red teams are developing them to target every network. Open source is the way to resolve that asymmetry.
With these becoming public, blue teams can simulate a LotL attack, develop indicators of attack, and write rules to trigger alerts.
In general, adversaries prefer their tricks to remain trade secrets. Once they’re known, documented, and commodified, they become far less useful.
I'm not saying that it is bad those are out, I'm saying by volume they'd be used more by "slightly advanced script kiddies", and as part of bigger tools.
Sure it might make it easier for red teams to help secure system, but for organizations bad at security they will be hit by that low hanging fruit methods, even if it might make more aware organizations more secure. Just because it lowers the point of entry.
Or sometimes a person shows up at a new IT job and the old admin didn't leave behind any notes and the only way to do the job at all short of rebuilding everything from the ground up is to pwn the network.
To be honest I would rather have the vote arrow moved somewhere else. I'm often more interested in collapsing a comment thread than voting. I'm not sure if this is something only I care about though.
It'd be hard to say what most users prefer. I would venture to guess that we're all conditioned to vote before collapsing comments simply because we've never had the option to collapse comments until today. So behavior preferences will change over time.
However, I'll hypothesize that it's preferable (overall) to have more friction on collapsing comments. A lot of great discussion happens in response to even a mediocre top-level comment, and forcing the user to take a few extra moments to skim the child-comments will increase the serendipitous discovery of these nested gems. Furthermore, the problem of a mediocre top-level comment with mediocre nested comments being at the actual top of the discussion is mitigated by the ability for people to downvote the thread, as has been done (with varying levels of efficacy) until today.
> . . . forcing the user to take a few extra moments to skim the child-comments will increase the serendipitous discovery of these nested gems.
Excellent phrasing. As a fairly long-time user who lurks more than he comments, I can concur that much of the best conversation I've read and participated in happened to be such nested gems. Serendipitous, indeed.
>A lot of great discussion happens in response to even a mediocre top-level comment, and forcing the user to take a few extra moments to skim the child-comments will increase the serendipitous discovery of these nested gems.
Is this actually data-driven or just a guess on your part? My experience is that a mediocre comment rarely ever gets good replies.
Anecdotal; comment vote scores aren't exposed so I'm not sure if an analysis is possible, even with what's been loaded on to BigQuery [0].
Maybe "mediocre" is the wrong word, as it implies an absolute judgment (on some non-existent scale of "quality"). I guess my intuition is derivative of the "don't judge a book by its cover", in that even if a submitted and upvoted story is not something I feel like reading, I still might read the comments to see the discussion.
Maybe someone internal to HN can do a quick calculation of how many child-comments surpass their parents (while accounting for the differences in visibility).
Why I agree with you, and would argue for putting the vote arrows somewhere else, is that voting should only happen after someone has fully read a comment and at least given it a second to think about it. It makes more sense for the collapse functionality to always be in the same place so you can do it somewhat "mindlessly", but for voting you specifically don't want to be able to do it mindlessly.
That is pretty correct, but it is not necessarily an exploit or vulnerability in the binary. More often than not, it is a quirk or a way to use the binary which is unknown/uncommon, but might not appear on a defenders' radar.
We generally try to (ab)use functionality in pre-existing software to avoid security mechanisms (like AppLocker) and detections (like AV/EDR, or rules created by a SOC when analysing execution logs in a SIEM). Often we discover that a target computer has been hardened in some form or fashion, and we have to get "creative" when trying to download, execute or exfiltrate data during security assessments.