From 4c799d484bf244724c32aad4acb1acff098303b2 Mon Sep 17 00:00:00 2001 From: Samuel Gaist Date: Fri, 7 Nov 2025 13:49:19 +0100 Subject: [PATCH 1/6] feat: add pre-commit hooks Signed-off-by: Samuel Gaist --- .pre-commit-config.yaml | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 .pre-commit-config.yaml diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml new file mode 100644 index 00000000..ae49ff89 --- /dev/null +++ b/.pre-commit-config.yaml @@ -0,0 +1,20 @@ +# See https://pre-commit.com for more information +# See https://pre-commit.com/hooks.html for more hooks +fail_fast: false +minimum_pre_commit_version: '0' +repos: +- repo: https://github.com/pre-commit/pre-commit-hooks + rev: v6.0.0 + hooks: + - id: check-added-large-files + - id: check-yaml + - id: check-case-conflict + - id: trailing-whitespace + - id: end-of-file-fixer +- repo: local + hooks: + - id: dco-hook-local + name: DCO hook local + entry: ./tools/local_hooks/dco-pre-commit-msg.sh + language: script + stages: [prepare-commit-msg] From d710909651ec3f6c62016eef5bfd3db6e1402eed Mon Sep 17 00:00:00 2001 From: Samuel Gaist Date: Fri, 7 Nov 2025 13:49:42 +0100 Subject: [PATCH 2/6] chore: applied cleanup from pre-commit Signed-off-by: Samuel Gaist --- .github/scripts/rules_overview_generator.py | 20 +- .github/workflows/registry.yaml | 2 +- .github/workflows/yaml-lint.yaml | 10 +- .gitignore | 1 - CONTRIBUTING.md | 6 +- LICENSE | 2 +- README.md | 6 +- RELEASE.md | 2 +- archive/falco-deprecated_rules.yaml | 58 +-- build/checker/.gitignore | 2 +- build/mitre_attack_checker/README.md | 48 ++- .../tests/resources/not_falco_rules_test.yaml | 2 +- build/registry/testdata/rules-failed-req.yaml | 2 +- .../registry/testdata/rules-numeric-req.yaml | 2 +- build/registry/testdata/rules-semver-req.yaml | 2 +- ...-adoption-management-maturity-framework.md | 74 ++-- rules/falco-incubating_rules.yaml | 314 ++++++++-------- rules/falco-sandbox_rules.yaml | 344 +++++++++--------- rules/falco_rules.yaml | 332 ++++++++--------- 19 files changed, 613 insertions(+), 616 deletions(-) diff --git a/.github/scripts/rules_overview_generator.py b/.github/scripts/rules_overview_generator.py index 9b0b6488..38c07dde 100644 --- a/.github/scripts/rules_overview_generator.py +++ b/.github/scripts/rules_overview_generator.py @@ -53,7 +53,7 @@ def rules_to_df(rules_dir): else: item['mitre_ttp'].append('[{}]({}{})'.format(i, BASE_MITRE_URL_TECHNIQUE, i.replace('.', '/'))) else: - item['extra_tags'].append(i) + item['extra_tags'].append(i) item['workload'].sort() item['mitre_phase'].sort() item['mitre_ttp'].sort() @@ -63,7 +63,7 @@ def rules_to_df(rules_dir): item['extra_tags_list'] = item['extra_tags'] item['compliance_pci_dss_list'] = item['compliance_pci_dss'] item['compliance_nist_list'] = item['compliance_nist'] - item['enabled'] = (item['enabled'] if 'enabled' in item else True) + item['enabled'] = (item['enabled'] if 'enabled' in item else True) l.append([', '.join(item[x]) if x in ['maturity', 'workload', 'mitre_phase', 'mitre_ttp', 'compliance_pci_dss', 'compliance_nist', 'extra_tags'] else item[x] for x in COLUMNS]) if not l: @@ -100,23 +100,23 @@ def print_markdown(df): print('This document provides an extensive overview of community-contributed syscall and container event-based rules. It offers resources for learning about these rules, promoting successful adoption, and driving future enhancements.\n') print('\n[Stable Falco Rules](#stable-falco-rules) | [Incubating Falco Rules](#incubating-falco-rules) | [Sandbox Falco Rules](#sandbox-falco-rules) | [Deprecated Falco Rules](#deprecated-falco-rules) | [Falco Rules Stats](#falco-rules-stats)\n') print('\nThe tables below can be scrolled to the right.\n') - + print('\n## Stable Falco Rules\n') print('\n{} stable Falco rules ({:.2f}% of rules) are included in the Falco release package:\n'.format(len(df_stable), (100.0 * len(df_stable) / n_rules))) print(df_stable.to_markdown(index=False)) - + print('\n## Incubating Falco Rules\n') print('\n{} incubating Falco rules ({:.2f}% of rules):\n'.format(len(df_incubating), (100.0 * len(df_incubating) / n_rules))) print(df_incubating.to_markdown(index=False)) - + print('\n## Sandbox Falco Rules\n') print('\n{} sandbox Falco rules ({:.2f}% of rules):\n'.format(len(df_sandbox), (100.0 * len(df_sandbox) / n_rules))) print(df_sandbox.to_markdown(index=False)) - + print('\n## Deprecated Falco Rules\n') print('\n{} deprecated Falco rules ({:.2f}% of rules):\n'.format(len(df_deprecated), (100.0 * len(df_deprecated) / n_rules))) print(df_deprecated.to_markdown(index=False)) - + print('\n# Falco Rules Stats\n') print('\n### Falco rules per workload type:\n') df1 = df.groupby('workload').agg(rule_count=('workload', 'count')) @@ -135,7 +135,7 @@ def print_markdown(df): df2['
rules
'] = df2['rule'].apply(lambda x: x[0]) df2['
percentage
'] = df2['rule'].apply(lambda x: round((100.0 * x[1] / n_rules), 2)).astype(str) + '%' print(df2.drop('rule', axis=1).to_markdown(index=True)) - + print('\n### Compliance-related Falco rules:\n') df3 = df df3['compliance_tag'] = df['compliance_pci_dss_list'] + df['compliance_nist_list'] @@ -149,11 +149,11 @@ def print_markdown(df): # df3['percentage'] = df3['rule'].apply(lambda x: round((100.0 * x[1] / n_rules), 2)).astype(str) + '%' print(df3.drop('rule', axis=1).to_markdown(index=True)) - + if __name__ == '__main__': args_parsed = arg_parser() rules_dir = args_parsed.rules_dir - + if not rules_dir or not os.path.isdir(rules_dir): sys.exit('No valid rules directory provided via --rules_dir arg, exiting ...') diff --git a/.github/workflows/registry.yaml b/.github/workflows/registry.yaml index 06098aa6..a2784ab5 100644 --- a/.github/workflows/registry.yaml +++ b/.github/workflows/registry.yaml @@ -21,7 +21,7 @@ jobs: - name: Build registry artifact tool working-directory: build/registry run: go build -o rules-registry ./... - + - name: Test registry artifact tool working-directory: build/registry run: go test ./... -cover diff --git a/.github/workflows/yaml-lint.yaml b/.github/workflows/yaml-lint.yaml index 42288dd4..eb36288a 100644 --- a/.github/workflows/yaml-lint.yaml +++ b/.github/workflows/yaml-lint.yaml @@ -1,11 +1,11 @@ name: Yamllint Github Actions -on: +on: pull_request: - branches: + branches: - main -jobs: - lintFalcoRules: +jobs: + lintFalcoRules: name: Yamllint runs-on: ubuntu-latest steps: @@ -13,7 +13,7 @@ jobs: uses: actions/checkout@v6 - name: yaml-lint uses: ibiqlik/action-yamllint@v3 - with: + with: file_or_dir: rules/*.yaml env: YAMLLINT_CONFIG_FILE: .github/workflows/.yamllint diff --git a/.gitignore b/.gitignore index 8e79fb27..75ede6f9 100644 --- a/.gitignore +++ b/.gitignore @@ -193,4 +193,3 @@ cython_debug/ # option (not recommended) you can uncomment the following to ignore the entire idea folder. .idea/ .run/ - diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8b4d7b67..b2fee004 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -15,7 +15,7 @@ All rules must be licensed under the [Apache 2.0 License](./LICENSE). # Rules Maturity Framework -The rules maturity framework was established following this [proposal](proposals/20230605-rules-adoption-management-maturity-framework.md). +The rules maturity framework was established following this [proposal](proposals/20230605-rules-adoption-management-maturity-framework.md). At a high level, The Falco Project maintains community-contributed syscall and container event-based [rules](https://github.com/falcosecurity/rules/blob/main/rules/), with `maturity_stable` tagged rules being included in the Falco release package. Other maturity-level rules are released separately, requiring explicit installation and possible customization for effective. In essence, there are now dedicated rule files for each maturity level. @@ -48,7 +48,7 @@ Special note regarding *plugins* rules: The rules for different Falco [plugins]( The levels: - **maturity_stable** indicates that the rule has undergone thorough evaluation by experts with hands-on production experience. These experts have determined that the rules embody best practices and exhibit optimal robustness, making it more difficult for attackers to bypass Falco. These rules are highly relevant for addressing broader threats and are recommended for customization to specific environments if necessary. They primarily focus on universal system-level detections, such as generic reverse shells or container escapes, which establish a solid baseline for threat detection across diverse industries. This inherent bias against including more application-specific detections is due to their potential lack of broad relevance or applicability. However, to mitigate this bias, the maintainers reserve the right to make judgments on a case-by-case basis. -- **maturity_incubating** indicates that the rules address relevant threats, provide a certain level of robustness guarantee, and adhere to best practices in rule writing. Furthermore, it signifies that the rules have been identified by experts as catering to more specific use cases, which may or may not be relevant for each adopter. This category is expected to include a larger number of application-specific rules. +- **maturity_incubating** indicates that the rules address relevant threats, provide a certain level of robustness guarantee, and adhere to best practices in rule writing. Furthermore, it signifies that the rules have been identified by experts as catering to more specific use cases, which may or may not be relevant for each adopter. This category is expected to include a larger number of application-specific rules. - **maturity_sandbox** indicates that the rule is in an experimental stage. The potential for broader usefulness and relevance of "sandbox" rules is currently being assessed. These rules can serve as inspiration and adhere to the minimum acceptance criteria for rules. - **maturity_deprecated** indicates that, upon re-assessment, the rule was deemed less applicable to the broader community. Each adopter needs to determine the relevance of these rules on their own. They are kept as examples but are no longer actively supported or tuned by The Falco Project. @@ -56,7 +56,7 @@ In summary, the rules maturity tag reflects the robustness, relevance, applicabi ## Justification of Rules Maturity Framework for Falco Adoption -A rules maturity framework has been introduced for Falco users to facilitate the adoption of non-custom rules more effectively. This framework ensures a smooth transition for adopters, whether they use rules generically or for specific use cases. A smooth adoption process is defined by making it easy for adopters to understand each rule and also gain an understanding of not just what the rule is doing, but also how beneficial it can be under various circumstances. +A rules maturity framework has been introduced for Falco users to facilitate the adoption of non-custom rules more effectively. This framework ensures a smooth transition for adopters, whether they use rules generically or for specific use cases. A smooth adoption process is defined by making it easy for adopters to understand each rule and also gain an understanding of not just what the rule is doing, but also how beneficial it can be under various circumstances. Additionally, due to this framework, adopters should find themselves with a clearer understanding of which rules can likely be adopted as-is versus which rules may require significant engineering efforts to evaluate and adopt. The rules maturity framework aligns with the [status](https://github.com/falcosecurity/evolution/blob/main/REPOSITORIES.md#status) levels used within The Falco Project repositories, namely "Stable", "Incubating", "Sandbox" and "Deprecated". diff --git a/LICENSE b/LICENSE index 26f5f0fe..2fad7131 100644 --- a/LICENSE +++ b/LICENSE @@ -199,4 +199,4 @@ distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and - limitations under the License. \ No newline at end of file + limitations under the License. diff --git a/README.md b/README.md index 1e5d22e8..3666ac64 100644 --- a/README.md +++ b/README.md @@ -1,8 +1,8 @@ # Falco Rules -[![Latest release](https://img.shields.io/github/v/release/falcosecurity/rules?label=Latest%20Rules%20Release&style=for-the-badge)](https://github.com/falcosecurity/rules/releases/latest) [![Compatible Falco release](https://img.shields.io/github/v/release/falcosecurity/falco?label=Compatible%20Falco%20Release&style=for-the-badge)](https://github.com/falcosecurity/falco/releases/latest) +[![Latest release](https://img.shields.io/github/v/release/falcosecurity/rules?label=Latest%20Rules%20Release&style=for-the-badge)](https://github.com/falcosecurity/rules/releases/latest) [![Compatible Falco release](https://img.shields.io/github/v/release/falcosecurity/falco?label=Compatible%20Falco%20Release&style=for-the-badge)](https://github.com/falcosecurity/falco/releases/latest) -[![Docs](https://img.shields.io/badge/docs-latest-green.svg?style=for-the-badge)](https://falco.org/docs/rules) [![Rules Overview](https://img.shields.io/badge/docs-latest-green.svg?label=Rules%20Overview&style=for-the-badge)](https://falcosecurity.github.io/rules/) [![Style Guide](https://img.shields.io/badge/docs-latest-green.svg?label=Style%20Guide&style=for-the-badge)](https://falco.org/docs/rules/style-guide/) +[![Docs](https://img.shields.io/badge/docs-latest-green.svg?style=for-the-badge)](https://falco.org/docs/rules) [![Rules Overview](https://img.shields.io/badge/docs-latest-green.svg?label=Rules%20Overview&style=for-the-badge)](https://falcosecurity.github.io/rules/) [![Style Guide](https://img.shields.io/badge/docs-latest-green.svg?label=Style%20Guide&style=for-the-badge)](https://falco.org/docs/rules/style-guide/) [![Supported Fields](https://img.shields.io/badge/docs-latest-green.svg?label=Supported%20Fields&style=for-the-badge)](https://falco.org/docs/reference/rules/supported-fields/) [![Supported EVT ARG Fields](https://img.shields.io/badge/docs-latest-green.svg?label=Supported%20Evt%20Arg%20Fields&style=for-the-badge)](https://github.com/falcosecurity/libs/blob/master/driver/event_table.c) @@ -50,7 +50,7 @@ Rules tell [Falco](https://github.com/falcosecurity/falco) what to do. These rul ## Falco Rules Files Registry -The Falco Rules Files Registry contains metadata and information about rules files distributed by The Falco Project. The registry serves as an additional method of making the rules files available to the community, complementing the process of retrieving the rules files from this repository. +The Falco Rules Files Registry contains metadata and information about rules files distributed by The Falco Project. The registry serves as an additional method of making the rules files available to the community, complementing the process of retrieving the rules files from this repository. Note: _Currently, the registry includes only rules for the syscall call data source; for other data sources see the [Plugins](https://github.com/falcosecurity/plugins) repository._ diff --git a/RELEASE.md b/RELEASE.md index d4170d31..af87f595 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -40,7 +40,7 @@ Patches on an already-released ruleset can anytime on a per-need basis. Assuming ## Versioning a ruleset -The version of the official Falco rulesets is compatible with [SemVer](https://semver.org/) and must be meaningful towards the changes in its structure and contents. To define a new version `x.y.z` for a given ruleset, consider the following guidelines. +The version of the official Falco rulesets is compatible with [SemVer](https://semver.org/) and must be meaningful towards the changes in its structure and contents. To define a new version `x.y.z` for a given ruleset, consider the following guidelines. Our automation will detect most of the following criteria and suggest a summary with all the changes relative to each of the three versioning categories (patch, minor, major). This provides a changelog and valuable suggestion on the next version to be assigned to each ruleset. However, be mindful that the versioning process cannot totally automated and always requires human attention (e.g. we can't automatically detect subtle semantic changes in rules). The automated jobs will use the versions of Falco defined in `./github/FALCO_VERSIONS` for validating and checking rulesets. The versions must be line-separated and ordered from the most recent to the least recent. Any [published container image tag](https://hub.docker.com/r/falcosecurity/falco/tags) is a valid Falco version entry, including `master`, `latest`, and any other stable release tag (e.g. `0.35.0`). `master` indicates the most recent dev version of Falco built from mainline, and can be used for using a not-yet-published version of Falco in case we want to run the CI with a new in-development feature. diff --git a/archive/falco-deprecated_rules.yaml b/archive/falco-deprecated_rules.yaml index 12eafc39..3d83c95c 100644 --- a/archive/falco-deprecated_rules.yaml +++ b/archive/falco-deprecated_rules.yaml @@ -81,14 +81,14 @@ condition: (never_true) - rule: Disallowed SSH Connection - desc: > - Detect any new SSH connection on port 22 to a host other than those in an allowed list of hosts. - This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely - crucial in any security program, as they can often provide the only definitive evidence. However, + desc: > + Detect any new SSH connection on port 22 to a host other than those in an allowed list of hosts. + This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely + crucial in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing them can be challenging due to the potential for noise. - condition: > - inbound_outbound - and ssh_port + condition: > + inbound_outbound + and ssh_port and not allowed_ssh_hosts enabled: false output: Disallowed SSH Connection | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -114,13 +114,13 @@ items: [google.com, www.yahoo.com] - rule: Unexpected outbound connection destination - desc: > - Detect any outbound connection to a destination outside of an allowed set of ips, networks, or domain names. - This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely crucial - in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing + desc: > + Detect any outbound connection to a destination outside of an allowed set of ips, networks, or domain names. + This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely crucial + in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing them can be challenging due to the potential for noise. condition: > - outbound + outbound and not ((fd.sip in (allowed_outbound_destination_ipaddrs)) or (fd.snet in (allowed_outbound_destination_networks)) or (fd.sip.name in (allowed_outbound_destination_domains))) @@ -128,7 +128,7 @@ output: Disallowed outbound connection destination | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: NOTICE tags: [maturity_deprecated, host, container, network, mitre_command_and_control, TA0011] - + # Use this to test whether the event occurred within a container. - macro: container condition: (container.id != host) @@ -138,7 +138,7 @@ - list: authorized_server_binary items: [] # add binary to allow, i.e.: nginx - + - list: authorized_server_port items: [] # add port to allow, i.e.: 80 @@ -154,18 +154,18 @@ # # Change rule to different port, then different process name, and test again that it fires. - rule: Outbound or Inbound Traffic not to Authorized Server Process and Port - desc: > - Detect traffic to an unauthorized server process and port within pre-defined containers. - This rule absolutely requires profiling your environment beforehand and also necessitates adjusting the list of containers - to which this rule will be applied. The current expression logic will never evaluate to true unless the list is populated. - Network-based rules are extremely crucial in any security program, as they can often provide the only definitive evidence. - However, effectively operationalizing them can be challenging due to the potential for noise. Notably, this rule is challenging + desc: > + Detect traffic to an unauthorized server process and port within pre-defined containers. + This rule absolutely requires profiling your environment beforehand and also necessitates adjusting the list of containers + to which this rule will be applied. The current expression logic will never evaluate to true unless the list is populated. + Network-based rules are extremely crucial in any security program, as they can often provide the only definitive evidence. + However, effectively operationalizing them can be challenging due to the potential for noise. Notably, this rule is challenging to operationalize. condition: > - inbound_outbound - and container - and container.image.repository in (allowed_image) - and not proc.name in (authorized_server_binary) + inbound_outbound + and container + and container.image.repository in (allowed_image) + and not proc.name in (authorized_server_binary) and not fd.sport in (authorized_server_port) enabled: false output: Network connection outside authorized port and binary | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -179,14 +179,14 @@ items: [] - rule: Outbound Connection to C2 Servers - desc: > + desc: > Detect outbound connections to command and control servers using a list of IP addresses and fully qualified domain names (FQDNs). - This rule absolutely requires profiling your environment beforehand and also necessitates adjusting the template lists. The current - expression logic will never evaluate to true unless the lists are populated. Network-based rules are extremely crucial in any - security program, as they can often provide the only definitive evidence. However, effectively operationalizing them can be challenging + This rule absolutely requires profiling your environment beforehand and also necessitates adjusting the template lists. The current + expression logic will never evaluate to true unless the lists are populated. Network-based rules are extremely crucial in any + security program, as they can often provide the only definitive evidence. However, effectively operationalizing them can be challenging due to the potential for noise. Notably, this rule is challenging to operationalize. condition: > - outbound + outbound and ((fd.sip in (c2_server_ip_list)) or (fd.sip.name in (c2_server_fqdn_list))) output: Outbound connection to C2 server | c2_domain=%fd.sip.name c2_addr=%fd.sip connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty diff --git a/build/checker/.gitignore b/build/checker/.gitignore index 41646b19..fbbdd5f1 100644 --- a/build/checker/.gitignore +++ b/build/checker/.gitignore @@ -1 +1 @@ -checker \ No newline at end of file +checker diff --git a/build/mitre_attack_checker/README.md b/build/mitre_attack_checker/README.md index 4480339b..cc8b2c94 100644 --- a/build/mitre_attack_checker/README.md +++ b/build/mitre_attack_checker/README.md @@ -83,30 +83,30 @@ poetry run python -m pytest --cov=falco_mitre_attack_checker ``` ``` ----------- coverage: platform linux, python 3.10.12-final-0 ---------- -Name Stmts Miss Cover ----------------------------------------------------------------------------- -falco_mitre_checker/__init__.py 0 0 100% -falco_mitre_checker/__main__.py 7 7 0% -falco_mitre_checker/api/__init__.py 0 0 100% -falco_mitre_checker/api/core.py 19 19 0% -falco_mitre_checker/cli/__init__.py 0 0 100% -falco_mitre_checker/cli/core.py 18 18 0% -falco_mitre_checker/engine/__init__.py 0 0 100% -falco_mitre_checker/engine/mitre_checker.py 46 1 98% -falco_mitre_checker/exceptions/__init__.py 0 0 100% -falco_mitre_checker/exceptions/rules_exceptions.py 8 0 100% -falco_mitre_checker/models/__init__.py 0 0 100% -falco_mitre_checker/models/falco_mitre_errors.py 16 0 100% +---------- coverage: platform linux, python 3.10.12-final-0 ---------- +Name Stmts Miss Cover +---------------------------------------------------------------------------- +falco_mitre_checker/__init__.py 0 0 100% +falco_mitre_checker/__main__.py 7 7 0% +falco_mitre_checker/api/__init__.py 0 0 100% +falco_mitre_checker/api/core.py 19 19 0% +falco_mitre_checker/cli/__init__.py 0 0 100% +falco_mitre_checker/cli/core.py 18 18 0% +falco_mitre_checker/engine/__init__.py 0 0 100% +falco_mitre_checker/engine/mitre_checker.py 46 1 98% +falco_mitre_checker/exceptions/__init__.py 0 0 100% +falco_mitre_checker/exceptions/rules_exceptions.py 8 0 100% +falco_mitre_checker/models/__init__.py 0 0 100% +falco_mitre_checker/models/falco_mitre_errors.py 16 0 100% falco_mitre_checker/models/falco_mitre_relations.py 14 2 86% falco_mitre_checker/parsers/__init__.py 0 0 100% -falco_mitre_checker/parsers/falco_rules.py 30 1 97% -falco_mitre_checker/parsers/mitre_stix.py 31 4 87% -falco_mitre_checker/tests/__init__.py 0 0 100% -falco_mitre_checker/tests/engine/__init__.py 0 0 100% -falco_mitre_checker/tests/engine/test_mitre_checker.py 41 0 100% -falco_mitre_checker/tests/parsers/__init__.py 0 0 100% -falco_mitre_checker/tests/parsers/test_falco_rules.py 18 0 100% +falco_mitre_checker/parsers/falco_rules.py 30 1 97% +falco_mitre_checker/parsers/mitre_stix.py 31 4 87% +falco_mitre_checker/tests/__init__.py 0 0 100% +falco_mitre_checker/tests/engine/__init__.py 0 0 100% +falco_mitre_checker/tests/engine/test_mitre_checker.py 41 0 100% +falco_mitre_checker/tests/parsers/__init__.py 0 0 100% +falco_mitre_checker/tests/parsers/test_falco_rules.py 18 0 100% falco_mitre_checker/tests/parsers/test_mitre_stix.py 34 0 100% falco_mitre_checker/tests/test_common.py 13 2 85% falco_mitre_checker/utils/__init__.py 0 0 100% @@ -133,9 +133,7 @@ poetry run python -m safety check 0 vulnerabilities ignored +=======================================================================================================+ - No known security vulnerabilities found. + No known security vulnerabilities found. +=======================================================================================================+ ``` - - diff --git a/build/mitre_attack_checker/falco_mitre_attack_checker/tests/resources/not_falco_rules_test.yaml b/build/mitre_attack_checker/falco_mitre_attack_checker/tests/resources/not_falco_rules_test.yaml index d764d127..1ac90494 100644 --- a/build/mitre_attack_checker/falco_mitre_attack_checker/tests/resources/not_falco_rules_test.yaml +++ b/build/mitre_attack_checker/falco_mitre_attack_checker/tests/resources/not_falco_rules_test.yaml @@ -1,2 +1,2 @@ test: True -falco-rules: false \ No newline at end of file +falco-rules: false diff --git a/build/registry/testdata/rules-failed-req.yaml b/build/registry/testdata/rules-failed-req.yaml index ec939c4b..fbad1d7b 100644 --- a/build/registry/testdata/rules-failed-req.yaml +++ b/build/registry/testdata/rules-failed-req.yaml @@ -1 +1 @@ -- required_engine_version: test \ No newline at end of file +- required_engine_version: test diff --git a/build/registry/testdata/rules-numeric-req.yaml b/build/registry/testdata/rules-numeric-req.yaml index 60b94c3b..cc5f63c3 100644 --- a/build/registry/testdata/rules-numeric-req.yaml +++ b/build/registry/testdata/rules-numeric-req.yaml @@ -1 +1 @@ -- required_engine_version: 15 \ No newline at end of file +- required_engine_version: 15 diff --git a/build/registry/testdata/rules-semver-req.yaml b/build/registry/testdata/rules-semver-req.yaml index 56727d23..7f079dae 100644 --- a/build/registry/testdata/rules-semver-req.yaml +++ b/build/registry/testdata/rules-semver-req.yaml @@ -1 +1 @@ -- required_engine_version: 0.31.0 \ No newline at end of file +- required_engine_version: 0.31.0 diff --git a/proposals/20230605-rules-adoption-management-maturity-framework.md b/proposals/20230605-rules-adoption-management-maturity-framework.md index e906123b..b67b629e 100644 --- a/proposals/20230605-rules-adoption-management-maturity-framework.md +++ b/proposals/20230605-rules-adoption-management-maturity-framework.md @@ -4,7 +4,7 @@ The objective is to outline key enhancements and improvements to Falco, focusing on optimizing its rule adoption, customization, and management capabilities. The proposal also introduces a rules maturity framework to provide a structured approach for assessing and categorizing rules. -In more detail, this proposal aims to address the expectations of adopters by providing clear guidelines for rule contribution, including processes and criteria. It also aims to provide guidance on rule customization and tuning to help adopters optimize the detection capabilities of Falco for their specific environments. Lastly, the proposal aims to empower adopters by providing them with the necessary knowledge and resources to effectively manage and customize rules. +In more detail, this proposal aims to address the expectations of adopters by providing clear guidelines for rule contribution, including processes and criteria. It also aims to provide guidance on rule customization and tuning to help adopters optimize the detection capabilities of Falco for their specific environments. Lastly, the proposal aims to empower adopters by providing them with the necessary knowledge and resources to effectively manage and customize rules. The proposed timeline for the initial completion of each item is the Falco 0.36 release, with further improvements being continuously added based on feedback. @@ -50,16 +50,16 @@ Not every rule has the potential to evolve and reach the "stable" level. This is Levels (new Falco tags): - **maturity_stable** (enabled by default) indicates that the rule has undergone thorough evaluation by experts with hands-on production experience. These experts have determined that the rules embody best practices and exhibit optimal robustness, making it more difficult for attackers to bypass Falco. These rules are highly relevant for addressing broader threats and are recommended for customization to specific environments if necessary. They primarily focus on universal system-level detections, such as generic reverse shells or container escapes, which establish a solid baseline for threat detection across diverse industries. This inherent bias against including more application-specific detections is due to their potential lack of broad relevance or applicability. However, to mitigate this bias, a grey area will be reserved, enabling case-by-case judgments to be made. -- **maturity_incubating** (disabled by default) indicates that the rules address relevant threats, provide a certain level of robustness guarantee, and adhere to best practices in rule writing. Furthermore, it signifies that the rules have been identified by experts as catering to more specific use cases, which may or may not be relevant for each adopter. This category is expected to include a larger number of application-specific rules. +- **maturity_incubating** (disabled by default) indicates that the rules address relevant threats, provide a certain level of robustness guarantee, and adhere to best practices in rule writing. Furthermore, it signifies that the rules have been identified by experts as catering to more specific use cases, which may or may not be relevant for each adopter. This category is expected to include a larger number of application-specific rules. - **maturity_sandbox** (disabled by default) indicates that the rule is in an experimental stage. The potential for broader usefulness and relevance of "sandbox" rules is currently being assessed. These rules can serve as inspiration and adhere to the minimum acceptance criteria for rules. - **maturity_deprecated** (disabled by default), indicates that, upon re-assessment, the rule was deemed less applicable to the broader community. Each adopter needs to determine the relevance of these rules on their own. They are kept as examples but are no longer actively supported or tuned by The Falco Project. > Falco introduces new additional tags, that is: -> -> `maturity_stable` -> `maturity_incubating` -> `maturity_sandbox` -> `maturity_deprecated` +> +> `maturity_stable` +> `maturity_incubating` +> `maturity_sandbox` +> `maturity_deprecated` > > for each rule. This tag reflects the robustness, relevance, applicability, and stability of each predefined rule in the [falcosecurity/rules](https://github.com/falcosecurity/rules/blob/main/rules/) repository. It serves as general guidance to determine which rules may provide the highest return on investment. As a minimum requirement, each rule must go through the `maturity_incubating` state before advancing to `maturity_stable`. Only `maturity_stable` rules will be enabled by default. We use the existing tags mechanisms to build upon a battle-proven solution and will provide transparent configurability through the `falco.yaml` file to support the unique use cases of adopters. > @@ -67,7 +67,7 @@ Levels (new Falco tags): The maturity level of the rules, however, does not directly reflect their potential for generating noise in the adopters' environment. This is due to the unique and constantly changing nature of each environment, especially in cloud environments, making it challenging to accurately predict the impact of rules. -Newcomers to Falco will be encouraged to start by configuring their setup with introductory rules labeled as "Falco's default rules" (`maturity_stable`). These rules, which are currently based on syscall and container events, will live in the established [falco_rules.yaml](https://github.com/falcosecurity/rules/blob/main/rules/falco_rules.yaml) file. +Newcomers to Falco will be encouraged to start by configuring their setup with introductory rules labeled as "Falco's default rules" (`maturity_stable`). These rules, which are currently based on syscall and container events, will live in the established [falco_rules.yaml](https://github.com/falcosecurity/rules/blob/main/rules/falco_rules.yaml) file. As users become more familiar with Falco and better understand their unique environments, they can gradually fine-tune the default rules to meet their specific requirements. Tuning rules goes hand in hand with assessing the performance overhead and adjusting Falco's [configuration](https://github.com/falcosecurity/falco/blob/master/falco.yaml) accordingly. This consideration is crucial to convey to adopters, as it is important to keep in mind that there are usually limitations to the budget allocated for security monitoring. @@ -120,7 +120,7 @@ How was the rule tested? The desired testing approach includes not only function ### Guidance on Rule Customization and Tuning -Each rule tagged as "Stable" will provide clear guidance on how it can be tuned, customized, or combined with other rules if applicable. Over time, a catalog of general best tuning practices will be developed. For specific examples, please refer to Appendix 2. +Each rule tagged as "Stable" will provide clear guidance on how it can be tuned, customized, or combined with other rules if applicable. Over time, a catalog of general best tuning practices will be developed. For specific examples, please refer to Appendix 2. ### Setting Expectations for Adopters @@ -133,7 +133,7 @@ In addition, effectively utilizing Falco requires expertise in various domains, ## Key Results for Falco 0.36 -In summary, the following action items are planned to be completed leading up to the Falco 0.36 release: +In summary, the following action items are planned to be completed leading up to the Falco 0.36 release: - Clearly communicate Falco's primary uses: threat detection and compliance. - Establish specific criteria for each rules maturity level and define general criteria for creating, contributing, and updating rules based on their respective maturity levels. @@ -157,27 +157,27 @@ Here are some examples of more robust rules with a brief description of why they
Detect release_agent File Container Escapes -

