by Kovah on 7/30/24, 8:39 AM with 42 comments
by legobeet on 7/30/24, 3:21 PM
For example, an application-specific HTTP proxy for your GITHUB_TOKEN. You can use a canary token for the internal user-facing auth. https://github.com/legobeat/git-auth-proxy [0].
That piece is being used here[1] in order to make it transparent for the user and I intend to add more features there for credentials- and secrets compartmentalization. Been keeping it fairly structured so you could also use it as a reference if you ever do similar stuff and want some inspiration or copypasta for your personal hacking.
[0]: Caveat: The proxy repo is a fork and the documentation is still more reflective of the previous owners intentions. I ripped out all the Azure/k8s integrations.
by Tiberium on 7/30/24, 2:31 PM
by notepad0x90 on 7/30/24, 12:46 PM
https://learn.microsoft.com/en-us/defender-xdr/deception-ove...
But in my opinion, deception tech is best implemented in-house. Nothing wrong with using externally developed tools, especially for high signal-to-noise things like honeypots but the actual monitoring and alerting data flow should be ideally be environment specific.
by aflukasz on 7/30/24, 5:36 PM
`-p rxwa` causes logging of any read, exec, write or attributes change on that file. More in `man auditctl`.
Among others, this has a benefit that, in principle, such honeypot triggers immediately and not only after someone decides to try using some actual credentials/data.
Obviously needs some work to make this robust (logs monitoring plus alerting), but it's a nice building block worth knowing and, if you care, then you probably already have those additional pieces in place anyway.
by dredmorbius on 7/30/24, 11:27 AM
by pjot on 7/30/24, 2:11 PM
by westpfelia on 7/30/24, 12:12 PM
Super easy to configure via webhooks into a siem or any kind of alerting platform.
by dredmorbius on 7/30/24, 11:26 AM
by jesprenj on 7/30/24, 1:40 PM
by declan_roberts on 7/30/24, 10:23 PM
by shortsunblack on 7/30/24, 10:31 PM