diff --git a/content/docs/technique.md b/content/docs/technique.md index 915d7ec..51e7a6d 100644 --- a/content/docs/technique.md +++ b/content/docs/technique.md @@ -1,6 +1,6 @@ --- title: "Technique" -description: "Techniques represent “how” an adversary achieves a tactical objective by performing an action. For example, an adversary create a backdoor in third party software used within the organization's supply chain. Techniques may also represent “what” an adversary gains by +description: "Techniques represent "how" an adversary achieves a tactical objective by performing an action. For example, an adversary create a backdoor in third party software used within the organization's supply chain. Techniques may also represent "what" an adversary gains by performing an action. This is a useful distinction for the Discovery tactic as the techniques highlight what type of information an adversary is after with a particular action. Sub-techniques further break down behaviors described by techniques into more specific descriptions of how behavior is used to achieve an objective. For example, with backdoor added to third party code, the adversary would need to become a maintainer of the third party library or masquerade the backdoor within a potentially legitimate pull request. @@ -23,7 +23,7 @@ summary: # REQUIRED - description: # REQUIRED - - supports markdown mitigations: # REQUIRED - -reference to mitigation references detections: # REQUIRED - - reference to detection definitions -subtechinques: # OPTIONAL - reference to TechIDs +subTechniques: # OPTIONAL - reference to techniqueIDs references: # OPTIONAL - reference to attacks, articles, blogs etc... metadata: state: # REQUIRED choose draft or release @@ -46,21 +46,19 @@ description: | Dependency confusion is a type of supply chain attack that occurs when an attacker exploits the way some package managers, such as npm and PyPI, resolve dependencies when installing software libraries. In a typical software development project, developers rely on a variety of external libraries, often referred to as dependencies, to build their applications. These libraries are typically stored in a remote repository, and developers use a package manager to install and manage them. An attacker will utilize prior knowledge of usage of dependencies (*Discover used open-source dependencies*) to upload a malicious package with the same name to a public repository. This might "confuse" package managers to use to public resource instead of the local one - thus executing or infecting the CI/CD. This can happen on the developer's machine or the build system and has the potential to further steps of an attack - for example, if the malicious code exfiltrate an access token to production environment -mitigations: -# reference to mitigation references +mitigations: # reference to mitigation references - M1200 -detections: -# reference to detection defintitions +detections: # reference to detection definitions - Detect rogue outgoing traffic from CI/CD system -subtechinques: -# reference to TechIDs +subTechniques: # reference to techniqueIDs - -refrences: +references: - https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 - https://pytorch.org/blog/compromised-nightly-dependency/ + metadata: version: 0.1 state: draft @@ -169,11 +167,11 @@ summary: Dependency Confusion **Sample Response:** ```YAML -decription: | +description: | Dependency confusion is a type of supply chain attack that occurs when an attacker exploits the way some package managers, such as npm and PyPI, resolve dependencies when installing software libraries. ``` -## mitigiations +## mitigations **Type:** String (long text)\ **Description:** a list of mitigation methods - please reference a mitigation id. \ @@ -196,7 +194,7 @@ detections: - D1200 ``` -## subtechinques +## subTechniques **Type:** array\ **Description:** A list of all sub-techniques associated with the technique itself.\ @@ -205,7 +203,7 @@ detections: **Sample Response:** ```YAML -subtechnique: +subTechnique: - T1001 - T1002 ``` @@ -234,7 +232,7 @@ references: **Description:** state of document. The options are `draft` or `release`\ **Field requirement:** Mandatory -### metadata.versionte +### metadata.version **Type:** String\ **Description:** Version number\ **Field requirement:** Optional diff --git a/content/oscar/detections/D1120 - Implement source code scanning for credentials.yaml b/content/oscar/detections/D1120 - Implement source code scanning for credentials.yaml index 0433eda..a8a85a9 100644 --- a/content/oscar/detections/D1120 - Implement source code scanning for credentials.yaml +++ b/content/oscar/detections/D1120 - Implement source code scanning for credentials.yaml @@ -4,7 +4,7 @@ summary: Implement source code scanning for credentials and tokens description: | Set up monitoring of reported issues based on regular credentials scanning results. Scan web applications for embedded secrets and credentials. - It is particularily important after deployment to a web endpoint that you scan that newly deployed app for secrets, credentials and other sensitive data. + It is particularly important after deployment to a web endpoint that you scan that newly deployed app for secrets, credentials and other sensitive data. references: - https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning diff --git a/content/oscar/detections/D1262 - Implement vulnerability assesment.yaml b/content/oscar/detections/D1262 - Implement vulnerability assesment.yaml index dc7151f..a4dba03 100644 --- a/content/oscar/detections/D1262 - Implement vulnerability assesment.yaml +++ b/content/oscar/detections/D1262 - Implement vulnerability assesment.yaml @@ -1,6 +1,6 @@ id: D1262 type: Detection -summary: Implement vulnerability assesment +summary: Implement vulnerability assessment description: | Vulnerability assessment is a proactive approach to mitigating cybersecurity risks by systematically identifying, evaluating, and prioritizing vulnerabilities in a system, network, or application. It involves conducting regular assessments to identify potential weaknesses that could be exploited by attackers, and taking appropriate actions to remediate or mitigate those vulnerabilities. diff --git a/content/oscar/mitigations/M1120 - Store credentials in vault.yaml b/content/oscar/mitigations/M1120 - Store credentials in vault.yaml index 5574331..a1394b2 100644 --- a/content/oscar/mitigations/M1120 - Store credentials in vault.yaml +++ b/content/oscar/mitigations/M1120 - Store credentials in vault.yaml @@ -3,7 +3,7 @@ type: Mitigation summary: Store credentials in vault description: | Sensitive data like credentials and API tokens should not be stored directly in code. - Modern applications talk to many third-party APIs, SaaS solutions and other dependecies. + Modern applications talk to many third-party APIs, SaaS solutions and other dependencies. This integration usually requires an API token, username & password credential or other similar variable. Sometimes these sensitive credentials include database host strings or hostnames. All of these credentials should not be stored directly in code. diff --git a/content/oscar/mitigations/M1121 - Enable git hooks.yaml b/content/oscar/mitigations/M1121 - Enable git hooks.yaml index 845a039..bee185b 100644 --- a/content/oscar/mitigations/M1121 - Enable git hooks.yaml +++ b/content/oscar/mitigations/M1121 - Enable git hooks.yaml @@ -3,7 +3,7 @@ type: Mitigation summary: Enable git hooks to find source code related issues early description: | Enable git hooks to automate the scanning of source code before it is published via git commits. - All Git implementations include a hooks directory inthe .git base directory. + All Git implementations include a hooks directory in the .git base directory. In that directory are several git automations called "hooks". These hooks will automatically run scripts when certain actions happen. The best example of this is the pre-commit hook that runs before a git commit is successful. diff --git a/content/oscar/mitigations/M1201 - Restrict egress traffic from CICD.yaml b/content/oscar/mitigations/M1201 - Restrict egress traffic from CICD.yaml index 7bcf718..eabb689 100644 --- a/content/oscar/mitigations/M1201 - Restrict egress traffic from CICD.yaml +++ b/content/oscar/mitigations/M1201 - Restrict egress traffic from CICD.yaml @@ -1,9 +1,9 @@ id: M1201 type: Mitigation -summary: Restrict egresss traffic in CI/CD +summary: Restrict egress traffic in CI/CD description: | - Restrict egress traffic from the build system to authorized destinations. This is pretty straightforward and a very feasble mitigation since a build system usually requires access to a very limited destinations. - Controlling the traffic has many benifits: + Restrict egress traffic from the build system to authorized destinations. This is pretty straightforward and a very feasible mitigation since a build system usually requires access to a very limited destinations. + Controlling the traffic has many benefits: 1. Prevent exfiltration of sensitive information 2. Block download of packages from unauthorized package repositories 3. Block download of malware diff --git a/content/oscar/mitigations/M1250 - Enable data encryption in transit.yaml b/content/oscar/mitigations/M1250 - Enable data encryption in transit.yaml index 5c3566e..062d2e1 100644 --- a/content/oscar/mitigations/M1250 - Enable data encryption in transit.yaml +++ b/content/oscar/mitigations/M1250 - Enable data encryption in transit.yaml @@ -1,6 +1,6 @@ id: M1250 type: Mitigation -summary: Enable data sencryption in transit +summary: Enable data encryption in transit description: | Data encryption in transit is a critical security control in cloud computing that involves encrypting data as it moves between two points over a network or the internet. This is important to prevent data breaches, protect sensitive data, and comply with data privacy regulations. Cloud service providers use various encryption protocols to establish a secure communication channel, and organizations should ensure that encryption is properly implemented and verified. diff --git a/content/oscar/mitigations/M1501 - Require SBOM from all third-party suppliers.yaml b/content/oscar/mitigations/M1501 - Require SBOM from all third-party suppliers.yaml index a9a2acb..3eeafeb 100644 --- a/content/oscar/mitigations/M1501 - Require SBOM from all third-party suppliers.yaml +++ b/content/oscar/mitigations/M1501 - Require SBOM from all third-party suppliers.yaml @@ -4,7 +4,7 @@ summary: Require SBOM from all third-party suppliers description: | An SBOM for every third-party artifact helps to ensure an artifact is safe to use and fully compliant. This file lists all important metadata, especially all the dependencies of an artifact, and allows for verification of each dependency. - If one of the dependencies/artifacts is attacked or has a new vulnerability (e.g., the “SolarWinds” or even “log4j” attack), it is easier to detect what has been affected by this incident because dependencies in use are listed in the SBOM file + If one of the dependencies/artifacts is attacked or has a new vulnerability (e.g., the "SolarWinds" or even "log4j" attack), it is easier to detect what has been affected by this incident because dependencies in use are listed in the SBOM file. references: - https://snyk.io/blog/building-sbom-open-source-supply-chain-security/ diff --git a/content/oscar/stories/AS1 - Webmin 1.900 RCE.yaml b/content/oscar/stories/AS1 - Webmin 1.900 RCE.yaml index d0eb680..9322b3e 100644 --- a/content/oscar/stories/AS1 - Webmin 1.900 RCE.yaml +++ b/content/oscar/stories/AS1 - Webmin 1.900 RCE.yaml @@ -6,7 +6,7 @@ summary: Webmin 1.900 RCE description: | Webmin, a widely used server administration software, experienced a security incident where attackers introduced a backdoor into version 1.890. This backdoor allowed individuals with knowledge of it to execute commands with root privileges. Subsequent versions, 1.900 to 1.920, also contained a similar backdoor in the code, but it was not exploitable in a default Webmin installation. Only if an administrator had specifically enabled the "changing of expired passwords" feature in the Webmin Configuration ⇾ Authentication section, could it be utilized by an attacker. These vulnerabilities were not accidental flaws; rather, the Webmin source code was deliberately modified to include a concealed vulnerability. -# Techinques used in attack +# Techniques used in attack attacks: - attack: Webmin index: 1 @@ -23,7 +23,7 @@ attacks: - techniqueID: T0191 techName: Malicious Code In Artifacts tactic: Impact - comment: The attackers infected the webmin code with a backdoor that allowed remote code execution. + comment: The attackers infected the Webmin code with a backdoor that allowed remote code execution. - techniqueID: T0135 tactic: Initial Access @@ -35,8 +35,8 @@ attacks: tactic: Initial Access techName: Outdated Software Components comment: | - The webmin build server was apperantly explioitable and the attackers used this to repeat the attack. - *"On September 10th 2018, the vulnerable build server was decomissioned and replaced with a newly installed server running CentOS 7. However, the build directory containing the modified file was copied across from backups made on the original server."* + The Webmin build server was apparently exploitable and the attackers used this to repeat the attack. + "On September 10th 2018, the vulnerable build server was decommissioned and replaced with a newly installed server running CentOS 7. However, the build directory containing the modified file was copied across from backups made on the original server." - attack: Webmin Customers index: 2 diff --git a/content/oscar/stories/AS107 - Dependabot.yaml b/content/oscar/stories/AS107 - Dependabot.yaml index 665a4ad..8051051 100644 --- a/content/oscar/stories/AS107 - Dependabot.yaml +++ b/content/oscar/stories/AS107 - Dependabot.yaml @@ -6,7 +6,7 @@ summary: Spoofed Dependabot description: | A large-scale attack targeted hundreds of GitHub repositories, involving malicious code commits designed to mimic "Dependabot," a standard GitHub tool. The attackers attempted to go unnoticed by impersonating this trusted tool. -# Techinques used in attack +# Techniques used in attack attacks: - attack: Github Repos index: 1 @@ -44,7 +44,7 @@ attacks: Attackers also infected Javascript files with a password stealing malware. - - attack: Users of code for inefected repoistories + - attack: Users of code for infected repositories index: 2 stage: post-supply-chain customer: 1 diff --git a/content/oscar/stories/AS108 - JuiceStealer.yaml b/content/oscar/stories/AS108 - JuiceStealer.yaml index 1bc6881..11e8ca4 100644 --- a/content/oscar/stories/AS108 - JuiceStealer.yaml +++ b/content/oscar/stories/AS108 - JuiceStealer.yaml @@ -6,7 +6,7 @@ summary: JuiceStealer - PyPi Supply Chain Attack description: | The threat actor known as "JuiceLedger" orchestrated a large-scale attack on PyPi, the official Python package repository. This attack was multifaceted, targeting package maintainers by attempting to compromise their PyPi accounts. Additionally, the attacker engaged in TypoSquatting, uploading malicious packages to the repository -# Techinques used in attack +# Techniques used in attack attacks: - attack: PyPi package maintainers index: 1 @@ -36,7 +36,7 @@ attacks: Simultaneously with the phishing attempts, the same malware, JuiceStealer, was introduced into hundreds of Python packages, strategically designed to mimic legitimate packages - - attack: Users of code for inefected repoistories + - attack: Users of code for infected repositories index: 2 stage: post-supply-chain customer: 1 diff --git a/content/oscar/stories/AS109 - Pytorch.yaml b/content/oscar/stories/AS109 - Pytorch.yaml index ef53bfa..be2d507 100644 --- a/content/oscar/stories/AS109 - Pytorch.yaml +++ b/content/oscar/stories/AS109 - Pytorch.yaml @@ -4,9 +4,9 @@ date: 2022-12 summary: Pytorch Dependency Confusion description: | - PyTorch is a machine learning framework based on the Torch library. On December 2022, it was revealed that several builds were infected by malware that was designed to steal environment variables and files. This attack was facilitiated by using dependency confusion of the package "torchtriton" which PyTorch was consuming. + PyTorch is a machine learning framework based on the Torch library. On December 2022, it was revealed that several builds were infected by malware that was designed to steal environment variables and files. This attack was facilitated by using dependency confusion of the package "torchtriton" which PyTorch was consuming. -# Techinques used in attack +# Techniques used in attack attacks: - attack: Torchtriton package index: 1 @@ -18,7 +18,7 @@ attacks: techName: Dependency Confusion tactic: Initial Access comment: | - Torchtriron is a package that the Pytorch project is consuming. On December 2022, the package was altered to exfiltrate sensitive information. Later on, the person that performs this attack confessed anonymosly that it was done for research purposes and all the collected data was deleted. + Torchtriton is a package that the Pytorch project is consuming. On December 2022, the package was altered to exfiltrate sensitive information. Later on, the person that performs this attack confessed anonymously that it was done for research purposes and all the collected data was deleted. diff --git a/content/oscar/stories/AS2 - 3CX Software.yaml b/content/oscar/stories/AS2 - 3CX Software.yaml index d69f081..aafca4b 100644 --- a/content/oscar/stories/AS2 - 3CX Software.yaml +++ b/content/oscar/stories/AS2 - 3CX Software.yaml @@ -4,9 +4,9 @@ date: 2023-04 summary: 3CX Desktop description: | - 3CX is a VOIP software company with more than 600000 customers. In April 2023, the company was subject to an attack that infected their 3CX desktop software with malware. It is suspected to be a nation state attack carried out by North Korea. The attack was faciltiated by attacking the supply chain of a trading software company, Trading Technoloigies. + 3CX is a VOIP software company with more than 600000 customers. In April 2023, the company was subject to an attack that infected their 3CX desktop software with malware. It is suspected to be a nation state attack carried out by North Korea. The attack was facilitated by attacking the supply chain of a trading software company, Trading Technologies. -# Techinques used in attack +# Techniques used in attack attacks: - attack: Trading Technologies index: 1 @@ -17,7 +17,7 @@ attacks: - techniqueID: T0191 techName: Malicious Code In Artifacts tactic: Impact - comment: The attackers trojanized the softare X_TRADER. The software was digitally signed by "Trading Technologies" which strongly suggests that the firm's supply chain was breached. + comment: The attackers trojanized the software X_TRADER. The software was digitally signed by "Trading Technologies" which strongly suggests that the firm's supply chain was breached. links: https://www.mandiant.com/resources/blog/3cx-software-supply-chain-compromise - attack: 3CX @@ -54,7 +54,7 @@ attacks: tactic: Credential Access techName: Harvesting Sensitive Information From Files comment: | - 3CX used to save their application password unencrypted/unhashed in the file system. It is not clear if that was used as part of this attack, but the fact is that they released a new client that resolves this issue. + 3CX used to save their application password unencrypted/un-hashed in the file system. It is not clear if that was used as part of this attack, but the fact is that they released a new client that resolves this issue. - techniqueID: T0176 tactic: Defense Evasion diff --git a/content/oscar/stories/AS3 - Codecov Bash Uploader.yaml b/content/oscar/stories/AS3 - Codecov Bash Uploader.yaml index 0b55a9f..fb12cb7 100644 --- a/content/oscar/stories/AS3 - Codecov Bash Uploader.yaml +++ b/content/oscar/stories/AS3 - Codecov Bash Uploader.yaml @@ -6,7 +6,7 @@ summary: Codecov Breach description: | Codecov is a popular code coverage utility that is used as stem in the CI/CD of many companies. -# Techinques used in attack +# Techniques used in attack attacks: - attack: Codecov index: 1 @@ -22,7 +22,7 @@ attacks: - techniqueID: T0142 techName: Accidental Public Disclosure Of Internal Resources tactic: Reconnaissance - comment: The git credentials was indeliberately saved in the public docker image + comment: The git credentials was in-deliberately saved in the public docker image - techniqueID: T0114 techName: Compromised Service Account @@ -32,7 +32,7 @@ attacks: - techniqueID: T0191 techName: Malicious Code In Artifacts tactic: Impact - comment: The Bash Uploader script was modified to exfiltrate environnent variables of the running system + comment: The Bash Uploader script was modified to exfiltrate environment variables of the running system - attack: Codecov users index: 2 @@ -45,7 +45,7 @@ attacks: tactic: Execution techName: Command Injection comment: | - When the Codecov image was executed - the malicious implant in the Bash Uploader script exflitrated environment variable to the attacker controlled + When the Codecov image was executed - the malicious implant in the Bash Uploader script exfiltrated environment variable to the attacker controlled - techniqueID: T0122 tactic: Initial Access diff --git a/content/oscar/stories/AS4 - PHP Backdoor.yaml b/content/oscar/stories/AS4 - PHP Backdoor.yaml index d120376..486e51d 100644 --- a/content/oscar/stories/AS4 - PHP Backdoor.yaml +++ b/content/oscar/stories/AS4 - PHP Backdoor.yaml @@ -4,9 +4,9 @@ date: 2021-03 summary: PHP Zerodium Backdoor description: | - In March 2023 it was discovered that a bad actor succeeded to infect the official PHP code with a backdoor. PHP is one the most common technologies for web applications - a succesful attack would have meant taking over millions of servers. + In March 2023 it was discovered that a bad actor succeeded to infect the official PHP code with a backdoor. PHP is one the most common technologies for web applications - a successful attack would have meant taking over millions of servers. -# Techinques used in attack +# Techniques used in attack attacks: - attack: PHP Zerodium Backdoor index: 1 @@ -28,15 +28,15 @@ attacks: - techniqueID: T0180 techName: Compromise Services / Servers tactic: Initial Access - comment: PHP Git server was maitained by the PHP developers. After the breach they decided to move to Github. + comment: PHP Git server was maintained by the PHP developers. After the breach they decided to move to Github. - techniqueID: T0191 techName: Malicious Code In Artifacts tactic: Impact comment: | - On March 28th, 2021, two commits to the source code of PHP were more than extraordinary. They contained a backdoor which would execute if HTTP_USER_AGENTT string starts with ‘zerodium’. + On March 28th, 2021, two commits to the source code of PHP were more than extraordinary. They contained a backdoor which would execute if HTTP_USER_AGENT string starts with 'zerodium'. - - attack: PHP Userss + - attack: PHP Users index: 2 stage: post-supply-chain customer: 1 @@ -46,7 +46,7 @@ attacks: - techniqueID: T0172 tactic: Execution techName: Runtime Backdoor - comment: The backdoor would execute commands when a http request with user-agent zerodium was sent + comment: The backdoor would execute commands when a HTTP request with User-Agent 'zerodium' was sent - techniqueID: T0111 tactic: Resource Development diff --git a/content/oscar/stories/AS5 - CCleaner.yaml b/content/oscar/stories/AS5 - CCleaner.yaml index 0dac861..439770e 100644 --- a/content/oscar/stories/AS5 - CCleaner.yaml +++ b/content/oscar/stories/AS5 - CCleaner.yaml @@ -6,7 +6,7 @@ summary: CCleaner description: | CCleaner is a popular system cleanup software -# Techinques used in attack +# Techniques used in attack attacks: - attack: CCleaner index: 1 diff --git a/content/oscar/stories/AS6 - SolarWinds.yaml b/content/oscar/stories/AS6 - SolarWinds.yaml index 9948202..54a4e01 100644 --- a/content/oscar/stories/AS6 - SolarWinds.yaml +++ b/content/oscar/stories/AS6 - SolarWinds.yaml @@ -6,7 +6,7 @@ summary: SolarWinds description: | The SolarWinds incident, one of the most significant cyberattacks in recent history, began when hackers gained unauthorized access to the internal network of SolarWinds, a prominent IT management software provider. In 2019, they injected malicious code into SolarWinds' widely used Orion software, which was unknowingly distributed to around 18,000 customers in a software update released in March 2020. Exploiting this compromise, the hackers conducted targeted cyber-espionage campaigns against various organizations. The breach, attributed to a state-sponsored hacking group believed to be linked to the Russian government, allowed the attackers to gain unauthorized access to systems. In response, directives were issued advising affected organizations to disconnect or power down SolarWinds Orion products. The breach also affected Microsoft, which revealed that the attackers had accessed some of their source code repositories. Investigations, forensic analyses, and mitigation efforts were undertaken to assess the breach's extent, remove the malicious code, and bolster security measures. The incident exposed the attackers' sophistication and highlighted the vulnerability of trusted software supply chains, underscoring the importance of robust cybersecurity measures. -# Techinques used in attack +# Techniques used in attack attacks: - attack: SolarWinds index: 1 @@ -18,7 +18,7 @@ attacks: techName: Accidental public disclosure of internal resources tactic: Reconnaissance comment: | - The password “solarwinds123,” was discovered in 2019 on the public internet by an independent security researcher who warned the company that the leak had exposed a SolarWinds file server. According to the researcher, he was able to use this password to access SolarWinds FTP server. + The password "solarwinds123," was discovered in 2019 on the public internet by an independent security researcher who warned the company that the leak had exposed a SolarWinds file server. According to the researcher, he was able to use this password to access SolarWinds FTP server. - techniqueID: T0105 techName: Active Scanning diff --git a/content/oscar/techniques/T0112 - Compromised token.yaml b/content/oscar/techniques/T0112 - Compromised token.yaml index 8eca565..bbf2d7a 100644 --- a/content/oscar/techniques/T0112 - Compromised token.yaml +++ b/content/oscar/techniques/T0112 - Compromised token.yaml @@ -14,7 +14,7 @@ realm: summary: Compromised token description: | - Access to third party APIs typically uses a token to authenticate acces. + Access to third party APIs typically uses a token to authenticate access. This token is usually a randomized string that is auto-generated by the API provider and should be at least 16 characters or more. This token is passed with a request to the API provider and if the token is valid, the request is successful. Each of these tokens will usually have a set of permissions applied to it that authorizes it to perform very simple read operations, or more complex write and delete operations. diff --git a/content/oscar/techniques/T0117 - SQL injection.yaml b/content/oscar/techniques/T0117 - SQL injection.yaml index 05cec96..b464113 100644 --- a/content/oscar/techniques/T0117 - SQL injection.yaml +++ b/content/oscar/techniques/T0117 - SQL injection.yaml @@ -10,7 +10,7 @@ summary: SQL injection description: | SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. - A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. + A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. Successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. mitigations: diff --git a/content/oscar/techniques/T0122 - Vulnerability in third-party dependency.yaml b/content/oscar/techniques/T0122 - Vulnerability in third-party dependency.yaml index d69b9b9..98eb9d0 100644 --- a/content/oscar/techniques/T0122 - Vulnerability in third-party dependency.yaml +++ b/content/oscar/techniques/T0122 - Vulnerability in third-party dependency.yaml @@ -13,7 +13,7 @@ summary: Vulnerability in third-party CI/CD actions description: | The use of 3rd party Github actions is very common. - Similar to using 3rd party libraries this can also introduce security risks - a malicious Github action has access to very sensitive information - i.e exfiltrating environment variables, including backdoors or malware in source code, infecting build artifcats. + Similar to using 3rd party libraries this can also introduce security risks - a malicious Github action has access to very sensitive information - i.e exfiltrating environment variables, including backdoors or malware in source code, infecting build artifacts. mitigations: - M1120 diff --git a/content/oscar/techniques/T0152 - IDE.yaml b/content/oscar/techniques/T0152 - IDE.yaml index 3b2f765..35f2544 100644 --- a/content/oscar/techniques/T0152 - IDE.yaml +++ b/content/oscar/techniques/T0152 - IDE.yaml @@ -9,7 +9,7 @@ realm: summary: IDE description: | - Malicous code can be injected into build commands, build scripts or project files. + Malicious code can be injected into build commands, build scripts or project files. These commands and scripts can be executed upon IDE project build and run. mitigations: diff --git a/content/oscar/techniques/T0165 - Create access token.yaml b/content/oscar/techniques/T0165 - Create access token.yaml index 5525f3e..220f692 100644 --- a/content/oscar/techniques/T0165 - Create access token.yaml +++ b/content/oscar/techniques/T0165 - Create access token.yaml @@ -11,7 +11,7 @@ summary: Create access token description: | Following initial access, an attacker may attempt to create alternative means of access to the system that was infiltrated. - Since the initial access may use a temporary or temporary session token - a common adversary technique would be to create an access token which will persist the access to the system. For example, after getting an initail access by abusing a compromised 2FA backed session token an attacker created access tokens that allowed both persistance and lateral movement (Circle CI reference) + Since the initial access may use a temporary or temporary session token - a common adversary technique would be to create an access token which will persist the access to the system. For example, after getting an initial access by abusing a compromised 2FA backed session token an attacker created access tokens that allowed both persistence and lateral movement (Circle CI reference) mitigations: - M1310 diff --git a/content/oscar/techniques/T0166 - Trigger pipeline execution.yaml b/content/oscar/techniques/T0166 - Trigger pipeline execution.yaml index a246c75..591e666 100644 --- a/content/oscar/techniques/T0166 - Trigger pipeline execution.yaml +++ b/content/oscar/techniques/T0166 - Trigger pipeline execution.yaml @@ -12,7 +12,7 @@ summary: Trigger pipeline execution description: | The Trigger pipeline execution (Poisoned pipeline execution) attack abuses permissions against an SCM repository, in a way that causes a CI pipeline to execute malicious commands. Users that have permissions to manipulate the CI configuration files, or other files which the CI pipeline job relies on, can modify them to contain malicious commands, ultimately poisoning the CI pipeline executing these commands. - Pipelines executing unreviewed code, for example those which are triggered directly off of pull requests or commits to arbitrary repository branches, are more susceptible to Trigger pipeline exectuion. + Pipelines executing unreviewed code, for example those which are triggered directly off of pull requests or commits to arbitrary repository branches, are more susceptible to Trigger pipeline execution. The reason is that these scenarios, by design, contain code which has not undergone any reviews or approvals. Once able to execute malicious code within the CI pipeline, the attacker can conduct a wide array of malicious operations, all within the context of the pipelines identity. diff --git a/content/oscar/techniques/T0187 - Exposed Storage.yaml b/content/oscar/techniques/T0187 - Exposed Storage.yaml index f0330fb..6f830da 100644 --- a/content/oscar/techniques/T0187 - Exposed Storage.yaml +++ b/content/oscar/techniques/T0187 - Exposed Storage.yaml @@ -10,7 +10,7 @@ summary: Exposed storage description: | Attackers are constantly searching for any data that might help them achieve their malicious goals. - Exposed storage such as S3 buckets are highly values since it might contain sensetivie information that can be used to yield an attack. + Exposed storage such as S3 buckets are highly values since it might contain sensitive information that can be used to yield an attack. For example: file system snapshots that might contain code or secrets. mitigations: diff --git a/content/oscar/techniques/T0188 - CSRF.yaml b/content/oscar/techniques/T0188 - CSRF.yaml index 05b8f7c..cc22be4 100644 --- a/content/oscar/techniques/T0188 - CSRF.yaml +++ b/content/oscar/techniques/T0188 - CSRF.yaml @@ -9,8 +9,8 @@ realm: summary: Cross Site Request Forgery description: | - Cross Site Request Forgert, or CSRF, may have different affects, depending on the application code. - It is widely used in conjunction with spear-phising attacks where adversaries will attempt to abuse authenticated users sessions to perform actions that will allow them to take over a server. + Cross-Site Request Forgery, or CSRF, may have different affects, depending on the application code. + It is widely used in conjunction with spear-phishing attacks where adversaries will attempt to abuse authenticated users sessions to perform actions that will allow them to take over a server. mitigations: - M1720 diff --git a/content/oscar/techniques/T0189 - Secrets in configuration files.yaml b/content/oscar/techniques/T0189 - Secrets in configuration files.yaml index 6db7ef3..0d341bc 100644 --- a/content/oscar/techniques/T0189 - Secrets in configuration files.yaml +++ b/content/oscar/techniques/T0189 - Secrets in configuration files.yaml @@ -10,7 +10,7 @@ realm: summary: Secrets in configuration files description: | - It is a very common mistake for developers to keep secrets in configuration files, these can include user crednetials, private keys, api keys etc... + It is a very common mistake for developers to keep secrets in configuration files, these can include user credentials, private keys, api keys etc... Those files are usually the first place where adversaries search for such information. mitigations: diff --git a/content/oscar/techniques/T0194 - Outdated software components.yaml b/content/oscar/techniques/T0194 - Outdated software components.yaml index c08d0d5..fc01eb0 100644 --- a/content/oscar/techniques/T0194 - Outdated software components.yaml +++ b/content/oscar/techniques/T0194 - Outdated software components.yaml @@ -12,9 +12,9 @@ realm: summary: Outdated software components description: | - Outdated software compoenents can impact various aspects of security. - The obvious one is, of course, outdated software usually means unpatched vulnerabilties. - But it also means that in case of an incident it will be harder for an organization to react and patch becuase it has higher risk of breaking functionality. + Outdated software components can impact various aspects of security. + The obvious one is, of course, outdated software usually means unpatched vulnerabilities. + But it also means that in case of an incident it will be harder for an organization to react and patch because it has higher risk of breaking functionality. mitigations: - M1500 diff --git a/content/oscar/techniques/T0198 - Malicious Build Time Dependencies.yaml b/content/oscar/techniques/T0198 - Malicious Build Time Dependencies.yaml index 757cee3..62d3750 100644 --- a/content/oscar/techniques/T0198 - Malicious Build Time Dependencies.yaml +++ b/content/oscar/techniques/T0198 - Malicious Build Time Dependencies.yaml @@ -11,7 +11,7 @@ realm: summary: Malicious Build Time Dependencies description: | - Within the CI/CD workflow, code can be pushed at different stages. During the build process, plugins are often utilized for tasks like building and testing. However, if a third-party plugin is compromised, malicious code can be introduced. For instance, an attacker gains control over a Maven plugin (a popular build framework) and injectx malware during the build process. SBOM tools may not be effective in detecting such scenarios as they primarily operate on source code. + Within the CI/CD workflow, code can be pushed at different stages. During the build process, plugins are often utilized for tasks like building and testing. However, if a third-party plugin is compromised, malicious code can be introduced. For instance, an attacker gains control over a Maven plugin (a popular build framework) and inject malware during the build process. SBOM tools may not be effective in detecting such scenarios as they primarily operate on source code. mitigations: - diff --git a/content/templates/detection.yaml b/content/templates/detection.yaml index af22cf5..da1c96d 100644 --- a/content/templates/detection.yaml +++ b/content/templates/detection.yaml @@ -16,29 +16,29 @@ ## TEMPLATE ## -id: # Defintion: Identifier of the detection | Requirement Level: MUST | Type: String | Structure: D____ | Example: D1002 +id: # Definition: Identifier of the detection | Requirement Level: MUST | Type: String | Structure: D____ | Example: D1002 type: Detection -summary: # Defintion: Summary of the detection | Requirement Level: MUST | Type: String | Example: Reconnaissance -description: # Defintion: Longer description of the detection | Requirement Level: MAY | Type: LongText | Example: The adversary is trying to gather information they can use to plan future operations -process: # Defintion: The process for implmeneting the detection | Requirement Level: MAY | Type: String - - prerequisites: # Defintion: aggregation cluster of all prerequisites for the implementation of the detection | Requirement Level: MAY - - prerequisite: # Defintion: A definition of a single prerequisite - type: # Defintion: The type of the prerequisite | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: technological, environmental, procedural | Example: environmental - summary: # Defintion: Summary of the prerequisite | Requirement Level: MUST (if reference is attributed) | Type: String | Example: administrative access to the jenkins server - description: # Defintion: further description of the prerequisite | Requirement Level: MAY | Type: LongText +summary: # Definition: Summary of the detection | Requirement Level: MUST | Type: String | Example: Reconnaissance +description: # Definition: Longer description of the detection | Requirement Level: MAY | Type: LongText | Example: The adversary is trying to gather information they can use to plan future operations +process: # Definition: The process for implementing the detection | Requirement Level: MAY | Type: String + - prerequisites: # Definition: aggregation cluster of all prerequisites for the implementation of the detection | Requirement Level: MAY + - prerequisite: # Definition: A definition of a single prerequisite + type: # Definition: The type of the prerequisite | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: technological, environmental, procedural | Example: environmental + summary: # Definition: Summary of the prerequisite | Requirement Level: MUST (if reference is attributed) | Type: String | Example: administrative access to the jenkins server + description: # Definition: further description of the prerequisite | Requirement Level: MAY | Type: LongText - steps: - step: - type: # Defintion: The type of the step | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: manual, automated | Example: automated - summary: # Defintion: Summary of the step | Requirement Level: MUST (if reference is attributed) | Type: String | Example: administrative access to the jenkins server - description: # Defintion: further description of the step | Requirement Level: MAY | Type: LongText -references: # Defintion: external references to the detection | Requirement Level: MAY | Type: Array (list) + type: # Definition: The type of the step | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: manual, automated | Example: automated + summary: # Definition: Summary of the step | Requirement Level: MUST (if reference is attributed) | Type: String | Example: administrative access to the jenkins server + description: # Definition: further description of the step | Requirement Level: MAY | Type: LongText +references: # Definition: external references to the detection | Requirement Level: MAY | Type: Array (list) - reference: - type: # Defintion: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research - path: # Defintion: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/ + type: # Definition: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research + path: # Definition: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/ metadata: - state: # Defintion: release state for the detection | Requirement Level: MUST | Type: String (from options) | Options: draft, under review, released | Example: released - created: # Defintion: when the detection was created | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 - updated: # Defintion: when the detection was last updated | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 - version: # Defintion: what is the current version of the detection (each change bumps a version) | Requirement Level: MUST | Type: String | Structure: Major.Minor | Example: 1.4 - creator: # Defintion: The individual that created the record in the OSC&R system | Requirement Level: MUST | Type: String - attribution: # Defintion: who should be thanked to as a part of the contribution to OSC&R and in general | Requirement Level: MAY | Type: List \ No newline at end of file + state: # Definition: release state for the detection | Requirement Level: MUST | Type: String (from options) | Options: draft, under review, released | Example: released + created: # Definition: when the detection was created | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 + updated: # Definition: when the detection was last updated | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 + version: # Definition: what is the current version of the detection (each change bumps a version) | Requirement Level: MUST | Type: String | Structure: Major.Minor | Example: 1.4 + creator: # Definition: The individual that created the record in the OSC&R system | Requirement Level: MUST | Type: String + attribution: # Definition: who should be thanked to as a part of the contribution to OSC&R and in general | Requirement Level: MAY | Type: List \ No newline at end of file diff --git a/content/templates/mitigation.yaml b/content/templates/mitigation.yaml index d28e491..522ab3c 100644 --- a/content/templates/mitigation.yaml +++ b/content/templates/mitigation.yaml @@ -16,29 +16,29 @@ ## TEMPLATE ## -id: # Defintion: Identifier of the mitigation | Requirement Level: MUST | Type: String | Structure: D____ | Example: M10002 +id: # Definition: Identifier of the mitigation | Requirement Level: MUST | Type: String | Structure: D____ | Example: M10002 type: mitigation -summary: # Defintion: Summary of the mitigation | Requirement Level: MUST | Type: String | Example: Reconnaissance -description: # Defintion: Longer description of the mitigation | Requirement Level: MAY | Type: LongText | Example: The adversary is trying to gather information they can use to plan future operations -process: # Defintion: The process for implmeneting the mitigation | Requirement Level: MAY | Type: String - - prerequisites: # Defintion: aggregation cluster of all prerequisites for the implementation of the mitigation | Requirement Level: MAY - - prerequisite: # Defintion: A definition of a single prerequisite - type: # Defintion: The type of the prerequisite | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: technological, environmental, procedural | Example: environmental - summary: # Defintion: Summary of the prerequisite | Requirement Level: MUST (if reference is attributed) | Type: String | Example: administrative access to the jenkins server - description: # Defintion: further description of the prerequisite | Requirement Level: MAY | Type: LongText +summary: # Definition: Summary of the mitigation | Requirement Level: MUST | Type: String | Example: Reconnaissance +description: # Definition: Longer description of the mitigation | Requirement Level: MAY | Type: LongText | Example: The adversary is trying to gather information they can use to plan future operations +process: # Definition: The process for implementing the mitigation | Requirement Level: MAY | Type: String + - prerequisites: # Definition: aggregation cluster of all prerequisites for the implementation of the mitigation | Requirement Level: MAY + - prerequisite: # Definition: A definition of a single prerequisite + type: # Definition: The type of the prerequisite | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: technological, environmental, procedural | Example: environmental + summary: # Definition: Summary of the prerequisite | Requirement Level: MUST (if reference is attributed) | Type: String | Example: administrative access to the jenkins server + description: # Definition: further description of the prerequisite | Requirement Level: MAY | Type: LongText - steps: - step: - type: # Defintion: The type of the step | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: manual, automated | Example: automated - summary: # Defintion: Summary of the step | Requirement Level: MUST (if reference is attributed) | Type: String | Example: administrative access to the jenkins server - description: # Defintion: further description of the step | Requirement Level: MAY | Type: LongText -references: # Defintion: external references to the mitigation | Requirement Level: MAY | Type: Array (list) + type: # Definition: The type of the step | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: manual, automated | Example: automated + summary: # Definition: Summary of the step | Requirement Level: MUST (if reference is attributed) | Type: String | Example: administrative access to the jenkins server + description: # Definition: further description of the step | Requirement Level: MAY | Type: LongText +references: # Definition: external references to the mitigation | Requirement Level: MAY | Type: Array (list) - reference: - type: # Defintion: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research - path: # Defintion: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/ + type: # Definition: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research + path: # Definition: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/ metadata: - state: # Defintion: release state for the mitigation | Requirement Level: MUST | Type: String (from options) | Options: draft, under review, released | Example: released - created: # Defintion: when the mitigation was created | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 - updated: # Defintion: when the mitigation was last updated | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 - version: # Defintion: what is the current version of the mitigation (each change bumps a version) | Requirement Level: MUST | Type: String | Structure: Major.Minor | Example: 1.4 - creator: # Defintion: The individual that created the record in the OSC&R system | Requirement Level: MUST | Type: String - attribution: # Defintion: who should be thanked to as a part of the contribution to OSC&R and in general | Requirement Level: MAY | Type: List + state: # Definition: release state for the mitigation | Requirement Level: MUST | Type: String (from options) | Options: draft, under review, released | Example: released + created: # Definition: when the mitigation was created | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 + updated: # Definition: when the mitigation was last updated | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 + version: # Definition: what is the current version of the mitigation (each change bumps a version) | Requirement Level: MUST | Type: String | Structure: Major.Minor | Example: 1.4 + creator: # Definition: The individual that created the record in the OSC&R system | Requirement Level: MUST | Type: String + attribution: # Definition: who should be thanked to as a part of the contribution to OSC&R and in general | Requirement Level: MAY | Type: List diff --git a/content/templates/procedure.yaml b/content/templates/procedure.yaml index c4046ec..f835822 100644 --- a/content/templates/procedure.yaml +++ b/content/templates/procedure.yaml @@ -16,25 +16,25 @@ ## TEMPLATE ## -id: # Defintion: Identifier of the procedure | Requirement Level: MUST | Type: String | Structure: P____ | Example: P10032 +id: # Definition: Identifier of the procedure | Requirement Level: MUST | Type: String | Structure: P____ | Example: P10032 type: Procedure -summary: # Defintion: Summary of the procedure | Requirement Level: MUST | Type: String | Example: CodeCov attack -description: # Defintion: Longer description of the procedure | Requirement Level: MAY | Type: LongText | Example: The adversary is trying to gather information they can use to plan future operations -attacking.group: # Defintion: The name of the attacking group if known | Requirement Level: MAY | Type: LongText | Example: The adversary is trying to gather information they can use to plan future operations -procedure: # Defintion: The description of the process for enabling the attack | Requirement Level: MUST | Type: String | Notes: Please note this is read in a sequential, thus ensure the logical flow of the steps aligns with the chronology of the attack. +summary: # Definition: Summary of the procedure | Requirement Level: MUST | Type: String | Example: CodeCov attack +description: # Definition: Longer description of the procedure | Requirement Level: MAY | Type: LongText | Example: The adversary is trying to gather information they can use to plan future operations +attacking.group: # Definition: The name of the attacking group if known | Requirement Level: MAY | Type: LongText | Example: The adversary is trying to gather information they can use to plan future operations +procedure: # Definition: The description of the process for enabling the attack | Requirement Level: MUST | Type: String | Notes: Please note this is read in a sequential, thus ensure the logical flow of the steps aligns with the chronology of the attack. - step: - id: # Defintion: Identifier of the TECHQNIUE that had been used | Requirement Level: MUST | Type: String | Example: T10065 - summary: # Defintion: Summary how the specific technique had been used in the context of the procedure | Requirement Level: MUST | Type: String | Example: The attackers were able to take ownership of an open source library - description: # Defintion: further description of the way the attackers used the technique | Requirement Level: MAY | Type: LongText - outcome: # Defintion: what happened after the attackers succeeded in executing on the technique | Requirement Level: MUST | Type: String | Example: The attacks had the ability to inject malicious code into the target organization's software -references: # Defintion: external references to the procedure | Requirement Level: MAY | Type: Array (list) + id: # Definition: Identifier of the TECHNIQUE that had been used | Requirement Level: MUST | Type: String | Example: T10065 + summary: # Definition: Summary how the specific technique had been used in the context of the procedure | Requirement Level: MUST | Type: String | Example: The attackers were able to take ownership of an open source library + description: # Definition: further description of the way the attackers used the technique | Requirement Level: MAY | Type: LongText + outcome: # Definition: what happened after the attackers succeeded in executing on the technique | Requirement Level: MUST | Type: String | Example: The attacks had the ability to inject malicious code into the target organization's software +references: # Definition: external references to the procedure | Requirement Level: MAY | Type: Array (list) - reference: - type: # Defintion: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research - path: # Defintion: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/ + type: # Definition: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research + path: # Definition: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/ metadata: - state: # Defintion: release state for the procedure | Requirement Level: MUST | Type: String (from options) | Options: draft, under review, released | Example: released - created: # Defintion: when the procedure was created | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 - updated: # Defintion: when the procedure was last updated | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 - version: # Defintion: what is the current version of the procedure (each change bumps a version) | Requirement Level: MUST | Type: String | Structure: Major.Minor | Example: 1.4 - creator: # Defintion: The individual that created the record in the OSC&R system | Requirement Level: MUST | Type: String - attribution: # Defintion: who should be thanked to as a part of the contribution to OSC&R and in general | Requirement Level: MAY | Type: List \ No newline at end of file + state: # Definition: release state for the procedure | Requirement Level: MUST | Type: String (from options) | Options: draft, under review, released | Example: released + created: # Definition: when the procedure was created | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 + updated: # Definition: when the procedure was last updated | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 + version: # Definition: what is the current version of the procedure (each change bumps a version) | Requirement Level: MUST | Type: String | Structure: Major.Minor | Example: 1.4 + creator: # Definition: The individual that created the record in the OSC&R system | Requirement Level: MUST | Type: String + attribution: # Definition: who should be thanked to as a part of the contribution to OSC&R and in general | Requirement Level: MAY | Type: List \ No newline at end of file diff --git a/content/templates/realm.yaml b/content/templates/realm.yaml index 2ef91aa..5d04a85 100644 --- a/content/templates/realm.yaml +++ b/content/templates/realm.yaml @@ -14,18 +14,18 @@ # - The ID should be serialized and counting up from the last ID in the system. If you are unsure as for the correct ID to use, consult with other contributors or the project maintainers before making changes -id: # Defintion: Identifier of the realm | Requirement Level: MUST | Type: String | Structure: R____ | Example: R1123 +id: # Definition: Identifier of the realm | Requirement Level: MUST | Type: String | Structure: R____ | Example: R1123 type: Realm -summary: # Defintion: Summary of the realm | Requirement Level: MUST | Type: String | Example: The adversary is trying to gather information they can use to plan future operations -description: # Defintion: Longer description of the realm | Requirement Level: MAY | Type: LongText -references: # Defintion: external references to the realm | Requirement Level: MAY | Type: Array (list) +summary: # Definition: Summary of the realm | Requirement Level: MUST | Type: String | Example: The adversary is trying to gather information they can use to plan future operations +description: # Definition: Longer description of the realm | Requirement Level: MAY | Type: LongText +references: # Definition: external references to the realm | Requirement Level: MAY | Type: Array (list) - reference: - type: # Defintion: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research - path: # Defintion: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/technique + type: # Definition: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research + path: # Definition: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/technique metadata: - state: # Defintion: release state for the realm | Requirement Level: MUST | Type: String (from options) | Options: draft, under review, released | Example: released - created: # Defintion: when the realm was created | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 - updated: # Defintion: when the realm was last updated | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 - version: # Defintion: what is the current version of the realm (each change bumps a version) | Requirement Level: MUST | Type: String | Structure: Major.Minor | Example: 1.4 - creator: # Defintion: The individual that created the record in the OSC&R system | Requirement Level: MUST | Type: String - attribution: # Defintion: who should be thanked to as a part of the contribution to OSC&R and in general | Requirement Level: MAY | Type: List \ No newline at end of file + state: # Definition: release state for the realm | Requirement Level: MUST | Type: String (from options) | Options: draft, under review, released | Example: released + created: # Definition: when the realm was created | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 + updated: # Definition: when the realm was last updated | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 + version: # Definition: what is the current version of the realm (each change bumps a version) | Requirement Level: MUST | Type: String | Structure: Major.Minor | Example: 1.4 + creator: # Definition: The individual that created the record in the OSC&R system | Requirement Level: MUST | Type: String + attribution: # Definition: who should be thanked to as a part of the contribution to OSC&R and in general | Requirement Level: MAY | Type: List \ No newline at end of file diff --git a/content/templates/stories/AS1 - Webmin 1.900 RCE.yaml b/content/templates/stories/AS1 - Webmin 1.900 RCE.yaml index 3e3f682..8b8a002 100644 --- a/content/templates/stories/AS1 - Webmin 1.900 RCE.yaml +++ b/content/templates/stories/AS1 - Webmin 1.900 RCE.yaml @@ -7,7 +7,7 @@ description: | Webmin is a popular server administration software. Webmin version 1.890 was released with a backdoor that could allow anyone with knowledge of it to execute commands as root. Versions 1.900 to 1.920 also contained a backdoor using similar code, but it was not exploitable in a default Webmin install. Only if the admin had enabled the feature at Webmin ⇾ Webmin Configuration ⇾ Authentication to allow changing of expired passwords could it be used by an attacker. Neither of these were accidental bugs - rather, the Webmin source code had been maliciously modified to add a non-obvious vulnerability. -# Techinques used in attack +# Techniques used in attack attacks: - attack: Webmin index: 1 @@ -22,7 +22,7 @@ attacks: - techid: T0191 - techname: Malicious Code In Artifacts - tactic: Impact - - comment: The attackers infected the webmin code with a backdoor that allowed remote code execution. + - comment: The attackers infected the Webmin code with a backdoor that allowed remote code execution. - technique: - id: T0135 - tactic: Initial Access @@ -34,8 +34,8 @@ attacks: - tactic: Initial Access - title: Outdated Software Components - comment: | - The webmin build server was apparently exploitable and the attackers used this to repeat the attack. - *"On September 10th 2018, the vulnerable build server was decomissioned and replaced with a newly installed server running CentOS 7. However, the build directory containing the modified file was copied across from backups made on the original server."* + The Webmin build server was apparently exploitable and the attackers used this to repeat the attack. + "On September 10th 2018, the vulnerable build server was decommissioned and replaced with a newly installed server running CentOS 7. However, the build directory containing the modified file was copied across from backups made on the original server." - attack: Webmin Customers index: 2 diff --git a/content/templates/tactic.yaml b/content/templates/tactic.yaml index aa2e823..a2ed29a 100644 --- a/content/templates/tactic.yaml +++ b/content/templates/tactic.yaml @@ -14,18 +14,18 @@ # - The ID should be serialized and counting up from the last ID in the system. If you are unsure as for the correct ID to use, consult with other contributors or the project maintainers before making changes -id: # Defintion: Identifier of the tactic | Requirement Level: MUST | Type: String | Structure: TA____ | Example: TA1123 +id: # Definition: Identifier of the tactic | Requirement Level: MUST | Type: String | Structure: TA____ | Example: TA1123 type: Tactic -summary: # Defintion: Summary of the tactic | Requirement Level: MUST | Type: String | Example: The adversary is trying to gather information they can use to plan future operations -description: # Defintion: Longer description of the tactic | Requirement Level: MAY | Type: LongText -references: # Defintion: external references to the tactic | Requirement Level: MAY | Type: Array (list) +summary: # Definition: Summary of the tactic | Requirement Level: MUST | Type: String | Example: The adversary is trying to gather information they can use to plan future operations +description: # Definition: Longer description of the tactic | Requirement Level: MAY | Type: LongText +references: # Definition: external references to the tactic | Requirement Level: MAY | Type: Array (list) - reference: - type: # Defintion: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research - path: # Defintion: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/technique + type: # Definition: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research + path: # Definition: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/technique metadata: - state: # Defintion: release state for the tactic | Requirement Level: MUST | Type: String (from options) | Options: draft, under review, released | Example: released - created: # Defintion: when the tactic was created | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 - updated: # Defintion: when the tactic was last updated | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 - version: # Defintion: what is the current version of the tactic (each change bumps a version) | Requirement Level: MUST | Type: String | Structure: Major.Minor | Example: 1.4 - creator: # Defintion: The individual that created the record in the OSC&R system | Requirement Level: MUST | Type: String - attribution: # Defintion: who should be thanked to as a part of the contribution to OSC&R and in general | Requirement Level: MAY | Type: List \ No newline at end of file + state: # Definition: release state for the tactic | Requirement Level: MUST | Type: String (from options) | Options: draft, under review, released | Example: released + created: # Definition: when the tactic was created | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 + updated: # Definition: when the tactic was last updated | Requirement Level: MUST | Type: date/time (ISO 8601) | Example: 2023-03-05T16:31:51+00:00 + version: # Definition: what is the current version of the tactic (each change bumps a version) | Requirement Level: MUST | Type: String | Structure: Major.Minor | Example: 1.4 + creator: # Definition: The individual that created the record in the OSC&R system | Requirement Level: MUST | Type: String + attribution: # Definition: who should be thanked to as a part of the contribution to OSC&R and in general | Requirement Level: MAY | Type: List \ No newline at end of file diff --git a/content/templates/technique.yaml b/content/templates/technique.yaml index 0a915cb..52ab3ac 100644 --- a/content/templates/technique.yaml +++ b/content/templates/technique.yaml @@ -15,22 +15,22 @@ -id: # Defintion: Identifier of the technique | Requirement Level: MUST | Type: String | Structure: T____ | Example: T1123 +id: # Definition: Identifier of the technique | Requirement Level: MUST | Type: String | Structure: T____ | Example: T1123 type: Technique -tactic: # Defintion: The identifier (ID) of the tactic associated with the technique. The tactic definition must be referenced to the pre-defined tactics. | Requirement Level: MUST | Type: String | Example: TA1002 -realm: # Defintion: The identifiers (ID) of relams associated with the technique. The realms definition must be referenced to the pre-defined relams. | Requirement Level: MUST | Type: Array | Example: R1004, R1006 -summary: # Defintion: Summary of the technique | Requirement Level: MUST | Type: String | Example: Abuse of CI/CD access rights -description: # Defintion: Longer description of the technique | Requirement Level: SHOULD | Type: LongText -detections: # Defintion: The identifier (ID) of the detections associated with the technique. Must be referenced to the pre-defined detections; If a new detection is required, please create the detection as a part of the commit and reference it. | Requirement Level: MAY | Type: String | Example: D1022 -mitigations: # Defintion: The identifier (ID) of the mitigations associated with the technique. Must be referenced to the pre-defined mitigations; If a new mitigation is required, please create the mitigation as a part of the commit and reference it. | Requirement Level: MAY | Type: String | Example: M1012 -subtechinques: # Defintion: The identifier (ID) of the subtechnique associated with the technique. Must be referenced to the pre-defined subtechniques; If a new subtecnique is required, please create the mitigation as a part of the commit and reference it. | Requirement Level: MAY | Type: String | Example: M1012 -references: # Defintion: external references to the technique | Requirement Level: MAY | Type: Array (list) +tactic: # Definition: The identifier (ID) of the tactic associated with the technique. The tactic definition must be referenced to the pre-defined tactics. | Requirement Level: MUST | Type: String | Example: TA1002 +realm: # Definition: The identifiers (ID) of realms associated with the technique. The realms definition must be referenced to the pre-defined realms. | Requirement Level: MUST | Type: Array | Example: R1004, R1006 +summary: # Definition: Summary of the technique | Requirement Level: MUST | Type: String | Example: Abuse of CI/CD access rights +description: # Definition: Longer description of the technique | Requirement Level: SHOULD | Type: LongText +detections: # Definition: The identifier (ID) of the detections associated with the technique. Must be referenced to the pre-defined detections; If a new detection is required, please create the detection as a part of the commit and reference it. | Requirement Level: MAY | Type: String | Example: D1022 +mitigations: # Definition: The identifier (ID) of the mitigations associated with the technique. Must be referenced to the pre-defined mitigations; If a new mitigation is required, please create the mitigation as a part of the commit and reference it. | Requirement Level: MAY | Type: String | Example: M1012 +subTechniques: # Definition: The identifier (ID) of the subTechnique associated with the technique. Must be referenced to the pre-defined sub-techniques; If a new sub-technique is required, please create the mitigation as a part of the commit and reference it. | Requirement Level: MAY | Type: String | Example: M1012 +references: # Definition: external references to the technique | Requirement Level: MAY | Type: Array (list) - reference: - type: # Defintion: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research - path: # Defintion: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/ + type: # Definition: The type of the reference | Requirement Level: MUST (if reference is attributed) | Type: String (with options) | Options: web.article,research,payload | Example: research + path: # Definition: link to the reference | Requirement Level: MUST (if reference is attributed) | Type: String | Example: https://www.bleepingcomputer.com/news/security/lastpass-devops-engineer-hacked-to-steal-password-vault-data-in-2022-breach/ ======= # Guidelines -# It is recommended to append the techinque name to the filename - ex T1111: A very cool technique.yaml +# It is recommended to append the technique name to the filename - ex T1111: A very cool technique.yaml # We support markdown in description. Use pipe for multiline descriptions @@ -65,10 +65,12 @@ description: # REQUIRED - - supports markdown mitigations: # REQUIRED - -reference to mitigation references - -detections: # REQUIRED - - reference to detection defintitions - - -subtechinques: # OPTIONAL - reference to TechIDs + +detections: # REQUIRED - - reference to detection definitions + - + +subTechniques: # OPTIONAL - reference to techniqueIDs - -references: # OPTIONAL - reference to attacks, articals, blogs etc... +references: # OPTIONAL - reference to attacks, articles, blogs etc... - \ No newline at end of file