+

Detecting attempts to escape a container is a crucial detection for modern container orchestration systems like Kubernetes. This rule stands out due to its inclusion of preconditions, which verify the necessary privileges of the container. Without these preconditions, the specific TTPs associated with container escape are not feasible. -

+

The rule is based on the open syscall while monitoring file writing activities, specifically looking for a string match on the file name "release_agent". This approach is robust because Linux expects the cgroup's release_agent file to be named in this manner. -

+

One downside of the rule is that it addresses only one specific TTP. Enabling additional rules like "Change thread namespace" can enhance coverage for other container escape methods. -

-
+

+
Drop and execute new binary in container -

+

The Falco 0.34 release note provides a concise summary of how high-value kernel signals can greatly simplify the task of detecting suspicious executions that occur when a malicious implant is dropped and executed. Instead of relying on complex checks for executable paths, the focus shifts to identifying executables that were not part of the container image and were executed from the container's upper overlayfs layer shortly after being dropped. -

+

This approach narrows detection scope, increases tractability, and eliminates the need for inspecting unfamiliar or unusual executable paths. By leveraging high-value kernel signals, detections become more precise, removing ambiguity and providing crucial context. -

-
+

+
@@ -192,17 +192,17 @@ Here are some general tricks for tuning on-host rules:
Profiling -

