LOLBAS: Living Off the Land Binaries, Scripts and Libraries
lolbas-project.github.io
lolbas-project.github.io
> The goal of the LOLBAS project is to document every binary, script, and library that can be used for Living Off The Land techniques.
> The phrase "Living off the land" was coined by Christopher Campbell (@obscuresec) & Matt Graeber (@mattifestation) at DerbyCon 3.
> The term LOLBins came from a Twitter discussion on what to call binaries that can be used by an attacker to perform actions beyond their original purpose.
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.
It will absolutely be used more often to exploit than to secure
Red is typically 'mischief' and Blue is typically 'mischief prevention.'
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.
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.
(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)
I’ve been manually going to find this kind of documentation since forever. This is great and so helpful
https://news.ycombinator.com/item?id=36628976 (79 comments)
These days, lolbas binaries get you caught by security tools unless you're very creative.
What does "C&C" mean in this context? I couldn't find an explanation on the site.
Find it here: loobins.io
Also layout is confusing, capabilities don’t appear after the executable name, rather the executable name iis vertically centered against the list of features.
Use only what's available to cause mischief or prevent mischief. The rules don't allow use of your own scripts, tools, etc. Typically red teams are mischief makers and blue teams are the prevention.
What is this? Please update the link to point to what this actually is. If it's interesting to someone, they'll find the files.
The associated github is much more informative about what the project does. Basically they document "undocumented" capabilities of signed microsoft binaries that can be used for red team work.
This is actually really great package documentation IMO
Edit: Because apparently this isn't clear enough:
1. Real world phenomena and technical projects are two distinctive categories, each encompassing a wealth of unique information.
2. Namespaces serve as unique identifiers, used to prevent naming conflicts in various domains.
3. When these namespaces are used within both real-world phenomena and technical projects, they overlap.
4. Overlapping namespaces, by their nature, blur the boundaries between distinctive categories.
5. Search engines operate by categorizing and associating information based on identifiers, specifically namespaces.
6. When these identifiers are blurred, the precision of search engines is compromised.
7. As search engine precision diminishes, the efficacy of search results for users decreases.
8. The reduction in search results efficacy translates to increased search times and decreased productivity, or an inability to find anything about the topic whatsoever due to results pruning.
9. A decrease in productivity is an indirect impact of namespace pollution, disrupting both those living in the real-world and those looking for technical information.
10. We already have to deal with SEO. We shouldn't need to deal with this as well.