venus/blog
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

basic webhook tested

Browse Source
This commit is contained in:
venus
2026-03-05 01:24:40 -06:00
parent ebb6aa0f56
commit f6f192da26
2 changed files with 297 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

296
content/Malware.md Normal file
View File

@@ -0,0 +1,296 @@
#public
# Malware/malicious software
- **Malware**: software written with intent to do HARM
```mermaid
flowchart TD
A[Data] <---> B[People]
A <---> C[Devices]
B <---> C
```
> Greatest Vulnerability is People
## Malware types
- **virus:** program to modify other programs
- **Worm**: program that spreads itself
> diff b/t virus and worm is method of movement
- **Trojan**: an innocent program that hides malware inside
- **Ransomware**: require payment to remove (often in exchange for decryption key)
- **Phishing**: Faking identity in order to build trust to encourage specific user behavior
- **DOS/DDOS**: (distributed) denial of service to overwhelm services and prevent legitimate activity from getting through
# Threat Actors
| Group | Motivations |
| ---------------- | -------------------------------------------------------- |
| Nation States | Intelligence Infrastructure |
| Groups of people | Intimidate, org-goals |
| Individuals | ego, \$\$\$, etc |
| Insider Threats | Those inside of an organization who abuse trusted access |
>Insider Threats are the Greatest challenge in cyber-sec
> There is an upward trend in the amount of malware and damage done in USD. 5 month avg for identifying breaches
# CIA TRIAD
```mermaid
flowchart TD
A[Confidentiality] <---> B[Integrity]
A <---> C[Accessibility]
B <---> C
````
True security manages all 3, our job is to find the right balance
## CONFIDENTIALITY
Ensuring that only authorized users can access data
### 3 Types of confidentiality
| type | definition | exampe | |
| --------------- | -------------------------------------------------------------------------- | ------------------------- | --- |
| Confidentiality | limiting access to information including the existence of such information | "What conversation" | |
| Privacy | Limit the information shared | Not giving away PII | |
| Secrecy | Data not to be shared beyond small circle | Restricting access to PII | |
- **PII**: personally identifiable information
## INTEGRITY
Ensure data and system resources are trustworthy
Trustworthy: known author, not maliciously modified
| Catagory | definition |
| --- | --- |
| Data integrity | Data has not been modified or overwritten |
| Origin Integrity | maintaining the authorship and chain of editors |
| System integrity | overall design of processes that work with data |
> While confidentiality is often considered the "Traditional" focus of security, Integrity can be considred just as important
## AVAILABILITY
Authorized users can access data and systems when needed.
Confilicts directly with Confidentiality, this balance is our job.
DDOS/DOS attacks affect availibility.
> "If one person can have access, many have access"
# What is security?
> Just fire-walling/encrypting your system $\neq$ security
**Security is a systems issue**, good security is a heuristic endeavor encompassing the following questions:
1. What are we protecting?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good job?
You need to deal with policy and procedure. E.G. talking to non-tech savvy people or encouraging more scrutiny of strange emails
- **Forensics:** determine what was done when
```mermaid
mindmap
id))system((
id(Hardware(
id(Software(
id)networking(
```
# The Five As
| [[Malware#Authentication]] | Verification of a user's Identity | static password |
| ------------------------ | -------------------------------------------- | ------------------------- |
| Access control | control who is allowed access to something | ACT card |
| [[Malware#Accounting]] | keeping track of activity | logs of command history |
| [[Malware#Auditing]] | checking for suspicious behavior or failures | log analysis |
| Action | taking action on a threat | changing a users password |
## Authentication
> How do we know who you say you are? j do we know you're authorized?
### 3 mechanism of authentication:
| something you **know** | Static username and passwd |
| ---------------------- | -------------------------------------------------------------------- |
| something you **have** | one time password (OTP) --> usually **2nd device** as authentication |
| something you **are** | Biometric credential |
## Accounting
- cant have $\infty$ storage, so what do you keep?
## Auditing
You need to know your system is compromised if you're taksed to protect it.
"Did something happen?"
This is looking at logs created and making policies to take action of some kind
you also need to determine the action to take
# measures and countermeasures
| prevention | measures to **stop breaches** | Gaurd at the gate, strong authentication policy | |
| ---------- | --------------------------------- | ----------------------------------------------- | --- |
| detection | measures to **detect breaches** | beggining, ongoing, or afterwords | |
| Reaction | measures to **recover of assets** | Rebuild, Repair, Pursue | |
```mermaid
flowchart TB
id1[Passwords are easy to guess] --> id2[Password policies] --> id3[Users write down passwds] --> id4[etc]
```
# Insider threats
- **Threat**: An event of condition that has the potential to cause loss or undesirable consequences
- **Insider Threat**: threat caused by someone inside of the organization
- Disgruntled employee
- Careless employee
| |IT sabatoge| Theft of IP | Fraud | Espionage |
| --- | --- | --- | --- | --- |
| WHO | techinal/priveleged access | scientists, programmers, engineers, sales | fincacial pros, low/mid developers, customer service | anybody |
| WHEN | on/before termination | ~60 days b4 leaving | Long period of time | long period of time |
| WHY | revenge | new job, start company | Greed, financial need | dissatisfaction, greed, financial need |
## Identifying Insider Threats:
- Who has the most access?
> Don't assume sysadmin is the villan, just be aware of their access level
- become the insider. "Think like the attacker"
- most employees dont join to become insiders
## Lifecycle of an insider
1. Recruitment/tipping point
2. Search/Reconnisance
3. Acquisition/collection
4. Exfiltration/Action
# Threat Modeling
> The equifax breach exploited a known vulnerability that equifax didn't patch for months. $1.4 Billion in damages
## The fundamental security problem
There are more attacks than can be reasonably stopped with limited time/money
## Why threat model
- Proactive vs Reactive
- Prioritization
- Systematic approach
- Find problem's you'd otherwise miss
- Legal compliance
## The cost of a vulnerability
![[Diagram 2.svg]]
## What is threat modeling?
A structured process to identify, quantify, and address security risks in a system or process
## Key Questions
1. What are we protecting
2. What can go wrong
3. What are we going to do about it
4. did we do a good job
## Steps
### 1. define scopes and assets
### 2. Create architecture diagram
- Data flow
- Network diagram
- Component diagram
- Trust breakdown diagram
### 3. Identify threats
| S | spoofing Identity |
| --- | --- |
| T | Tampering with data |
| R | Repudation |
| I | Information disclosure |
| D | Denial of servie |
| E | Escalation of privelege |
> [[Malware#CIA Triad]]
### 4. Rank and prioritize threats
#### DREAD
on a scale of 1 - 10
Risk = (D+R+E+A+D)/5
| D | Damage potential |
| --- | --- |
| R | Reproducability |
| E | Exploitability |
| A | Affected Users |
| D | Discoverability |
Ex: Mybama SQLI
| D | 10 |
| --- | --- |
| R | 10 |
| E | 7 |
| A | 10 |
| D | 8 |
R 9 = (10 + 10 + 7 + 10 + 8) / 5
9 is a **Critical threat**
#### Impact/likelyhood table
| likelyhood | low | med | high |
| ---------- | --- | --- | ---- |
| low | 1 | 2 | 3 |
| med | 2 | 4 | 6 |
| high | 3 | 6 | 9 |
| < 3 | < 6 | 9 |
| --- | --- |---|
| low, fix when possible | Vulnerable. Fix ASAP | HUGE PROBLEM |
### 5. Determine Mitigation
1. **Eliminate**: remove the vuln --> unused admin page
2. **Mitigate**: Reduce likelihood of attack --> Sanitize SQL inputs
3. **Transfer**: Move to somewhere else --> send it to your SSO
4. **Accept**: It's good enough --> password logins (using microsoft)
## Why it works:
1. Systematic, not random
2. Visual
3. Collaborative
4. Proactive
5. Prioritized
6. Documented
# Encryption
## Symmetric V. Asymmetric
- **Symmetric encryption**: Uses a single key
- **Asymmetric encryption**: Uses two keys
```mermaid
stateDiagram-v2
state symmetric{
plaintext
}
state asymmetric{
text
key
}
text --> encryption
key --> encryption
encryption --> cyphertext
plaintext --> encryption
cyphertext --> decryption
decryption --> Plaintext
```
### Asymmetric key encryption
> Asymmetric has 2 keys and is more computationally expensive
takes 2 keys, and runs the encryption algo on the combined input
1 is the private key, one is the public
how do you securely send the keys?
### Symmetric key encryption
Cheaper, older and more common
> Block cipher
- **DES**: Data Encryption Standard
- Oldest standard
- originally labbeled by NIST
- **AES**: Advanced Encryption Standard
- updated DES, more computationally signifigant for modern computing
- **3DES**: 3 Data Encryption Standard
- does DES 3 times
- **TLS**: Transport Layer security
- for high level web traffic
- **SSL**: Secure Socket layer
- for secure communication between machine
## Feistel block cipher
Takes initial input, splits in half, encrypts left half, and switches. Repeats
The key is used in encryption through a reversable algorithm.
![[Pasted image 20260217083518.png]]
## Diffie Heiman Key exchange
Symmetric means you have to pass around the key,
Asymmetric is computationally expensive
Diffie-Heiman is a solution
1. Publish your public key
2. Send hash function with any work you then publish
3. Your public key can be used to verify integrety of any published work
3a. verifying file downloads
3b. git commits
You can aslo force 1-way encryption with a block cipher so:
data --> hash
but not:
hash --> data
any slight change of input, dramatically changes output (Avalance effect)
> since encryption methods take any size and hash it to a fixed size, collisions are possible. Furthermore, Collisions are going to be vastly different inputs
## Hash functions
- Md5
- Sha1
- Sha3
- Sha256
- RSA