+

Profiling the environment can be effective in detecting abnormal behaviors that may be considered normal in system-critical applications but outliers in standard applications. Implementing a simple allow list, such as for container names or namespaces, can already provide valuable assistance. This approach also aligns with the practice of clearly defining the crown jewel applications for which robust detections are desired. -

-
+

+
Linux concepts / behavioral indicators -

+

Another aspect of tuning a detection involves considering behavioral aspects related to Linux concepts. For example, a detection can be tuned based on the presence of a shell or a Java process in the parent process lineage, or detecting file manipulations while maintaining manual interactive shell access to a container. By incorporating these behavioral indicators, the detection can become more specific, relevant, and effective in identifying potential security threats. -

-
+

+
@@ -213,32 +213,32 @@ Examples of existing gaps in Falco for threat detection, as of June 6, 2023, inc
Deep kernel-level monitoring -

+

Falco operates at the kernel level but does not provide deep visibility into all aspects of kernel internals. It focuses on monitoring system calls and other observable events but may not capture low-level kernel activities. -

-
+

+
Network packet inspection -

+

Falco's primary focus is on monitoring system calls, and while it can detect network-related system calls, it may not offer extensive network packet inspection capabilities. Additionally, when considering modern cloud architectures with load balancers in front of application backend servers, there are inherent limitations in L3/4 network monitoring. Lastly, keeping in mind that Falco runs on each host in isolation, it means that certain correlations and detailed network introspection are still being extended and improved upon. -

-
+

+
Full-stack application monitoring -

+

Essentially, Falco is designed to monitor the Linux kernel and system-level activities. While it can capture certain application-related events, it may not provide comprehensive monitoring and visibility into the full application stack. However, there are exceptions where Falco has expanded its monitoring coverage to additional data sources using the plugins framework. One notable example is the integration with Kubernetes audit logs, which provides monitoring at the control plane level within a Kubernetes infrastructure. In addition, Falco's underlying libraries possess the capability to capture abnormal behavior at higher levels of the stack, such as analyzing HTTP requests. However, this potential is currently not exposed in Falco. -

-
+

+
Advanced behavior analysis / anomaly detection -

+

Falco excels at detecting known patterns and rules-based anomalies. However, it currently may have limitations when it comes to advanced behavior analysis, on host anomaly detection, or identifying zero-day exploits that do not exhibit known patterns. -

-
+

