Did someone already set up a honeypot with valid .env credentials and honeytokens?

I'm really curious about a specific IP (78[.]153[.]140[.]171) which is hammering a shitload of virtual hosts with different .env paths.

I'd love to understand where these credentials are actually being used later on.

#honeytoken #honeypot #cybersecurity

#ddp #deception #honeytoken #canary #maturity #framework

Модель зрелости использования обманных систем

Неплохой фреймворк (https://deceptiq.com/blog/cyber-deception-maturity-model) от компании DECEPTIQ: для каждого уровня зрелости есть описание, стратегии развития и ключевые метрики для отслеживания. Дополнительно имеется опросник для определения текущего уровня зрелости, а в конце авторы развенчивают распространенные мифы, связанные с внедрением обманных систем.

Помимо вышеуказанного фреймворка можно ещё рассмотреть "канареечную" модель зрелости (https://tracebit.com/blog/the-security-canary-maturity-model) от Tracebit: она проще и ограничивается уровнем использования приманок (ханитокенов, "канареек").

We have added deceptive decoys to a Capture The Flag challenge and monitored players.

Did that work? YES 🙂​

More details here: https://blogs.sap.com/2023/11/15/disinformation-for-the-greater-good/

#deception #cyberdeception #honeytoken

Do you use honeytoken accounts or devices in your organization?

#Honeytoken #accounts are accounts that serve as bait for a threat actor. From an organization's perspective, these are standard accounts, usually equivalent to a regular employee's account. The only difference is that no one uses these accounts.

Honeytoken accounts can also be configured in Microsoft Defender for Identity (#MDI). Any activity on such an account is then immediately reported as an incident in Microsoft 365 Defender. In addition to user accounts, it is also possible to add honeytoken devices with a similar principle.

Why would you want to create #honeytoken accounts in your customer DB?

Aren’t you simply creating stale data without any practical application?

Here is why: https://www.jbspeakr.cc/honeytoken-accounts-credential-breach/

#threatdetection #breachdata

Experimenting with application intrusion #detection and #response changed how I look at certain practices such as penetration tests and reports coming from the testing team. This is many years ago where my team received a pentest report of a web application we have been working on, however, before we received the report, I started looking for signs and indicators of what the pentesters tried out - XSS, SQLi and other common attacks and payloads - in the UI. I noticed that they also tried a CSV injection attack in one part of the web application which had a CSV file export. This did not end up in the report that we received as they did not manage to find a CSV injection vulnerability - the input they tried to inject into was never part of the exported CSV file. However, a while after we got the report, we started introducing a change in the code of the CSV file export and guess what this change was: it now included the input that the pentesting team tried to inject into. We were luckily changing the code without introducing a vulnerability, however, I keep thinking about this a lot since we more or less dodged this bullet because of a manual method of searching for what the pentesting team has been up to.

Instead of manually searching through logs or other resources for indicators of an attack, why not create detection points for the web application that focus only on blatant attack(er) activity and create dedicated logging for intrusion detection?

Here are some example categories of detection points:

* Monitoring and logging of suspicious activity that could never come from a benign user:
- Why would a benign user change a cookie (#honeytoken) value that was never meant to be touched ;)
- Why should your server-side input validators fail when the input should have been rejected by the same validators on the client-side?
* Monitoring and logging of attacker-induced errors and exceptions:
- Syntax errors may be caused by code injection probes (e.g., SQLi)
* Monitoring and logging the performance of security controls:
- Did the CSV escaping mechanism really prevent the CSV injection attack?

Especially the second category of detection points is noteworthy as it touches on the idea that an attacker will be eventually successful - errors and exceptions in this case might be the first sign and should therefore not be neglected. But that does not mean that we can't do anything about it ;)

To learn how to implement such detection points for your web applications, have a look at the very good OWASP resources that guide you how to make web applications attack(er)-aware and self-defending:

* OWASP AppSensor - Comprehensive Guide and Detection Points:
https://owasp.org/www-project-appsensor/
* OWASP Top Ten Proactive Controls - Implement Security Logging and Monitoring:
https://owasp.org/www-project-proactive-controls/v3/en/c9-security-logging
* OWASP Testing Guide - Test Defenses Against Application Misuse:
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/07-Test_Defenses_Against_Application_Misuse
* OWASP Code Review Guide - Reviewing Security Alerts, Review for Active Defense:
https://owasp.org/www-project-code-review-guide/
* OWASP Application Logging Vocabulary Cheat Sheet:
https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html

This is one of my first posts where I will speak more about the topic of attack-aware web application development and #defendabledesign - the hashtag which I will use from now on for this topic ;)

Hope you all have a nice evening and weekend, see you around!

#infosec #dfir #blueteam #appsec #webdevelopment #websecurity