+
diff --git a/rules/falco-incubating_rules.yaml b/rules/falco-incubating_rules.yaml index 025e47a1..4157a782 100644 --- a/rules/falco-incubating_rules.yaml +++ b/rules/falco-incubating_rules.yaml @@ -256,13 +256,13 @@ condition: (never_true) - rule: Modify Shell Configuration File - desc: > - Detect attempts to modify shell configuration files, primarily aimed at establishing persistence by automatically inserting + desc: > + Detect attempts to modify shell configuration files, primarily aimed at establishing persistence by automatically inserting commands into scripts executed by shells. The upstream rule excludes shell processes because they often create unnecessary noise. - However, this might lead to missed detections. To customize the rule for your situation, you can fine-tune it using enhanced profiling. + However, this might lead to missed detections. To customize the rule for your situation, you can fine-tune it using enhanced profiling. For example, you might want to only consider interactive shell processes (where proc.tty != 0). condition: > - open_write + open_write and (fd.filename in (shell_config_filenames) or fd.name in (shell_config_files) or fd.directory in (shell_config_directories)) @@ -279,11 +279,11 @@ - rule: Schedule Cron Jobs desc: > - Detect scheduled cron jobs; this is a highly generic detection and certainly needs adjustments and profiling in your environment before + Detect scheduled cron jobs; this is a highly generic detection and certainly needs adjustments and profiling in your environment before operationalization. Simultaneously, exploiting the functionality of cron jobs is among one of the oldest TTPs used by adversaries. condition: > ((open_write and fd.name startswith /etc/cron) or - (spawned_process and proc.name = "crontab")) + (spawned_process and proc.name = "crontab")) and not user_known_cron_jobs output: Cron jobs were scheduled to run | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: @@ -360,17 +360,17 @@ condition: (never_true) - rule: Read ssh information - desc: > - This rule identifies attempts to read files within ssh directories using programs that are not related to ssh. It's a simple and - versatile detection method that works well alongside more specific rules focused on sensitive file access. You have a couple of - options for using this rule effectively: you can adjust the specialized rules to cover all the important scenarios and ensure - precedence in rule smatching for those, or you can analyze the combined view of ssh-related file access across various rules on - your downstream computing platform. Just like with other rules, you can narrow down monitoring to specific processes, or you can + desc: > + This rule identifies attempts to read files within ssh directories using programs that are not related to ssh. It's a simple and + versatile detection method that works well alongside more specific rules focused on sensitive file access. You have a couple of + options for using this rule effectively: you can adjust the specialized rules to cover all the important scenarios and ensure + precedence in rule smatching for those, or you can analyze the combined view of ssh-related file access across various rules on + your downstream computing platform. Just like with other rules, you can narrow down monitoring to specific processes, or you can limit it to interactive access only. condition: > - (open_read or open_directory) + (open_read or open_directory) and (user_ssh_directory or fd.name startswith /root/.ssh) - and not user_known_read_ssh_information_activities + and not user_known_read_ssh_information_activities and not proc.name in (ssh_binaries) output: ssh-related file/directory read by non-ssh program | file=%fd.name pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: ERROR @@ -387,8 +387,8 @@ - rule: DB program spawned process desc: > - A program related to the database server creates an unexpected child process (other than itself). - This is not supposed to happen and often follows SQL injection attacks. This behavioral detection could + A program related to the database server creates an unexpected child process (other than itself). + This is not supposed to happen and often follows SQL injection attacks. This behavioral detection could indicate potential unauthorized data extraction or tampering with the database. condition: > spawned_process @@ -417,9 +417,9 @@ - rule: Change thread namespace desc: > - An attempt to alter the namespace of a process (often performed while creating a container) through the setns syscall. - Conversely, the same syscall setns is triggered when an unauthorized attempt is made to break out from the container - to the host, for example, when using commands like `nsenter --target 1` and similar ones. Recommending to profile your + An attempt to alter the namespace of a process (often performed while creating a container) through the setns syscall. + Conversely, the same syscall setns is triggered when an unauthorized attempt is made to break out from the container + to the host, for example, when using commands like `nsenter --target 1` and similar ones. Recommending to profile your environment and refine this rule for effective operationalization. condition: > evt.type=setns @@ -442,14 +442,14 @@ tags: [maturity_incubating, host, container, process, mitre_privilege_escalation, T1611] - rule: Change namespace privileges via unshare - desc: > - Unprivileged users in containers may not have CAP_SYS_ADMIN or other elevated privileges. However, they can - use the unshare system call with CLONE_NEWNS or CLONE_NEWUSER to create or clone a namespace or user with the - necessary privileges to conduct further attacks. It is best practice to block the unshare system call via + desc: > + Unprivileged users in containers may not have CAP_SYS_ADMIN or other elevated privileges. However, they can + use the unshare system call with CLONE_NEWNS or CLONE_NEWUSER to create or clone a namespace or user with the + necessary privileges to conduct further attacks. It is best practice to block the unshare system call via seccomp if it is not needed. Misuse of unshare can be related to misconfigured Kubernetes clusters, for example. condition: > - evt.type=unshare - and container + evt.type=unshare + and container and not thread.cap_permitted contains CAP_SYS_ADMIN output: Change namespace privileges via unshare | res=%evt.res evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: NOTICE @@ -601,13 +601,13 @@ condition: (never_true) - rule: Launch Privileged Container - desc: > - Detect the initial process initiation within a privileged container, with exemptions for known and trusted images. - This rule primarily serves as an excellent auditing mechanism since highly privileged containers, when compromised, - can result in significant harm. For instance, if another rule triggers within such a privileged container, it could be + desc: > + Detect the initial process initiation within a privileged container, with exemptions for known and trusted images. + This rule primarily serves as an excellent auditing mechanism since highly privileged containers, when compromised, + can result in significant harm. For instance, if another rule triggers within such a privileged container, it could be seen as more suspicious, prompting a closer inspection. condition: > - container_started + container_started and container.privileged=true and not falco_privileged_containers and not user_privileged_containers @@ -630,13 +630,13 @@ or thread.cap_permitted contains CAP_BPF) - rule: Launch Excessively Capable Container - desc: > - Identify containers that start with a powerful set of capabilities, with exceptions for recognized trusted images. - Similar to the "Launch Privileged Container" rule, this functions as a robust auditing rule. Compromised highly privileged - containers can lead to substantial harm. For instance, if another rule is triggered within such a container, it might + desc: > + Identify containers that start with a powerful set of capabilities, with exceptions for recognized trusted images. + Similar to the "Launch Privileged Container" rule, this functions as a robust auditing rule. Compromised highly privileged + containers can lead to substantial harm. For instance, if another rule is triggered within such a container, it might raise suspicion, prompting closer scrutiny. condition: > - container_started + container_started and excessively_capable_container and not falco_privileged_containers and not user_privileged_containers @@ -651,12 +651,12 @@ # systemd can listen on ports to launch things like sshd on demand - rule: System procs network activity desc: > - Detect any unexpected network activity performed by system binaries that typically shouldn't perform network activity, including - coreutils binaries (like sleep, mkdir, who, date, and others) or user management binaries (such as login, systemd, usermod, deluser, + Detect any unexpected network activity performed by system binaries that typically shouldn't perform network activity, including + coreutils binaries (like sleep, mkdir, who, date, and others) or user management binaries (such as login, systemd, usermod, deluser, adduser, chpasswd, and others). This serves as a valuable baseline detection for network-related activities. condition: > inbound_outbound - and fd.sockfamily = ip + and fd.sockfamily = ip and (system_procs or proc.name in (shell_binaries)) and not proc.name in (known_system_procs_network_activity_binaries) and not login_doing_dns_lookup @@ -692,14 +692,14 @@ - rule: Program run with disallowed http proxy env desc: > - Detect curl or wget usage with HTTP_PROXY environment variable. Attackers can manipulate the HTTP_PROXY variable's - value to redirect application's internal HTTP requests. This could expose sensitive information like authentication + Detect curl or wget usage with HTTP_PROXY environment variable. Attackers can manipulate the HTTP_PROXY variable's + value to redirect application's internal HTTP requests. This could expose sensitive information like authentication keys and private data. condition: > - spawned_process - and http_proxy_procs + spawned_process + and http_proxy_procs and proc.env icontains HTTP_PROXY - and not allowed_ssh_proxy_env + and not allowed_ssh_proxy_env output: Curl or wget run with disallowed HTTP_PROXY environment variable | env=%proc.env evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: NOTICE tags: [maturity_incubating, host, container, users, mitre_execution, T1204] @@ -733,12 +733,12 @@ condition: fd.port in (expected_udp_ports) - rule: Unexpected UDP Traffic - desc: > - Detecting UDP traffic on ports other than 53 (DNS) or other commonly used ports. Misusing UDP is a known TTP among attackers. + desc: > + Detecting UDP traffic on ports other than 53 (DNS) or other commonly used ports. Misusing UDP is a known TTP among attackers. Monitoring unusual network activity is highly valuable but often generates significant noise, as is the case with this detection. - condition: > - inbound_outbound - and fd.l4proto=udp + condition: > + inbound_outbound + and fd.l4proto=udp and not expected_udp_traffic output: Unexpected UDP Traffic Seen | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: NOTICE @@ -776,10 +776,10 @@ # sshd, mail programs attempt to setuid to root even when running as non-root. Excluding here to avoid meaningless FPs - rule: Non sudo setuid desc: > - Detect attempts to change users through the use of setuid, with exceptions for sudo/su. - The users "root" and "nobody" using setuid on themselves are also excluded, as setuid calls in these cases - typically involve reducing privileges. By setting the setuid bit, an attacker could execute code in a - different user's context, potentially with higher privileges. One drawback is the potential for noise, + Detect attempts to change users through the use of setuid, with exceptions for sudo/su. + The users "root" and "nobody" using setuid on themselves are also excluded, as setuid calls in these cases + typically involve reducing privileges. By setting the setuid bit, an attacker could execute code in a + different user's context, potentially with higher privileges. One drawback is the potential for noise, as many applications legitimately use this approach. condition: > evt.type=setuid @@ -804,25 +804,25 @@ - rule: User mgmt binaries desc: > - Detect activity by any programs that can manage users, passwords, or permissions (such as login, systemd, usermod, deluser, adduser, - chpasswd, and others). sudo and su are excluded. Activity in containers is also excluded -- some containers create custom users on - top of a base linux distribution at startup. Some innocuous command lines that don't actually change anything are excluded. You might + Detect activity by any programs that can manage users, passwords, or permissions (such as login, systemd, usermod, deluser, adduser, + chpasswd, and others). sudo and su are excluded. Activity in containers is also excluded -- some containers create custom users on + top of a base linux distribution at startup. Some innocuous command lines that don't actually change anything are excluded. You might want to consider applying this rule to container actions as well. condition: > - spawned_process + spawned_process and not container - and proc.name in (user_mgmt_binaries) - and not proc.name in (su, sudo, lastlog, nologin, unix_chkpwd) + and proc.name in (user_mgmt_binaries) + and not proc.name in (su, sudo, lastlog, nologin, unix_chkpwd) and not proc.pname in (cron_binaries, systemd, systemd.postins, udev.postinst, run-parts) - and not proc.cmdline startswith "passwd -S" - and not proc.cmdline startswith "useradd -D" - and not proc.cmdline startswith "systemd --version" - and not run_by_qualys - and not run_by_sumologic_securefiles - and not run_by_yum - and not run_by_ms_oms - and not run_by_google_accounts_daemon - and not chage_list + and not proc.cmdline startswith "passwd -S" + and not proc.cmdline startswith "useradd -D" + and not proc.cmdline startswith "systemd --version" + and not run_by_qualys + and not run_by_sumologic_securefiles + and not run_by_yum + and not run_by_ms_oms + and not run_by_google_accounts_daemon + and not chage_list and not user_known_user_management_activities output: User management binary command run outside of container | gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: NOTICE @@ -840,9 +840,9 @@ # (we may need to add additional checks against false positives, see: # https://bugs.launchpad.net/ubuntu/+source/rkhunter/+bug/86153) - rule: Create files below dev - desc: > - Detect the creation of files under /dev except for authorized device management programs. This can reveal rootkits hiding - files in /dev. Additionally, consider the "Execution from /dev/shm" rule. The upstream rule already covers some tuning + desc: > + Detect the creation of files under /dev except for authorized device management programs. This can reveal rootkits hiding + files in /dev. Additionally, consider the "Execution from /dev/shm" rule. The upstream rule already covers some tuning scenarios that you can further expand upon. condition: > (evt.type = creat or (evt.type in (open,openat,openat2))) @@ -871,13 +871,13 @@ # metadata about the instance. It may be desirable to prevent access # to this IP from containers. - rule: Contact EC2 Instance Metadata Service From Container - desc: > - Detects attempts to communicate with the EC2 Instance Metadata Service from a container. This detection is narrowly focused + desc: > + Detects attempts to communicate with the EC2 Instance Metadata Service from a container. This detection is narrowly focused and might not apply to your environment. In addition, it could generate noise and require fine-tuning. - condition: > - outbound + condition: > + outbound and container - and fd.sip="169.254.169.254" + and fd.sip="169.254.169.254" and not ec2_metadata_containers output: Outbound connection to EC2 instance metadata service | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: NOTICE @@ -891,13 +891,13 @@ # On GCP, AWS and Azure, 169.254.169.254 is a special IP used to fetch # metadata about the instance. The metadata could be used to get credentials by attackers. - rule: Contact cloud metadata service from container - desc: > - Detects attempts to communicate with the Cloud Instance Metadata Service from a container. This detection is narrowly focused + desc: > + Detects attempts to communicate with the Cloud Instance Metadata Service from a container. This detection is narrowly focused and might not apply to your environment. In addition, it could generate noise and require fine-tuning. - condition: > - outbound - and container - and fd.sip="169.254.169.254" + condition: > + outbound + and container + and fd.sip="169.254.169.254" and not user_known_metadata_access enabled: true output: Outbound connection to cloud instance metadata service | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -926,10 +926,10 @@ and container.image.repository = "registry.k8s.io/kube-proxy") - rule: Launch Package Management Process in Container - desc: > - Detect package management processes executed within containers. An excellent auditing rule to monitor general drifts - in containers. Particularly useful for newer rules like "Drop and execute new binary in container" during incident - response investigations. This helps identify common anti-patterns of ad-hoc debugging. Simultaneously, to maintain + desc: > + Detect package management processes executed within containers. An excellent auditing rule to monitor general drifts + in containers. Particularly useful for newer rules like "Drop and execute new binary in container" during incident + response investigations. This helps identify common anti-patterns of ad-hoc debugging. Simultaneously, to maintain optimal hygiene, it's recommended to prevent container drifts and instead opt for redeploying new containers. condition: > spawned_process @@ -948,13 +948,13 @@ - rule: Launch Suspicious Network Tool in Container desc: > - Detect network tools (like netcat, nmap, tcpdump, socat, and more) launched within containers without any additional filters. - This serves as a valuable general detection, but it's recommended to invest engineering effort to fine-tune it and prevent a + Detect network tools (like netcat, nmap, tcpdump, socat, and more) launched within containers without any additional filters. + This serves as a valuable general detection, but it's recommended to invest engineering effort to fine-tune it and prevent a high volume of legitimate logs. This rule complements the more specific "Netcat Remote Code Execution in Container" rule. condition: > - spawned_process - and container - and network_tool_procs + spawned_process + and container + and network_tool_procs and not user_known_network_tool_activities output: Network tool launched in container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: NOTICE @@ -962,13 +962,13 @@ - rule: Launch Suspicious Network Tool on Host desc: > - Detect network tools (like netcat, nmap, tcpdump, socat, and more) launched within containers without any additional filters. - This serves as a valuable general detection, but it's recommended to invest engineering effort to fine-tune it and prevent a + Detect network tools (like netcat, nmap, tcpdump, socat, and more) launched within containers without any additional filters. + This serves as a valuable general detection, but it's recommended to invest engineering effort to fine-tune it and prevent a high volume of legitimate logs. The host equivalent of "Launch Suspicious Network Tool in Container.". condition: > - spawned_process - and not container - and network_tool_procs + spawned_process + and not container + and network_tool_procs and not user_known_network_tool_activities output: Network tool launched on host | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: NOTICE @@ -1008,13 +1008,13 @@ # the filtercheck and others will always return . It would be better to use # a more generic filter like `fs.path.*` - rule: Delete or rename shell history - desc: > - Detect shell history deletion, frequently used by unsophisticated adversaries to eliminate evidence. - Note that it can also trigger when exiting a Terminal shell, such as with `kubectl exec`, which + desc: > + Detect shell history deletion, frequently used by unsophisticated adversaries to eliminate evidence. + Note that it can also trigger when exiting a Terminal shell, such as with `kubectl exec`, which may introduce some noise. condition: > - (modify_shell_history or truncate_shell_history) - and not var_lib_docker_filepath + (modify_shell_history or truncate_shell_history) + and not var_lib_docker_filepath and not proc.name in (docker_binaries) output: Shell history deleted or renamed | file=%fd.name name=%evt.arg.name path=%evt.arg.path oldpath=%evt.arg.oldpath evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: @@ -1037,12 +1037,12 @@ # we will always return ``. - rule: Set Setuid or Setgid bit desc: > - This rule is focused on detecting the use of setuid or setgid bits set via chmod. These bits, when set for an application, - result in the application running with the privileges of the owning user or group. By enabling the setuid or setgid bits, - an attacker could run code in a different user's context, possibly with elevated privileges. However, there's a trade-off + This rule is focused on detecting the use of setuid or setgid bits set via chmod. These bits, when set for an application, + result in the application running with the privileges of the owning user or group. By enabling the setuid or setgid bits, + an attacker could run code in a different user's context, possibly with elevated privileges. However, there's a trade-off with noise, given that numerous applications legitimately run chmod. This rule is related to the "Non sudo setuid" rule. condition: > - chmod + chmod and (evt.arg.mode contains "S_ISUID" or evt.arg.mode contains "S_ISGID") and not proc.name in (user_known_chmod_applications) and not exe_running_docker_save @@ -1064,8 +1064,8 @@ condition: (never_true) - rule: Launch Remote File Copy Tools in Container - desc: > - Detect remote file copy tools (like rsync, scp, sftp, dcp) launched within a container, potentially indicating data + desc: > + Detect remote file copy tools (like rsync, scp, sftp, dcp) launched within a container, potentially indicating data exfiltration. Suggest refining this rule to accommodate legitimate use cases. condition: > spawned_process @@ -1093,15 +1093,15 @@ # kubectl run --generator=run-pod/v1 -n default -i --tty busybox --image=busybox --rm -- wget google.com -O /var/google.html # # Check logs running - rule: Network Connection outside Local Subnet - desc: > - Detect network traffic (inbound or outbound) from a container to a destination outside the local subnet. - To operationalize this rule, profile your environment and update the template macro namespace_scope_network_only_subnet. + desc: > + Detect network traffic (inbound or outbound) from a container to a destination outside the local subnet. + To operationalize this rule, profile your environment and update the template macro namespace_scope_network_only_subnet. Customizing network-related rules usually demands substantial engineering effort to ensure their functionality. condition: > - inbound_outbound - and container - and k8s.ns.name in (namespace_scope_network_only_subnet) - and not network_local_subnet + inbound_outbound + and container + and k8s.ns.name in (namespace_scope_network_only_subnet) + and not network_local_subnet output: Network connection outside local subnet | fd_rip_name=%fd.rip.name fd_lip_name=%fd.lip.name fd_cip_name=%fd.cip.name fd_sip_name=%fd.sip.name connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: WARNING tags: [maturity_incubating, container, network, mitre_discovery, T1046, PCI_DSS_6.4.2] @@ -1128,12 +1128,12 @@ condition: (never_true) - rule: Mount Launched in Privileged Container - desc: > - Detect filesystem mounts (using the mount binary) within a privileged container. Due to the elevated privileges, - this action could be one of the TTPs used in an attempt to escape from a container to the host. This type of action + desc: > + Detect filesystem mounts (using the mount binary) within a privileged container. Due to the elevated privileges, + this action could be one of the TTPs used in an attempt to escape from a container to the host. This type of action is often preceded by reconnaissance activities, for which you can also create custom rules. condition: > - spawned_process + spawned_process and container and container.privileged=true and proc.name=mount @@ -1165,14 +1165,14 @@ proc.cmdline contains " --remote-name ")) - rule: Launch Ingress Remote File Copy Tools in Container - desc: > - Detect ingress remote file copy tools (such as curl or wget) launched inside containers. This rule can be - considered a valuable auditing tool, but it has the potential to generate notable noise and requires careful + desc: > + Detect ingress remote file copy tools (such as curl or wget) launched inside containers. This rule can be + considered a valuable auditing tool, but it has the potential to generate notable noise and requires careful profiling before full operationalization. condition: > - spawned_process - and container - and (ingress_remote_file_copy_procs or curl_download) + spawned_process + and container + and (ingress_remote_file_copy_procs or curl_download) and not user_known_ingress_remote_file_copy_activities output: Ingress remote file copy tool launched in container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: NOTICE @@ -1185,14 +1185,14 @@ items: [scsi_id, argoexec] - rule: Read environment variable from /proc files - desc: > - An attempt to read process environment variables from /proc files. The consequences are akin to accessing traditional - sensitive files, as sensitive data, including secrets, might be stored in environment variables. Understanding your - environment, such as identifying critical namespaces, and incorporating extra filtering statements to alert exclusively + desc: > + An attempt to read process environment variables from /proc files. The consequences are akin to accessing traditional + sensitive files, as sensitive data, including secrets, might be stored in environment variables. Understanding your + environment, such as identifying critical namespaces, and incorporating extra filtering statements to alert exclusively for those, can enhance the rule's effectiveness. condition: > - open_read - and container + open_read + and container and (fd.name glob /proc/*/environ) and not proc.name in (known_binaries_to_read_environment_variables_from_proc_files) output: Environment variables were retrieved from /proc files | file=%fd.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -1213,26 +1213,26 @@ condition: (not proc.pname exists or proc.pname in (runc:[0:PARENT], runc:[1:CHILD], runc, docker-runc, exe, docker-runc-cur, containerd-shim, systemd, crio, conmon)) - macro: system_level_side_effect_artifacts_kubectl_cp - condition: (fd.name startswith /etc or - fd.name startswith /proc or - fd.name startswith /lib or - fd.name startswith /run or - fd.name startswith /usr or + condition: (fd.name startswith /etc or + fd.name startswith /proc or + fd.name startswith /lib or + fd.name startswith /run or + fd.name startswith /usr or fd.name="/") - rule: Exfiltrating Artifacts via Kubernetes Control Plane desc: > - Detect the copying of artifacts from a container's file system using the Kubernetes control plane (kubectl cp). - This rule can identify potential exfiltration of application secrets from containers' file systems, potentially - revealing the outcomes of unauthorized access and control plane misuse via stolen identities (such as stolen - credentials like Kubernetes serviceaccount tokens). Can be customized by the adopter to only monitor specific + Detect the copying of artifacts from a container's file system using the Kubernetes control plane (kubectl cp). + This rule can identify potential exfiltration of application secrets from containers' file systems, potentially + revealing the outcomes of unauthorized access and control plane misuse via stolen identities (such as stolen + credentials like Kubernetes serviceaccount tokens). Can be customized by the adopter to only monitor specific artifact paths, containers, or namespaces as needed. condition: > - open_read - and container - and proc.name=tar - and container_entrypoint - and proc.tty=0 + open_read + and container + and proc.name=tar + and container_entrypoint + and proc.tty=0 and not system_level_side_effect_artifacts_kubectl_cp output: Exfiltrating Artifacts via Kubernetes Control Plane | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: NOTICE @@ -1241,7 +1241,7 @@ - rule: Adding ssh keys to authorized_keys desc: > After gaining access, attackers can modify the authorized_keys file to maintain persistence on a victim host. - Where authorized_keys files are modified via cloud APIs or command line interfaces, an adversary may achieve + Where authorized_keys files are modified via cloud APIs or command line interfaces, an adversary may achieve privilege escalation on the target virtual machine if they add a key to a higher-privileged user. This rules aims at detecting any modification to the authorized_keys file, that is usually located under the .ssh directory in any user's home directory. This rule complements the more generic auditing rule "Read ssh information" @@ -1261,13 +1261,13 @@ - rule: Potential Local Privilege Escalation via Environment Variables Misuse desc: > - Process run with suspect environment variable that could be attempting privilege escalation. One use case is - detecting the use of the GLIBC_TUNABLES environment variable, which could be used for privilege escalation - on systems running vulnerable glibc versions. Only known and carefully profiled processes that legitimately - exhibit this behavior should be excluded from this rule. This rule is expected to trigger on every attempt, + Process run with suspect environment variable that could be attempting privilege escalation. One use case is + detecting the use of the GLIBC_TUNABLES environment variable, which could be used for privilege escalation + on systems running vulnerable glibc versions. Only known and carefully profiled processes that legitimately + exhibit this behavior should be excluded from this rule. This rule is expected to trigger on every attempt, even failed ones. condition: > - spawned_process + spawned_process and glibc_tunables_env enabled: true output: Process run with suspect environment variable which could be attempting privilege escalation | env=%proc.env evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags @@ -1276,9 +1276,9 @@ - rule: Backdoored library loaded into SSHD (CVE-2024-3094) desc: This rule detects possible CVE-2024-3094 exploitation when the SSH daemon process loads a vulnerable version of the liblzma library. An attacker could exploit this to interfere with authentication in sshd via systemd, potentially compromising sensitive data or escalating their privileges. - condition: > - open_read and - proc.name=sshd and + condition: > + open_read and + proc.name=sshd and (fd.name contains "liblzma.so.5.6.0" or fd.name contains "liblzma.so.5.6.1") output: SSHD loaded a backdoored version of liblzma library %fd.name with parent %proc.pname and cmdline %proc.cmdline | process=%proc.name parent=%proc.pname file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid proc_exepath=%proc.exepath command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: WARNING @@ -1291,11 +1291,11 @@ condition: (proc.name in (bpf_profiled_binaries)) - rule: BPF Program Not Profiled - desc: > - BPF is a kernel technology that can be misused for malicious purposes, like "Linux Kernel Module Injection". This - rule should be considered an auditing rule to notify you of any unprofiled BPF tools running in your environment. - However, it requires customization after profiling your environment. BPF-powered agents make bpf syscalls all the - time, so this rule only sends logs for BPF_PROG_LOAD calls (bpf cmd=5) in the enter event. If you also want to log + desc: > + BPF is a kernel technology that can be misused for malicious purposes, like "Linux Kernel Module Injection". This + rule should be considered an auditing rule to notify you of any unprofiled BPF tools running in your environment. + However, it requires customization after profiling your environment. BPF-powered agents make bpf syscalls all the + time, so this rule only sends logs for BPF_PROG_LOAD calls (bpf cmd=5) in the enter event. If you also want to log whether the syscall failed or succeeded, remove the direction filter and add the evt.arg.res_or_fd output field. condition: > evt.type=bpf diff --git a/rules/falco-sandbox_rules.yaml b/rules/falco-sandbox_rules.yaml index 9da3a025..40275124 100644 --- a/rules/falco-sandbox_rules.yaml +++ b/rules/falco-sandbox_rules.yaml @@ -262,13 +262,13 @@ items: [google.com] - rule: Unexpected inbound connection source - desc: > - Detect any inbound connection from a source outside of an allowed set of ips, networks, or domain names. - This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely crucial - in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing + desc: > + Detect any inbound connection from a source outside of an allowed set of ips, networks, or domain names. + This rule absolutely requires profiling your environment beforehand. Network-based rules are extremely crucial + in any security program, as they can often provide the only definitive evidence. However, effectively operationalizing them can be challenging due to the potential for noise. condition: > - inbound + inbound and not ((fd.cip in (allowed_inbound_source_ipaddrs)) or (fd.cnet in (allowed_inbound_source_networks)) or (fd.cip.name in (allowed_inbound_source_domains))) @@ -305,15 +305,15 @@ # This rule is not enabled by default, as there are many legitimate # readers of shell config files. - rule: Read Shell Configuration File - desc: > - This rule detects attempts made by non-shell programs to read shell configuration files. It offers additional generic auditing. - It serves as a baseline detection alert for unusual shell configuration file accesses. The rule "Modify Shell Configuration File" + desc: > + This rule detects attempts made by non-shell programs to read shell configuration files. It offers additional generic auditing. + It serves as a baseline detection alert for unusual shell configuration file accesses. The rule "Modify Shell Configuration File" might be more relevant and adequate for your specific cases. condition: > open_read and (fd.filename in (shell_config_filenames) or fd.name in (shell_config_files) or - fd.directory in (shell_config_directories)) + fd.directory in (shell_config_directories)) and not proc.name in (shell_binaries) enabled: false output: A shell configuration file was read by a non-shell program | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -588,8 +588,8 @@ # rule, 'open_write' events don't have a `%evt.arg.newpath` argument for example so # we will always return ``. - rule: Update Package Repository - desc: > - This rule generically detects updates to package repositories and can be seen as an auditing measure. + desc: > + This rule generically detects updates to package repositories and can be seen as an auditing measure. Recommend evaluating its relevance for your specific environment. condition: > ((open_write and access_repositories) or (modify and modify_repositories)) @@ -609,13 +609,13 @@ condition: (never_true) - rule: Write below binary dir - desc: > - Trying to write to any file below specific binary directories can serve as an auditing rule to track general system changes. - Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful - profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system + desc: > + Trying to write to any file below specific binary directories can serve as an auditing rule to track general system changes. + Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful + profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. condition: > - open_write + open_write and bin_dir and not package_mgmt_procs and not exe_running_docker_save @@ -661,10 +661,10 @@ condition: (never_true) - rule: Write below monitored dir - desc: > - Trying to write to any file below a set of monitored directories can serve as an auditing rule to track general system changes. - Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful - profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system + desc: > + Trying to write to any file below a set of monitored directories can serve as an auditing rule to track general system changes. + Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful + profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. condition: > open_write @@ -865,8 +865,8 @@ - macro: write_etc_common condition: > - (open_write - and etc_dir + (open_write + and etc_dir and proc_name_exists and not proc.name in (passwd_binaries, shadowutils_binaries, sysdigcloud_binaries, package_mgmt_binaries, ssl_mgmt_binaries, dhcp_binaries, @@ -973,10 +973,10 @@ and not calico_node) - rule: Write below etc - desc: > - Trying to write to any file below /etc can serve as an auditing rule to track general system changes. - Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful - profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system + desc: > + Trying to write to any file below /etc can serve as an auditing rule to track general system changes. + Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful + profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. condition: write_etc_common output: File below /etc opened for writing | file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -1052,11 +1052,11 @@ condition: (proc.name=mysqlsh and fd.directory=/root/.mysqlsh) - rule: Write below root - desc: > - Trying to write to any file directly below / or /root can serve as an auditing rule to track general system changes. - Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful - profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system - changes, including compliance-related cases. Lastly, this rule stands out as potentially the noisiest one among rules related + desc: > + Trying to write to any file directly below / or /root can serve as an auditing rule to track general system changes. + Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful + profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system + changes, including compliance-related cases. Lastly, this rule stands out as potentially the noisiest one among rules related to "write below. condition: > open_write @@ -1097,10 +1097,10 @@ # Only let rpm-related programs write to the rpm database - rule: Write below rpm database - desc: > - Trying to write to the rpm database by any non-rpm related program can serve as an auditing rule to track general system changes. - Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful - profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system + desc: > + Trying to write to the rpm database by any non-rpm related program can serve as an auditing rule to track general system changes. + Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful + profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. condition: > open_write @@ -1119,16 +1119,16 @@ condition: (never_true) - rule: Modify binary dirs - desc: > - Trying to modify any file below a set of binary directories can serve as an auditing rule to track general system changes. - Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful - profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system + desc: > + Trying to modify any file below a set of binary directories can serve as an auditing rule to track general system changes. + Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful + profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. - condition: > - modify + condition: > + modify and bin_dir_rename - and not package_mgmt_procs - and not exe_running_docker_save + and not package_mgmt_procs + and not exe_running_docker_save and not user_known_modify_bin_dir_activities output: File below known binary directory renamed/removed | file=%fd.name pcmdline=%proc.pcmdline evt_args=%evt.args evt_type=%evt.type evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: ERROR @@ -1139,9 +1139,9 @@ - rule: Mkdir binary dirs desc: > - Trying to create a directory below a set of binary directories can serve as an auditing rule to track general system changes. - Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful - profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system + Trying to create a directory below a set of binary directories can serve as an auditing rule to track general system changes. + Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful + profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. condition: > mkdir @@ -1258,11 +1258,11 @@ - rule: Launch Sensitive Mount Container desc: > - Detect the initial process launched within a container that has a mount from a sensitive host directory (e.g. /proc). - Exceptions are made for known trusted images. This rule holds value for generic auditing; however, its noisiness + Detect the initial process launched within a container that has a mount from a sensitive host directory (e.g. /proc). + Exceptions are made for known trusted images. This rule holds value for generic auditing; however, its noisiness varies based on your environment. condition: > - container_started + container_started and sensitive_mount and not falco_sensitive_mount_containers and not user_sensitive_mount_containers @@ -1283,12 +1283,12 @@ - rule: Launch Disallowed Container desc: > - Detect the initial process launched within a container that is not in a list of allowed containers. - This rule holds value for generic auditing; however, this rule requires a good understanding of your - setup and consistent effort to keep the list of allowed containers current. In some situations, + Detect the initial process launched within a container that is not in a list of allowed containers. + This rule holds value for generic auditing; however, this rule requires a good understanding of your + setup and consistent effort to keep the list of allowed containers current. In some situations, this can be challenging to manage. - condition: > - container_started + condition: > + container_started and not allowed_containers output: Container started and not in allowed list | evt_type=%evt.type user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: WARNING @@ -1299,12 +1299,12 @@ # outgoing connections might be suspicious. These rules are not # enabled by default. - rule: Interpreted procs inbound network activity - desc: > - Any inbound network activity performed by any interpreted program (perl, python, ruby, etc.). While it offers broad coverage and behavioral - insights, operationalizing it effectively requires significant time and might result in a moderate level of noise. Suggesting customizing + desc: > + Any inbound network activity performed by any interpreted program (perl, python, ruby, etc.). While it offers broad coverage and behavioral + insights, operationalizing it effectively requires significant time and might result in a moderate level of noise. Suggesting customizing this rule to be more specific. For example, you could set it up to alert only for important namespaces after studying their usual behavior. condition: > - inbound + inbound and interpreted_procs enabled: false output: Interpreted program received/listened for network traffic | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -1312,12 +1312,12 @@ tags: [maturity_sandbox, host, container, network, mitre_exfiltration, TA0011] - rule: Interpreted procs outbound network activity - desc: > - Any outbound network activity performed by any interpreted program (perl, python, ruby, etc.). While it offers broad coverage and behavioral - insights, operationalizing it effectively requires significant time and might result in a moderate level of noise. Suggesting customizing + desc: > + Any outbound network activity performed by any interpreted program (perl, python, ruby, etc.). While it offers broad coverage and behavioral + insights, operationalizing it effectively requires significant time and might result in a moderate level of noise. Suggesting customizing this rule to be more specific. For example, you could set it up to alert only for important namespaces after studying their usual behavior. condition: > - outbound + outbound and interpreted_procs enabled: false output: Interpreted program performed outgoing network connection | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -1334,16 +1334,16 @@ condition: (never_true) - rule: Unexpected K8s NodePort Connection - desc: > - Detect attempts to utilize K8s NodePorts from a container. K8s NodePorts are accessible on the eth0 interface of - each node, and they facilitate external traffic into a Kubernetes cluster. Attackers could misuse them for - unauthorized access. The rule uses default port ranges, but check for custom ranges and make necessary adjustments. + desc: > + Detect attempts to utilize K8s NodePorts from a container. K8s NodePorts are accessible on the eth0 interface of + each node, and they facilitate external traffic into a Kubernetes cluster. Attackers could misuse them for + unauthorized access. The rule uses default port ranges, but check for custom ranges and make necessary adjustments. Also, consider tuning this rule as needed. - condition: > - inbound_outbound - and container - and fd.sport >= 30000 - and fd.sport <= 32767 + condition: > + inbound_outbound + and container + and fd.sport >= 30000 + and fd.sport <= 32767 and not nodeport_containers enabled: false output: Unexpected K8s NodePort Connection | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -1358,15 +1358,15 @@ condition: (never_true) - rule: Create Hidden Files or Directories - desc: > - Detecting hidden files or directories creation can serve as an auditing rule to track general system changes. - Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful - profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system + desc: > + Detecting hidden files or directories creation can serve as an auditing rule to track general system changes. + Such rules can be noisy and challenging to interpret, particularly if your system frequently undergoes updates. However, careful + profiling of your environment can transform this rule into an effective rule for detecting unusual behavior associated with system changes, including compliance-related cases. condition: > ((modify and evt.arg.newpath contains "/.") or (mkdir and evt.arg.path contains "/.") or - (open_write and evt.arg.flags contains "O_CREAT" and fd.name contains "/." and not fd.name pmatch (exclude_hidden_directories))) + (open_write and evt.arg.flags contains "O_CREAT" and fd.name contains "/." and not fd.name pmatch (exclude_hidden_directories))) and not user_known_create_hidden_file_activities and not exe_running_docker_save enabled: false @@ -1473,12 +1473,12 @@ # The rule is disabled by default. # Note: falco will send DNS request to resolve miner pool domain which may trigger alerts in your environment. - rule: Detect outbound connections to common miner pool ports - desc: > - Miners usually connect to miner pools using standard ports, and this rule flags such activity. Important: Falco currently sends DNS - requests to resolve miner pool domains, which could trigger other alerts. Prior to enabling this rule, it's advised to ensure whether + desc: > + Miners usually connect to miner pools using standard ports, and this rule flags such activity. Important: Falco currently sends DNS + requests to resolve miner pool domains, which could trigger other alerts. Prior to enabling this rule, it's advised to ensure whether this is acceptable for your environment. This rule is specifically disabled for that reason. - condition: > - net_miner_pool + condition: > + net_miner_pool and not trusted_images_query_miner_domain_dns enabled: false output: Outbound connection to IP/Port flagged by https://cryptoioc.ch | ip=%fd.rip connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -1486,14 +1486,14 @@ tags: [maturity_sandbox, host, container, network, mitre_impact, T1496] - rule: Detect crypto miners using the Stratum protocol - desc: > - Miners commonly specify the mining pool to connect to using a URI that starts with "stratum+tcp". However, this rule is highly specific to + desc: > + Miners commonly specify the mining pool to connect to using a URI that starts with "stratum+tcp". However, this rule is highly specific to this technique, and matching command-line arguments can generally be bypassed quite easily. - condition: > - spawned_process - and (proc.cmdline contains "stratum+tcp" or - proc.cmdline contains "stratum2+tcp" or - proc.cmdline contains "stratum+ssl" or + condition: > + spawned_process + and (proc.cmdline contains "stratum+tcp" or + proc.cmdline contains "stratum2+tcp" or + proc.cmdline contains "stratum+ssl" or proc.cmdline contains "stratum2+ssl") output: Possible miner running | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: CRITICAL @@ -1523,14 +1523,14 @@ condition: (user_known_k8s_client_container) - rule: Kubernetes Client Tool Launched in Container - desc: > - Detect the execution of a Kubernetes client tool (like docker, kubectl, crictl) within a container, which is typically not expected behavior. - Although this rule targets container workloads, monitoring the use of tools like crictl on the host over interactive access could also be + desc: > + Detect the execution of a Kubernetes client tool (like docker, kubectl, crictl) within a container, which is typically not expected behavior. + Although this rule targets container workloads, monitoring the use of tools like crictl on the host over interactive access could also be valuable for broader auditing objectives. - condition: > - spawned_process - and container - and not user_known_k8s_client_container_parens + condition: > + spawned_process + and container + and not user_known_k8s_client_container_parens and proc.name in (k8s_client_binaries) output: Kubernetes Client Tool Launched in Container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: WARNING @@ -1549,21 +1549,21 @@ condition: (never_true) - rule: Container Drift Detected (chmod) - desc: > - Detect new executables created within a container as a result of chmod. While this detection can generate significant noise, chmod - usage is frequently linked to dropping and executing malicious implants. The newer rule "Drop and execute new binary in container" - provides more precise detection of this TTP using unambiguous kernel signals. It is recommended to use the new rule. However, this + desc: > + Detect new executables created within a container as a result of chmod. While this detection can generate significant noise, chmod + usage is frequently linked to dropping and executing malicious implants. The newer rule "Drop and execute new binary in container" + provides more precise detection of this TTP using unambiguous kernel signals. It is recommended to use the new rule. However, this rule might be more relevant for auditing if applicable in your environment, such as when chmod is used on files within the /tmp folder. condition: > - chmod - and container - and evt.rawres>=0 + chmod + and container + and evt.rawres>=0 and ((evt.arg.mode contains "S_IXUSR") or (evt.arg.mode contains "S_IXGRP") or (evt.arg.mode contains "S_IXOTH")) - and not runc_writing_exec_fifo - and not runc_writing_var_lib_docker - and not user_known_container_drift_activities + and not runc_writing_exec_fifo + and not runc_writing_var_lib_docker + and not user_known_container_drift_activities enabled: false output: Drift detected (chmod), new executable created in a container | filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: ERROR @@ -1574,16 +1574,16 @@ # **************************************************************************** - rule: Container Drift Detected (open+create) desc: > - Detect new executables created within a container as a result of open+create. The newer rule "Drop and execute new binary in container" - provides more precise detection of this TTP using unambiguous kernel signals. It is recommended to use the new rule. + Detect new executables created within a container as a result of open+create. The newer rule "Drop and execute new binary in container" + provides more precise detection of this TTP using unambiguous kernel signals. It is recommended to use the new rule. condition: > - evt.type in (open,openat,openat2,creat) + evt.type in (open,openat,openat2,creat) and evt.rawres>=0 - and evt.is_open_exec=true - and container - and not runc_writing_exec_fifo - and not runc_writing_var_lib_docker - and not user_known_container_drift_activities + and evt.is_open_exec=true + and container + and not runc_writing_exec_fifo + and not runc_writing_var_lib_docker + and not user_known_container_drift_activities enabled: false output: Drift detected (open+create), new executable created in a container | filename=%evt.arg.filename name=%evt.arg.name mode=%evt.arg.mode evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: ERROR @@ -1598,15 +1598,15 @@ # The rule is disabled by default and should be enabled when non-root container policy has been applied. # Note the rule will not work as expected when usernamespace is applied, e.g. userns-remap is enabled. - rule: Container Run as Root User - desc: > - Container detected running as the root user. This should be taken into account especially when policies disallow containers from running with - root user privileges. Note that a root user in containers doesn't inherently possess extensive power, as modern container environments define + desc: > + Container detected running as the root user. This should be taken into account especially when policies disallow containers from running with + root user privileges. Note that a root user in containers doesn't inherently possess extensive power, as modern container environments define privileges through Linux capabilities. To learn more, check out the rule "Launch Privileged Container". - condition: > - spawned_process - and container - and proc.vpid=1 - and user.uid=0 + condition: > + spawned_process + and container + and proc.vpid=1 + and user.uid=0 and not user_known_run_as_root_container enabled: false output: Container launched with root user privilege | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags @@ -1616,15 +1616,15 @@ # This rule helps detect CVE-2021-3156: # A privilege escalation to root through heap-based buffer overflow - rule: Sudo Potential Privilege Escalation - desc: > - Affecting sudo (<= 1.9.5p2), there's a privilege escalation vulnerability. By executing sudo using the sudoedit -s or sudoedit -i command with a - command-line argument that ends with a single backslash character, an unprivileged user can potentially escalate privileges to root. This rule is + desc: > + Affecting sudo (<= 1.9.5p2), there's a privilege escalation vulnerability. By executing sudo using the sudoedit -s or sudoedit -i command with a + command-line argument that ends with a single backslash character, an unprivileged user can potentially escalate privileges to root. This rule is highly specific and might be bypassed due to potential issues with string matching on command line arguments. - condition: > - spawned_process - and user.uid != 0 - and (proc.name=sudoedit or proc.name = sudo) - and (proc.args contains -s or proc.args contains -i or proc.args contains --login) + condition: > + spawned_process + and user.uid != 0 + and (proc.name=sudoedit or proc.name = sudo) + and (proc.args contains -s or proc.args contains -i or proc.args contains --login) and (proc.args contains "\ " or proc.args endswith \) output: Detect Sudo Privilege Escalation Exploit (CVE-2021-3156) | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: CRITICAL @@ -1634,13 +1634,13 @@ items: [] - rule: Unprivileged Delegation of Page Faults Handling to a Userspace Process - desc: > - Detect a successful unprivileged userfaultfd syscall, which could serve as an attack primitive for exploiting other vulnerabilities. + desc: > + Detect a successful unprivileged userfaultfd syscall, which could serve as an attack primitive for exploiting other vulnerabilities. To fine-tune this rule, consider using the template list "user_known_userfaultfd_processes". condition: > - evt.type = userfaultfd - and user.uid != 0 - and (evt.rawres >= 0 or evt.res != -1) + evt.type = userfaultfd + and user.uid != 0 + and (evt.rawres >= 0 or evt.res != -1) and not proc.name in (user_known_userfaultfd_processes) output: An userfaultfd syscall was successfully executed by an unprivileged user | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: CRITICAL @@ -1649,14 +1649,14 @@ # This rule helps detect CVE-2021-4034: # A privilege escalation to root through memory corruption - rule: Polkit Local Privilege Escalation Vulnerability (CVE-2021-4034) - desc: > - This rule detects attempts to exploit a privilege escalation vulnerability in Polkit's pkexec. Through the execution of specially - crafted code, a local user can exploit this weakness to attain root privileges on a compromised system. This rule is highly + desc: > + This rule detects attempts to exploit a privilege escalation vulnerability in Polkit's pkexec. Through the execution of specially + crafted code, a local user can exploit this weakness to attain root privileges on a compromised system. This rule is highly specific in its scope. condition: - spawned_process - and user.uid != 0 - and proc.name=pkexec + spawned_process + and user.uid != 0 + and proc.name=pkexec and proc.args = '' output: Detect Polkit pkexec Local Privilege Escalation Exploit (CVE-2021-4034) | args=%proc.args evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: CRITICAL @@ -1668,11 +1668,11 @@ condition: (evt.type=recvfrom and fd.type in (ipv4, ipv6) and proc.exe endswith java) - rule: Java Process Class File Download - desc: > - Detecting a Java process downloading a class file which could indicate a successful exploit of the log4shell Log4j vulnerability (CVE-2021-44228). + desc: > + Detecting a Java process downloading a class file which could indicate a successful exploit of the log4shell Log4j vulnerability (CVE-2021-44228). This rule is highly specific in its scope. condition: > - java_network_read + java_network_read and evt.buffer bcontains cafebabe output: Java process class file download | server_ip=%fd.sip server_port=%fd.sport connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: CRITICAL @@ -1686,14 +1686,14 @@ condition: proc.name in (docker_binaries) - rule: Modify Container Entrypoint - desc: > - This rule detect an attempt to write on container entrypoint symlink (/proc/self/exe). Possible CVE-2019-5736 Container Breakout exploitation attempt. + desc: > + This rule detect an attempt to write on container entrypoint symlink (/proc/self/exe). Possible CVE-2019-5736 Container Breakout exploitation attempt. This rule has a more narrow scope. condition: > - open_write - and container - and (fd.name=/proc/self/exe or fd.name startswith /proc/self/fd/) - and not docker_procs + open_write + and container + and (fd.name=/proc/self/exe or fd.name startswith /proc/self/fd/) + and not docker_procs and not proc.cmdline = "runc:[1:CHILD] init" enabled: false output: Detect Potential Container Breakout Exploit (CVE-2019-5736) | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -1707,21 +1707,21 @@ condition: (proc.cmdline contains "base64" and (proc.cmdline contains "--decode" or proc.cmdline contains "-d")) - rule: Decoding Payload in Container - desc: > - Detect any use of {base64} decoding in a container. Legitimate applications may decode encoded payloads. The template list - known_decode_payload_containers can be used for simple tuning and customization, or you can adopt custom, more refined tuning. Less - sophisticated adversaries may {base64}-decode their payloads not only to obfuscate them, but also to ensure that the payload remains - intact when the application processes it. Note that injecting commands into an application's input often results in the application - processing passed strings like "sh -c". In these cases, you may be lucky and the encoded blob will also be logged. Otherwise, all you - will see is the {base64} decoding command, as the encoded blob was already interpreted by the shell. - condition: > - spawned_process - and container - and base64_decoding + desc: > + Detect any use of {base64} decoding in a container. Legitimate applications may decode encoded payloads. The template list + known_decode_payload_containers can be used for simple tuning and customization, or you can adopt custom, more refined tuning. Less + sophisticated adversaries may {base64}-decode their payloads not only to obfuscate them, but also to ensure that the payload remains + intact when the application processes it. Note that injecting commands into an application's input often results in the application + processing passed strings like "sh -c". In these cases, you may be lucky and the encoded blob will also be logged. Otherwise, all you + will see is the {base64} decoding command, as the encoded blob was already interpreted by the shell. + condition: > + spawned_process + and container + and base64_decoding and not container.image.repository in (known_decode_payload_containers) output: Decoding Payload in Container | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: INFO - tags: [maturity_sandbox, container, process, mitre_command_and_control, T1132] + tags: [maturity_sandbox, container, process, mitre_command_and_control, T1132] - list: recon_binaries items: [w, whoami, id, who, uname] @@ -1730,25 +1730,25 @@ - rule: Basic Interactive Reconnaissance desc: > - This rule detects basic interactive reconnaissance commands that are typically run by unsophisticated attackers or used - in internal Red Team exercises. Interactive is defined as a terminal being present (proc.tty != 0). This could be any - form of reverse shell or usage of kubectl exec or ssh etc. In addition, filtering for the process being the process group - leader indicates that the command was "directly" typed into the terminal and not run as a result of a script. This rule - is a basic auditing or template rule. You can expand the list of reconnaissance commands, such as by adding "ls". Common - anti-patterns are SRE activity or debugging, but it is still worth capturing this generically. Typically, you would expect + This rule detects basic interactive reconnaissance commands that are typically run by unsophisticated attackers or used + in internal Red Team exercises. Interactive is defined as a terminal being present (proc.tty != 0). This could be any + form of reverse shell or usage of kubectl exec or ssh etc. In addition, filtering for the process being the process group + leader indicates that the command was "directly" typed into the terminal and not run as a result of a script. This rule + is a basic auditing or template rule. You can expand the list of reconnaissance commands, such as by adding "ls". Common + anti-patterns are SRE activity or debugging, but it is still worth capturing this generically. Typically, you would expect other rules to fire as well in relation to this activity. condition: > - spawned_process - and recon_binaries_procs - and proc.tty != 0 + spawned_process + and recon_binaries_procs + and proc.tty != 0 and proc.is_vpgid_leader=true output: Basic Interactive Reconnaissance | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: NOTICE tags: [maturity_sandbox, host, container, process, mitre_reconnaissance, TA0043] - rule: Netcat/Socat Remote Code Execution on Host - desc: > - Netcat/Socat Program runs on host that allows remote code execution and may be utilized + desc: > + Netcat/Socat Program runs on host that allows remote code execution and may be utilized as a part of a variety of reverse shell payload https://github.com/swisskyrepo/PayloadsAllTheThings/. These programs are of higher relevance as they are commonly installed on UNIX-like operating systems. condition: > diff --git a/rules/falco_rules.yaml b/rules/falco_rules.yaml index 36e12961..40cb8b1d 100644 --- a/rules/falco_rules.yaml +++ b/rules/falco_rules.yaml @@ -317,15 +317,15 @@ # ****************************************************************************** - rule: Directory traversal monitored file read desc: > - Web applications can be vulnerable to directory traversal attacks that allow accessing files outside of the web app's root directory - (e.g. Arbitrary File Read bugs). System directories like /etc are typically accessed via absolute paths. Access patterns outside of this + Web applications can be vulnerable to directory traversal attacks that allow accessing files outside of the web app's root directory + (e.g. Arbitrary File Read bugs). System directories like /etc are typically accessed via absolute paths. Access patterns outside of this (here path traversal) can be regarded as suspicious. This rule includes failed file open attempts. - condition: > - (open_read or open_file_failed) - and (etc_dir or user_ssh_directory or - fd.name startswith /root/.ssh or - fd.name contains "id_rsa") - and directory_traversal + condition: > + (open_read or open_file_failed) + and (etc_dir or user_ssh_directory or + fd.name startswith /root/.ssh or + fd.name contains "id_rsa") + and directory_traversal and not proc.pname in (shell_binaries) enabled: true output: Read monitored file via directory traversal | file=%fd.name fileraw=%fd.nameraw gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty @@ -343,16 +343,16 @@ An attempt to read any sensitive file (e.g. files containing user/password/authentication information) by a trusted program after startup. Trusted programs might read these files at startup to load initial state, but not afterwards. Can be customized as needed. - In modern containerized cloud infrastructures, accessing traditional Linux sensitive files - might be less relevant, yet it remains valuable for baseline detections. While we provide additional - rules for SSH or cloud vendor-specific credentials, you can significantly enhance your security + In modern containerized cloud infrastructures, accessing traditional Linux sensitive files + might be less relevant, yet it remains valuable for baseline detections. While we provide additional + rules for SSH or cloud vendor-specific credentials, you can significantly enhance your security program by crafting custom rules for critical application credentials unique to your environment. - condition: > - open_read - and sensitive_files - and server_procs - and not proc_is_new - and proc.name!="sshd" + condition: > + open_read + and sensitive_files + and server_procs + and not proc_is_new + and proc.name!="sshd" and not user_known_read_sensitive_files_activities output: Sensitive file opened for reading by trusted program after startup | file=%fd.name pcmdline=%proc.pcmdline gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: WARNING @@ -398,9 +398,9 @@ desc: > An attempt to read any sensitive file (e.g. files containing user/password/authentication information). Exceptions are made for known trusted programs. Can be customized as needed. - In modern containerized cloud infrastructures, accessing traditional Linux sensitive files - might be less relevant, yet it remains valuable for baseline detections. While we provide additional - rules for SSH or cloud vendor-specific credentials, you can significantly enhance your security + In modern containerized cloud infrastructures, accessing traditional Linux sensitive files + might be less relevant, yet it remains valuable for baseline detections. While we provide additional + rules for SSH or cloud vendor-specific credentials, you can significantly enhance your security program by crafting custom rules for critical application credentials unique to your environment. condition: > open_read @@ -562,15 +562,15 @@ # (the ./run and ./finish scripts), but the processes runsv can not # spawn shells. - rule: Run shell untrusted - desc: > - An attempt to spawn a shell below a non-shell application. The non-shell applications that are monitored are - defined in the protected_shell_spawner macro, with protected_shell_spawning_binaries being the list you can - easily customize. For Java parent processes, please note that Java often has a custom process name. Therefore, - rely more on proc.exe to define Java applications. This rule can be noisier, as you can see in the exhaustive - existing tuning. However, given it is very behavior-driven and broad, it is universally relevant to catch - general Remote Code Execution (RCE). Allocate time to tune this rule for your use cases and reduce noise. - Tuning suggestions include looking at the duration of the parent process (proc.ppid.duration) to define your - long-running app processes. Checking for newer fields such as proc.vpgid.name and proc.vpgid.exe instead of the + desc: > + An attempt to spawn a shell below a non-shell application. The non-shell applications that are monitored are + defined in the protected_shell_spawner macro, with protected_shell_spawning_binaries being the list you can + easily customize. For Java parent processes, please note that Java often has a custom process name. Therefore, + rely more on proc.exe to define Java applications. This rule can be noisier, as you can see in the exhaustive + existing tuning. However, given it is very behavior-driven and broad, it is universally relevant to catch + general Remote Code Execution (RCE). Allocate time to tune this rule for your use cases and reduce noise. + Tuning suggestions include looking at the duration of the parent process (proc.ppid.duration) to define your + long-running app processes. Checking for newer fields such as proc.vpgid.name and proc.vpgid.exe instead of the direct parent process being a non-shell application could make the rule more robust. condition: > spawned_process @@ -687,19 +687,19 @@ # output: "Interactive root | %user.name %proc.name %evt.type %evt.args %fd.name" # priority: WARNING - rule: System user interactive - desc: > + desc: > System (e.g. non-login) users spawning new processes. Can add custom service users (e.g. apache or mysqld). - 'Interactive' is defined as new processes as descendants of an ssh session or login process. Consider further tuning - by only looking at processes in a terminal / tty (proc.tty != 0). A newer field proc.is_vpgid_leader could be of help - to distinguish if the process was "directly" executed, for instance, in a tty, or executed as a descendant process in the - same process group, which, for example, is the case when subprocesses are spawned from a script. Consider this rule - as a great template rule to monitor interactive accesses to your systems more broadly. However, such a custom rule would be - unique to your environment. The rule "Terminal shell in container" that fires when using "kubectl exec" is more Kubernetes + 'Interactive' is defined as new processes as descendants of an ssh session or login process. Consider further tuning + by only looking at processes in a terminal / tty (proc.tty != 0). A newer field proc.is_vpgid_leader could be of help + to distinguish if the process was "directly" executed, for instance, in a tty, or executed as a descendant process in the + same process group, which, for example, is the case when subprocesses are spawned from a script. Consider this rule + as a great template rule to monitor interactive accesses to your systems more broadly. However, such a custom rule would be + unique to your environment. The rule "Terminal shell in container" that fires when using "kubectl exec" is more Kubernetes relevant, whereas this one could be more interesting for the underlying host. - condition: > - spawned_process - and system_users - and interactive + condition: > + spawned_process + and system_users + and interactive and not user_known_system_user_login output: System user ran an interactive command | evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: INFO @@ -712,15 +712,15 @@ - rule: Terminal shell in container desc: > - A shell was used as the entrypoint/exec point into a container with an attached terminal. Parent process may have - legitimately already exited and be null (read container_entrypoint macro). Common when using "kubectl exec" in Kubernetes. - Correlate with k8saudit exec logs if possible to find user or serviceaccount token used (fuzzy correlation by namespace and pod name). - Rather than considering it a standalone rule, it may be best used as generic auditing rule while examining other triggered + A shell was used as the entrypoint/exec point into a container with an attached terminal. Parent process may have + legitimately already exited and be null (read container_entrypoint macro). Common when using "kubectl exec" in Kubernetes. + Correlate with k8saudit exec logs if possible to find user or serviceaccount token used (fuzzy correlation by namespace and pod name). + Rather than considering it a standalone rule, it may be best used as generic auditing rule while examining other triggered rules in this container/tty. condition: > - spawned_process + spawned_process and container - and shell_procs + and shell_procs and proc.tty != 0 and container_entrypoint and not user_expected_terminal_shell_in_container_conditions @@ -826,36 +826,36 @@ - rule: Contact K8S API Server From Container desc: > - Detect attempts to communicate with the K8S API Server from a container by non-profiled users. Kubernetes APIs play a - pivotal role in configuring the cluster management lifecycle. Detecting potential unauthorized access to the API server - is of utmost importance. Audit your complete infrastructure and pinpoint any potential machines from which the API server - might be accessible based on your network layout. If Falco can't operate on all these machines, consider analyzing the - Kubernetes audit logs (typically drained from control nodes, and Falco offers a k8saudit plugin) as an additional data + Detect attempts to communicate with the K8S API Server from a container by non-profiled users. Kubernetes APIs play a + pivotal role in configuring the cluster management lifecycle. Detecting potential unauthorized access to the API server + is of utmost importance. Audit your complete infrastructure and pinpoint any potential machines from which the API server + might be accessible based on your network layout. If Falco can't operate on all these machines, consider analyzing the + Kubernetes audit logs (typically drained from control nodes, and Falco offers a k8saudit plugin) as an additional data source for detections within the control plane. condition: > - evt.type=connect - and (fd.typechar=4 or fd.typechar=6) - and container - and k8s_api_server - and not k8s_containers + evt.type=connect + and (fd.typechar=4 or fd.typechar=6) + and container + and k8s_api_server + and not k8s_containers and not user_known_contact_k8s_api_server_activities output: Unexpected connection to K8s API Server from container | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: NOTICE tags: [maturity_stable, container, network, k8s, mitre_discovery, T1565] - rule: Netcat Remote Code Execution in Container - desc: > - Netcat Program runs inside container that allows remote code execution and may be utilized + desc: > + Netcat Program runs inside container that allows remote code execution and may be utilized as a part of a variety of reverse shell payload https://github.com/swisskyrepo/PayloadsAllTheThings/. These programs are of higher relevance as they are commonly installed on UNIX-like operating systems. - Can fire in combination with the "Redirect STDOUT/STDIN to Network Connection in Container" + Can fire in combination with the "Redirect STDOUT/STDIN to Network Connection in Container" rule as it utilizes a different evt.type. condition: > - spawned_process - and container - and ((proc.name = "nc" and (proc.cmdline contains " -e" or + spawned_process + and container + and ((proc.name = "nc" and (proc.cmdline contains " -e" or proc.cmdline contains " -c")) or - (proc.name = "ncat" and (proc.args contains "--sh-exec" or + (proc.name = "ncat" and (proc.args contains "--sh-exec" or proc.args contains "--exec" or proc.args contains "-e " or proc.args contains "-c " or proc.args contains "--lua-exec")) ) @@ -888,16 +888,16 @@ - rule: Search Private Keys or Passwords desc: > - Detect attempts to search for private keys or passwords using the grep or find command. This is often seen with - unsophisticated attackers, as there are many ways to access files using bash built-ins that could go unnoticed. - Regardless, this serves as a solid baseline detection that can be tailored to cover these gaps while maintaining + Detect attempts to search for private keys or passwords using the grep or find command. This is often seen with + unsophisticated attackers, as there are many ways to access files using bash built-ins that could go unnoticed. + Regardless, this serves as a solid baseline detection that can be tailored to cover these gaps while maintaining an acceptable noise level. condition: > - spawned_process + spawned_process and ((grep_commands and private_key_or_password) or - (proc.name = "find" and (proc.args contains "id_rsa" or - proc.args contains "id_dsa" or - proc.args contains "id_ed25519" or + (proc.name = "find" and (proc.args contains "id_rsa" or + proc.args contains "id_dsa" or + proc.args contains "id_ed25519" or proc.args contains "id_ecdsa" ) )) @@ -932,16 +932,16 @@ fd.name startswith "/var/lib/rancher/k3s/agent/containerd/tmpmounts/")) - rule: Clear Log Activities - desc: > - Detect clearing of critical access log files, typically done to erase evidence that could be attributed to an adversary's - actions. To effectively customize and operationalize this detection, check for potentially missing log file destinations + desc: > + Detect clearing of critical access log files, typically done to erase evidence that could be attributed to an adversary's + actions. To effectively customize and operationalize this detection, check for potentially missing log file destinations relevant to your environment, and adjust the profiled containers you wish not to be alerted on. condition: > - open_write - and access_log_files - and evt.arg.flags contains "O_TRUNC" + open_write + and access_log_files + and evt.arg.flags contains "O_TRUNC" and not containerd_activities - and not trusted_logging_images + and not trusted_logging_images and not allowed_clear_log_files output: Log files were tampered | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: @@ -958,12 +958,12 @@ condition: (never_true) - rule: Remove Bulk Data from Disk - desc: > - Detect a process running to clear bulk data from disk with the intention to destroy data, possibly interrupting availability + desc: > + Detect a process running to clear bulk data from disk with the intention to destroy data, possibly interrupting availability to systems. Profile your environment and use user_known_remove_data_activities to tune this rule. - condition: > - spawned_process - and clear_data_procs + condition: > + spawned_process + and clear_data_procs and not user_known_remove_data_activities output: Bulk data has been removed from disk | file=%fd.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: @@ -971,24 +971,24 @@ tags: [maturity_stable, host, container, process, filesystem, mitre_impact, T1485] - rule: Create Symlink Over Sensitive Files - desc: > - Detect symlinks created over a curated list of sensitive files or subdirectories under /etc/ or - root directories. Can be customized as needed. Refer to further and equivalent guidance within the + desc: > + Detect symlinks created over a curated list of sensitive files or subdirectories under /etc/ or + root directories. Can be customized as needed. Refer to further and equivalent guidance within the rule "Read sensitive file untrusted". condition: > - create_symlink + create_symlink and (evt.arg.target in (sensitive_file_names) or evt.arg.target in (sensitive_directory_names)) output: Symlinks created over sensitive files | target=%evt.arg.target linkpath=%evt.arg.linkpath evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: WARNING tags: [maturity_stable, host, container, filesystem, mitre_credential_access, T1555] - rule: Create Hardlink Over Sensitive Files - desc: > - Detect hardlink created over a curated list of sensitive files or subdirectories under /etc/ or - root directories. Can be customized as needed. Refer to further and equivalent guidance within the + desc: > + Detect hardlink created over a curated list of sensitive files or subdirectories under /etc/ or + root directories. Can be customized as needed. Refer to further and equivalent guidance within the rule "Read sensitive file untrusted". condition: > - create_hardlink + create_hardlink and (evt.arg.oldpath in (sensitive_file_names)) output: Hardlinks created over sensitive files | target=%evt.arg.oldpath linkpath=%evt.arg.newpath evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: WARNING @@ -998,14 +998,14 @@ items: [] - rule: Packet socket created in container - desc: > - Detect new packet socket at the device driver (OSI Layer 2) level in a container. Packet socket could be used for ARP Spoofing + desc: > + Detect new packet socket at the device driver (OSI Layer 2) level in a container. Packet socket could be used for ARP Spoofing and privilege escalation (CVE-2020-14386) by an attacker. Noise can be reduced by using the user_known_packet_socket_binaries template list. - condition: > + condition: > evt.type=socket - and container - and evt.arg.domain contains AF_PACKET + and container + and evt.arg.domain contains AF_PACKET and not proc.name in (user_known_packet_socket_binaries) output: Packet socket was created in a container | socket_info=%evt.args connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: NOTICE @@ -1028,17 +1028,17 @@ # relying on the rule triggering when any of std{out,err,in} are redirected. - rule: Redirect STDOUT/STDIN to Network Connection in Container desc: > - Detect redirection of stdout/stdin to a network connection within a container, achieved by utilizing a - variant of the dup syscall (potential reverse shell or remote code execution - https://github.com/swisskyrepo/PayloadsAllTheThings/). This detection is behavior-based and may generate - noise in the system, and can be adjusted using the user_known_stand_streams_redirect_activities template - macro. Tuning can be performed similarly to existing detections based on process lineage or container images, + Detect redirection of stdout/stdin to a network connection within a container, achieved by utilizing a + variant of the dup syscall (potential reverse shell or remote code execution + https://github.com/swisskyrepo/PayloadsAllTheThings/). This detection is behavior-based and may generate + noise in the system, and can be adjusted using the user_known_stand_streams_redirect_activities template + macro. Tuning can be performed similarly to existing detections based on process lineage or container images, and/or it can be limited to interactive tty (tty != 0). - condition: > - dup - and container - and evt.rawres in (0, 1, 2) - and fd.type in ("ipv4", "ipv6") + condition: > + dup + and container + and evt.rawres in (0, 1, 2) + and fd.type in ("ipv4", "ipv6") and not user_known_stand_streams_redirect_activities output: Redirect stdout/stdin to network connection | gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] fd.sip=%fd.sip connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: NOTICE @@ -1052,21 +1052,21 @@ Inject Linux Kernel Modules from containers using insmod or modprobe with init_module and finit_module syscalls, given the precondition of sys_module effective capabilities. Profile the environment and consider allowed_container_images_loading_kernel_module to reduce noise and account for legitimate cases. - condition: > - kernel_module_load - and container - and thread.cap_effective icontains sys_module + condition: > + kernel_module_load + and container + and thread.cap_effective icontains sys_module and not container.image.repository in (allowed_container_images_loading_kernel_module) output: Linux Kernel Module injection from container | parent_exepath=%proc.pexepath gparent=%proc.aname[2] gexepath=%proc.aexepath[2] module=%proc.args res=%evt.res evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: WARNING tags: [maturity_stable, host, container, process, mitre_persistence, TA0003] - rule: Debugfs Launched in Privileged Container - desc: > - Detect file system debugger debugfs launched inside a privileged container which might lead to container escape. + desc: > + Detect file system debugger debugfs launched inside a privileged container which might lead to container escape. This rule has a more narrow scope. condition: > - spawned_process + spawned_process and container and container.privileged=true and proc.name=debugfs @@ -1075,15 +1075,15 @@ tags: [maturity_stable, container, cis, process, mitre_privilege_escalation, T1611] - rule: Detect release_agent File Container Escapes - desc: > - Detect an attempt to exploit a container escape using release_agent file. - By running a container with certains capabilities, a privileged user can modify + desc: > + Detect an attempt to exploit a container escape using release_agent file. + By running a container with certains capabilities, a privileged user can modify release_agent file and escape from the container. condition: > - open_write - and container - and fd.name endswith release_agent - and (user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) + open_write + and container + and fd.name endswith release_agent + and (user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and thread.cap_effective contains CAP_SYS_ADMIN output: Detect an attempt to exploit a container escape using release_agent file | file=%fd.name cap_effective=%thread.cap_effective evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: CRITICAL @@ -1108,27 +1108,27 @@ evt.arg.request contains PTRACE_SETREGS)) - rule: PTRACE attached to process - desc: > - Detect an attempt to inject potentially malicious code into a process using PTRACE in order to evade - process-based defenses or elevate privileges. Common anti-patterns are debuggers. Additionally, profiling - your environment via the known_ptrace_procs template macro can reduce noise. + desc: > + Detect an attempt to inject potentially malicious code into a process using PTRACE in order to evade + process-based defenses or elevate privileges. Common anti-patterns are debuggers. Additionally, profiling + your environment via the known_ptrace_procs template macro can reduce noise. A successful ptrace syscall generates multiple logs at once. - condition: > - ptrace_attach_or_injection - and proc_name_exists + condition: > + ptrace_attach_or_injection + and proc_name_exists and not known_ptrace_procs output: Detected ptrace PTRACE_ATTACH attempt | proc_pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: WARNING tags: [maturity_stable, host, container, process, mitre_privilege_escalation, T1055.008] - + - rule: PTRACE anti-debug attempt - desc: > - Detect usage of the PTRACE system call with the PTRACE_TRACEME argument, indicating a program actively attempting + desc: > + Detect usage of the PTRACE system call with the PTRACE_TRACEME argument, indicating a program actively attempting to avoid debuggers attaching to the process. This behavior is typically indicative of malware activity. Read more about PTRACE in the "PTRACE attached to process" rule. - condition: > - evt.type=ptrace - and evt.arg.request contains PTRACE_TRACEME + condition: > + evt.type=ptrace + and evt.arg.request contains PTRACE_TRACEME and proc_name_exists output: Detected potential PTRACE_TRACEME anti-debug attempt | proc_pcmdline=%proc.pcmdline evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: NOTICE @@ -1144,12 +1144,12 @@ - rule: Find AWS Credentials desc: > - Detect attempts to search for private keys or passwords using the grep or find command, particularly targeting standard - AWS credential locations. This is often seen with unsophisticated attackers, as there are many ways to access files - using bash built-ins that could go unnoticed. Regardless, this serves as a solid baseline detection that can be tailored + Detect attempts to search for private keys or passwords using the grep or find command, particularly targeting standard + AWS credential locations. This is often seen with unsophisticated attackers, as there are many ways to access files + using bash built-ins that could go unnoticed. Regardless, this serves as a solid baseline detection that can be tailored to cover these gaps while maintaining an acceptable noise level. This rule complements the rule "Search Private Keys or Passwords". condition: > - spawned_process + spawned_process and ((grep_commands and private_aws_credentials) or (proc.name = "find" and proc.args endswith ".aws/credentials")) output: Detected AWS credentials search activity | proc_pcmdline=%proc.pcmdline proc_cwd=%proc.cwd group_gid=%group.gid group_name=%group.name user_loginname=%user.loginname evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags @@ -1157,19 +1157,19 @@ tags: [maturity_stable, host, container, process, aws, mitre_credential_access, T1552] - rule: Execution from /dev/shm - desc: > - This rule detects file execution in the /dev/shm directory, a tactic often used by threat actors to store their readable, writable, and - occasionally executable files. /dev/shm acts as a link to the host or other containers, creating vulnerabilities for their compromise - as well. Notably, /dev/shm remains unchanged even after a container restart. Consider this rule alongside the newer + desc: > + This rule detects file execution in the /dev/shm directory, a tactic often used by threat actors to store their readable, writable, and + occasionally executable files. /dev/shm acts as a link to the host or other containers, creating vulnerabilities for their compromise + as well. Notably, /dev/shm remains unchanged even after a container restart. Consider this rule alongside the newer "Drop and execute new binary in container" rule. condition: > - spawned_process - and (proc.exe startswith "/dev/shm/" or - (proc.cwd startswith "/dev/shm/" and proc.exe startswith "./" ) or - (shell_procs and proc.args startswith "-c /dev/shm") or - (shell_procs and proc.args startswith "-i /dev/shm") or - (shell_procs and proc.args startswith "/dev/shm") or - (proc.cwd startswith "/dev/shm/" and proc.args startswith "./" )) + spawned_process + and (proc.exe startswith "/dev/shm/" or + (proc.cwd startswith "/dev/shm/" and proc.exe startswith "./" ) or + (shell_procs and proc.args startswith "-c /dev/shm") or + (shell_procs and proc.args startswith "-i /dev/shm") or + (shell_procs and proc.args startswith "/dev/shm") or + (proc.cwd startswith "/dev/shm/" and proc.args startswith "./" )) and not container.image.repository in (falco_privileged_images, trusted_images) output: File execution detected from /dev/shm | evt_res=%evt.res file=%fd.name proc_cwd=%proc.cwd proc_pcmdline=%proc.pcmdline user_loginname=%user.loginname group_gid=%group.gid group_name=%group.name evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags priority: WARNING @@ -1187,15 +1187,15 @@ Detect if an executable not belonging to the base image of a container is being executed. The drop and execute pattern can be observed very often after an attacker gained an initial foothold. is_exe_upper_layer filter field only applies for container runtimes that use overlayfs as union mount filesystem. - Adopters can utilize the provided template list known_drop_and_execute_containers containing allowed container + Adopters can utilize the provided template list known_drop_and_execute_containers containing allowed container images known to execute binaries not included in their base image. Alternatively, you could exclude non-production - namespaces in Kubernetes settings by adjusting the rule further. This helps reduce noise by applying application - and environment-specific knowledge to this rule. Common anti-patterns include administrators or SREs performing + namespaces in Kubernetes settings by adjusting the rule further. This helps reduce noise by applying application + and environment-specific knowledge to this rule. Common anti-patterns include administrators or SREs performing ad-hoc debugging. condition: > spawned_process and container - and proc.is_exe_upper_layer=true + and proc.is_exe_upper_layer=true and not container.image.repository in (known_drop_and_execute_containers) and not known_drop_and_execute_activities output: Executing binary not part of base image | proc_exe=%proc.exe proc_sname=%proc.sname gparent=%proc.aname[2] proc_exe_ino_ctime=%proc.exe_ino.ctime proc_exe_ino_mtime=%proc.exe_ino.mtime proc_exe_ino_ctime_duration_proc_start=%proc.exe_ino.ctime_duration_proc_start proc_cwd=%proc.cwd container_start_ts=%container.start_ts evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags @@ -1222,18 +1222,18 @@ condition: (fd.sport in (ssh_non_standard_ports)) - rule: Disallowed SSH Connection Non Standard Port - desc: > - Detect any new outbound SSH connection from the host or container using a non-standard port. This rule holds the potential - to detect a family of reverse shells that cause the victim machine to connect back out over SSH, with STDIN piped from - the SSH connection to a shell's STDIN, and STDOUT of the shell piped back over SSH. Such an attack can be launched against - any app that is vulnerable to command injection. The upstream rule only covers a limited selection of non-standard ports. - We suggest adding more ports, potentially incorporating ranges based on your environment's knowledge and custom SSH port - configurations. This rule can complement the "Redirect STDOUT/STDIN to Network Connection in Container" or + desc: > + Detect any new outbound SSH connection from the host or container using a non-standard port. This rule holds the potential + to detect a family of reverse shells that cause the victim machine to connect back out over SSH, with STDIN piped from + the SSH connection to a shell's STDIN, and STDOUT of the shell piped back over SSH. Such an attack can be launched against + any app that is vulnerable to command injection. The upstream rule only covers a limited selection of non-standard ports. + We suggest adding more ports, potentially incorporating ranges based on your environment's knowledge and custom SSH port + configurations. This rule can complement the "Redirect STDOUT/STDIN to Network Connection in Container" or "Disallowed SSH Connection" rule. - condition: > - outbound - and proc.exe endswith ssh - and fd.l4proto=tcp + condition: > + outbound + and proc.exe endswith ssh + and fd.l4proto=tcp and ssh_non_standard_ports_network output: Disallowed SSH Connection | connection=%fd.name lport=%fd.lport rport=%fd.rport fd_type=%fd.type fd_proto=%fd.l4proto evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty priority: NOTICE @@ -1243,7 +1243,7 @@ items: [runc] - macro: known_memfd_execution_processes - condition: > + condition: > (proc.name in (known_memfd_execution_binaries)) or (proc.pname in (known_memfd_execution_binaries)) or (proc.exepath = "memfd:runc_cloned:/proc/self/exe") @@ -1252,9 +1252,9 @@ - rule: Fileless execution via memfd_create desc: > - Detect if a binary is executed from memory using the memfd_create technique. This is a well-known defense evasion - technique for executing malware on a victim machine without storing the payload on disk and to avoid leaving traces - about what has been executed. Adopters can whitelist processes that may use fileless execution for benign purposes + Detect if a binary is executed from memory using the memfd_create technique. This is a well-known defense evasion + technique for executing malware on a victim machine without storing the payload on disk and to avoid leaving traces + about what has been executed. Adopters can whitelist processes that may use fileless execution for benign purposes by adding items to the list known_memfd_execution_processes. condition: > spawned_process From fc359343cdfb5efdb89267b6ecb66cd0e934e9fd Mon Sep 17 00:00:00 2001 From: Samuel Gaist Date: Thu, 12 Feb 2026 16:25:45 +0100 Subject: [PATCH 3/6] chore: clean .pre-commit-config Signed-off-by: Samuel Gaist --- .pre-commit-config.yaml | 38 +++++++++++++++++++++----------------- 1 file changed, 21 insertions(+), 17 deletions(-) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index ae49ff89..1ab3288f 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -1,20 +1,24 @@ -# See https://pre-commit.com for more information -# See https://pre-commit.com/hooks.html for more hooks +--- fail_fast: false minimum_pre_commit_version: '0' repos: -- repo: https://github.com/pre-commit/pre-commit-hooks - rev: v6.0.0 - hooks: - - id: check-added-large-files - - id: check-yaml - - id: check-case-conflict - - id: trailing-whitespace - - id: end-of-file-fixer -- repo: local - hooks: - - id: dco-hook-local - name: DCO hook local - entry: ./tools/local_hooks/dco-pre-commit-msg.sh - language: script - stages: [prepare-commit-msg] + - repo: https://github.com/pre-commit/pre-commit-hooks + rev: v6.0.0 + hooks: + - id: check-added-large-files + - id: check-yaml + - id: check-case-conflict + - id: trailing-whitespace + - id: end-of-file-fixer + - repo: local + hooks: + - id: dco-hook-local + name: DCO hook local + entry: ./tools/local_hooks/dco-pre-commit-msg.sh + language: script + stages: [prepare-commit-msg] + - repo: https://github.com/adrienverge/yamllint.git + rev: v1.37.1 + hooks: + - id: yamllint + args: [--format, parsable, --strict, -c=.github/workflows/.yamllint] From d7fa6d9a8847a9d5501aabeac6af603055e41c70 Mon Sep 17 00:00:00 2001 From: Samuel Gaist Date: Thu, 12 Feb 2026 16:26:25 +0100 Subject: [PATCH 4/6] chore: add missing dco pre-commit msg script Don't forget to install the prepare-commit-mgs hooks or it will not be used. Signed-off-by: Samuel Gaist --- .pre-commit-config.yaml | 2 +- tools/local_hooks/dco-pre-commit-msg.sh | 16 ++++++++++++++++ 2 files changed, 17 insertions(+), 1 deletion(-) create mode 100755 tools/local_hooks/dco-pre-commit-msg.sh diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 1ab3288f..f132b80a 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -15,7 +15,7 @@ repos: - id: dco-hook-local name: DCO hook local entry: ./tools/local_hooks/dco-pre-commit-msg.sh - language: script + language: unsupported_script stages: [prepare-commit-msg] - repo: https://github.com/adrienverge/yamllint.git rev: v1.37.1 diff --git a/tools/local_hooks/dco-pre-commit-msg.sh b/tools/local_hooks/dco-pre-commit-msg.sh new file mode 100755 index 00000000..e9ae363a --- /dev/null +++ b/tools/local_hooks/dco-pre-commit-msg.sh @@ -0,0 +1,16 @@ +#!/usr/bin/env sh +# +# This is a git pre-commit-msg hook which automatically add a +# DCO signed-off message if one is missing. +# + +MESSAGE_FILE="$1" +GIT_AUTHOR=$(git var GIT_AUTHOR_IDENT) +SIGNOFF_BY=$(echo $GIT_AUTHOR | sed -n 's/^\(.*>\).*$/Signed-off-by: \1/p') + +# Verify if a DCO signoff message exists. +# Append a DCO signoff message if one doesn't exist. +if ! $(grep -qs "^$SIGNOFF_BY" "$MESSAGE_FILE") ; then + printf "\n$SIGNOFF_BY" >> "$MESSAGE_FILE" +fi +exit 0 From ae817e3d035bacbe9123475551368a8e0b8a883b Mon Sep 17 00:00:00 2001 From: Samuel Gaist Date: Fri, 13 Feb 2026 20:47:34 +0100 Subject: [PATCH 5/6] feat: set default install hook types This ensures that the DCO hook is called Signed-off-by: Samuel Gaist --- .pre-commit-config.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index f132b80a..1479b476 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -1,6 +1,7 @@ --- fail_fast: false minimum_pre_commit_version: '0' +default_install_hook_types: ["pre-commit", "prepare-commit-msg"] repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v6.0.0 From b30bdcc4c3eaf3b302a92e809a79fe3cb51ae2aa Mon Sep 17 00:00:00 2001 From: Samuel Gaist Date: Fri, 13 Feb 2026 20:52:31 +0100 Subject: [PATCH 6/6] chore: pre-commit autoupdate Signed-off-by: Samuel Gaist --- .pre-commit-config.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index 1479b476..c50538de 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -19,7 +19,7 @@ repos: language: unsupported_script stages: [prepare-commit-msg] - repo: https://github.com/adrienverge/yamllint.git - rev: v1.37.1 + rev: v1.38.0 hooks: - id: yamllint args: [--format, parsable, --strict, -c=.github/workflows/.yamllint]