Posted by:

David Greenwood, Chief of Signal

If you are reading this blog post via a 3rd party source it is very likely that many parts of it will not render correctly. Please view the post on signalscorps.com for the full interactive viewing experience.

In this post I will show you some of my experiments using GPT to generation detection rules.

It has been over six months since my last posts on using OpenAI to;

• Extract threat intelligence from unstructured text reports
• Using OpenAI training data to enrich existing intelligence with more context
• Automating the workflows using the OpenAI API

Since then we’ve seen the introduction of GPT-4 (currently in beta).

In the intervening period I’ve also had many emails sent to me with people detailing how they’ve authored detection rules using ChatGPT. Of course, I had to have a go myself.

IOC (observable) based detections

Part 1 showed a basic analysis of malware using the information available, here it is again for reference;

Here we have domains pointing to IPs all of which are likely suspected of hosting the Turian malware between July 7, 2022 to Oct. 11, 2022.

Sticking with STIX for now, lets see how GPT-3.5 can handle writing STIX 2.1 patterns.

Input:

Please create a STIX 2.1 Indicator SDO containing a STIX pattern for the following information.

1. IP address: 151.248.24.251
   • Contains a historical certificate reference to portal-Share.mfa.new
   • Suggests an ambiguous “Ministry of Foreign Affairs (MFA)” nexus
   • STIX 2.1 Domain Object: ipv4-addr
2. IP address: 158.247.222.6
   • Virtual Private Server (VPS) owned by The Constant Company
   • Hosted the domain www.delldrivers.in from July 7, 2022 to Oct. 11, 2022
   • Associated with a Turian backdoor sample
   • STIX 2.1 Domain Object: ipv4-addr
3. Domain: portal-Share.mfa.new
   • Contains a historical certificate reference
   • Suggests an ambiguous “Ministry of Foreign Affairs (MFA)” nexus
   • STIX 2.1 Domain Object: domain-name
4. Domain: www.delldrivers.in
   • Hosted on the IP address 158.247.222.6
   • Associated with a Turian backdoor sample
   • STIX 2.1 Domain Object: domain-name
5. Malware: Turian
   • Associated with the IP address 158.247.222.6
   • STIX 2.1 Cyber-observable Object: malware

Output:

Here is a STIX 2.1 Indicator SDO containing a STIX pattern for the provided information:

{
    "type": "indicator",
    "spec_version": "2.1",
    "id": "indicator--11111111-2222-3333-4444-555555555555",
    "created": "2023-04-03T00:00:00.000Z",
    "modified": "2023-04-03T00:00:00.000Z",
    "name": "Potential Ministry of Foreign Affairs (MFA) cyber threat",
    "description": "This indicator suggests a potential nexus to the Ministry of Foreign Affairs (MFA) based on the historical certificate references and other associated information.",
    "labels": [
        "threat-actor"
    ],
    "pattern": "([ipv4-addr:value = '151.248.24.251'] AND [ipv4-addr:extensions.'certificate-fingerprint'.sha256 = 'portal-Share.mfa.new']) OR ([ipv4-addr:value = '158.247.222.6'] AND [domain-name:value = 'www.delldrivers.in'] AND [malware:name = 'Turian']) OR ([domain-name:value = 'portal-Share.mfa.new'] AND [domain-name:extensions.'certificate-fingerprint'.sha256 = ''])",
    "valid_from": "2023-04-03T00:00:00.000Z",
    "pattern_type": "stix",
    "pattern_version": "2.1",
    "indicator_types": [
        "malicious-activity"
    ],
    "kill_chain_phases": [
        {
            "kill_chain_name": "lockheed-martin-cyber-kill-chain",
            "phase_name": "command-and-control"
        }
    ]
}

In this STIX 2.1 Indicator SDO, the pattern is composed of several parts that represent the different pieces of information provided. The pattern uses STIX query language syntax to express the conditions that would indicate potential malicious activity.

The STIX 2.1 Indicator SDO contains a STIX pattern that identifies three potential indicators of malicious activity:

1. The first part of the pattern looks for an IPv4 address (151.248.24.251) that contains a historical certificate reference to the domain portal-Share.mfa.new, which suggests a potential nexus to the Ministry of Foreign Affairs (MFA).
2. The second part of the pattern looks for an IPv4 address (158.247.222.6) that hosted the domain www.delldrivers.in from July 7, 2022 to Oct. 11, 2022, and is associated with a Turian backdoor sample.
3. The third part of the pattern looks for the domain portal-Share.mfa.new, which contains a historical certificate reference and suggests a potential nexus to the Ministry of Foreign Affairs (MFA).

The STIX 2.1 Indicator SDO also includes other fields that provide additional context and metadata about the indicator, such as a name, description, labels, and kill chain phases.

Review

Very good! I like the determination of the kill_chain_phases.

Let’s start with the STIX 2.1 pattern;

    "pattern": "([ipv4-addr:value = '151.248.24.251'] AND [ipv4-addr:extensions.'certificate-fingerprint'.sha256 = 'portal-Share.mfa.new']) OR ([ipv4-addr:value = '158.247.222.6'] AND [domain-name:value = 'www.delldrivers.in'] AND [malware:name = 'Turian']) OR ([domain-name:value = 'portal-Share.mfa.new'] AND [domain-name:extensions.'certificate-fingerprint'.sha256 = ''])",

Broken apart

([ipv4-addr:value = '151.248.24.251'] AND [ipv4-addr:extensions.'certificate-fingerprint'.sha256 = 'portal-Share.mfa.new'])

You might choose to use an OR comparison expression operator here, depending on whether you expect the logs to pickup both ipv4 and domain.

What’s more important though is that portal-Share.mfa.new is a domain resolving to 151.248.24.251 not a certificate-fingerprint. Although you can see how GPT became confused:

Contains a historical certificate reference to portal-Share.mfa.new

Analysing the next part;

OR ([ipv4-addr:value = '158.247.222.6'] AND [domain-name:value = 'www.delldrivers.in'] AND [malware:name = 'Turian']) 

You can’t detect on a malware (you detect on known observables or behaviour (TTPs)). Personally I’d rewrite this as;

([ipv4-addr:value = '158.247.222.6'] AND [domain-name:value = 'www.delldrivers.in'])

Finally;

OR ([domain-name:value = 'portal-Share.mfa.new'] AND [domain-name:extensions.'certificate-fingerprint'.sha256 = ''])

This part is now redundant. Searching on domain-name:extensions.'certificate-fingerprint'.sha256 = '*' (notice the addition of the wildcard), could be a useful depending on how you analyse certificates in your SOC.

Giving a final pattern;

    "pattern": "([ipv4-addr:value = '151.248.24.251'] OR [domain-name:value = 'portal-Share.mfa.new']) OR ([ipv4-addr:value = '158.247.222.6'] OR [domain-name:value = 'www.delldrivers.in'])",

Looking at the wider object and ignoring the errors seen in previous posts (e.g. incorrect UUID for the id property), there are a few key changes I would make;

Change;

• name value to “Detection: Turian Malware”
• valid_from value to 2022-07-07T00:00:00.000Z
• add malicious-activity value to indicator_types list

I’d probably add a bit more context (e.g. link to original report in external_references) but for brevity of this post I will skip over for now.

Lets get GPT to make these updates;

Input:

Thanks!

Can you please make the following four changes;

Change;

• pattern to ([ipv4-addr:value = '151.248.24.251'] OR [domain-name:value = 'portal-Share.mfa.new']) OR ([ipv4-addr:value = '158.247.222.6'] OR [domain-name:value = 'www.delldrivers.in'])
• name value to “Detection: Turian Malware”
• valid_from value to 2022-07-07T00:00:00.000Z
• add malicious-activity value to indicator_types list

And print the response.

Output:

Sure, here’s the updated STIX 2.1 Indicator SDO:

{
    "type": "indicator",
    "spec_version": "2.1",
    "id": "indicator--11111111-2222-3333-4444-555555555555",
    "created": "2023-04-03T00:00:00.000Z",
    "modified": "2023-04-03T00:00:00.000Z",
    "name": "Detection: Turian Malware",
    "description": "This indicator detects the presence of the Turian malware based on the associated IP addresses and domains.",
    "labels": [
        "threat-actor"
    ],
    "pattern": "([ipv4-addr:value = '151.248.24.251'] OR [domain-name:value = 'portal-Share.mfa.new']) OR ([ipv4-addr:value = '158.247.222.6'] OR [domain-name:value = 'www.delldrivers.in'])",
    "valid_from": "2022-07-07T00:00:00.000Z",
    "pattern_type": "stix",
    "pattern_version": "2.1",
    "indicator_types": [
        "malicious-activity"
    ],
    "kill_chain_phases": [
        {
            "kill_chain_name": "lockheed-martin-cyber-kill-chain",
            "phase_name": "command-and-control"
        }
    ]
}

In this updated STIX 2.1 Indicator SDO, the changes made are as follows:

1. The pattern field has been updated to reflect the new STIX query language syntax that includes the “OR” operator between the different conditions.
2. The name field has been updated to “Detection: Turian Malware” to more accurately reflect the purpose of the indicator.
3. The valid_from field has been updated to reflect the date when the indicator first became relevant.
4. The malicious-activity value has been added to the indicator_types list to more accurately categorize the type of activity being detected.

I hope this helps! Let me know if you have any other questions.

Review:

Whilst a STIX representation is useful for intel analysts, not a lot of SOC teams use STIX.

There are lot’s of tools that exist, notably STIX Shifter, that already convert STIX Patterns to other detection rule languages. Though can GPT replace them?

As a former Splunker, let me start there.

Input:

Please turn the STIX pattern in the previous response into a Splunk query.

Output:

Sure, here’s a Splunk query that translates the STIX pattern from the previous response:

(index=your_index_name sourcetype=your_sourcetype_name) (ipv4="151.248.24.251" OR domain="portal-Share.mfa.new") OR (ipv4="158.247.222.6" OR domain="www.delldrivers.in")

This query assumes that the data you are searching for is indexed in a Splunk instance, and that you have specified the appropriate index name and sourcetype name.

The query uses parentheses and the “OR” operator to match the different conditions in the STIX pattern. The ipv4 field is used to match the IP addresses, while the domain field is used to match the domain names.

Note that you may need to adjust the field names and values in the query to match the specific data sources and fields in your environment.

Review:

It’s a good placeholder. I especially like it has not used index=* and adds some oversight requiring the user to manually specify the index and or sourcetype.

I’d probably add the time range into query to further improve excecution effieciency.

Input:

Please also add the timerange July 7, 2022 to Oct. 11, 2022 to the query please.

Output:

Sure! Here’s the updated Splunk query that includes the time range:

(index=your_index_name sourcetype=your_sourcetype_name) (ipv4="151.248.24.251" OR domain="portal-Share.mfa.new" OR (ipv4="158.247.222.6" AND domain="www.delldrivers.in" AND _time>=1657248000 AND _time<=1665475200))

This query includes a time range filter that limits the search results to events that occurred between July 7, 2022, and Oct. 11, 2022. The time range filter is added using the _time field, which is a default field in Splunk that represents the timestamp of the event.

Note that you may need to adjust the field names and values in the query to match the specific data sources and fields in your environment. Additionally, you may need to convert the time range into Unix timestamps if your Splunk instance uses that format for time values.

Review:

What I really like here is that the timerange only considers 158.247.222.6 and www.delldrivers.in in the original report.

OR (ipv4="158.247.222.6" AND domain="www.delldrivers.in" AND _time>=1657248000 AND _time<=1665475200))

Though I’d probably use an OR again to restructure the quesry as follows;

OR ((ipv4="158.247.222.6" OR domain="www.delldrivers.in") AND (_time>=1657248000 AND _time<=1665475200))

Input:

Can you convert that to a Sigma Detection Rule please?

Output:

Sure! Here’s a Sigma detection rule that translates the Splunk query from the previous response:

title: Detection of Turian Malware
id: your_rule_id
description: Detects potential activity related to the Turian malware based on IP addresses and domains.
status: experimental
references:
    - https://your_reference1
    - https://your_reference2
author: Your Name
date: 2023-04-03
logsource:
    category: your_log_category
detection:
    selection:
        - ipv4="151.248.24.251" OR domain="portal-Share.mfa.new" OR (ipv4="158.247.222.6" AND domain="www.delldrivers.in")
    timeframe: from 2022-07-07T00:00:00+00:00 to 2022-10-11T23:59:59+00:00
falsepositives:
    - Legitimate traffic to the IP addresses and domains listed in the selection criteria.
level: high

In this Sigma detection rule, the Splunk query has been translated into a Sigma-compatible format that includes additional fields for metadata and context. The selection field contains the selection criteria, which are the same as the conditions in the Splunk query.

The timeframe field specifies the time range for the detection rule, which is the same as the time range in the Splunk query. The falsepositives field contains examples of legitimate traffic that could trigger the rule and cause a false positive.

Note that you may need to adjust the field names and values in the Sigma detection rule to match the specific data sources and fields in your environment.

Review:

Generally OK, but the key part, the detection is written incorrectly.

Jumping ahead slightly, I believe this is a result of multiple transforms (STIX to Splunk to Sigma).

I know this because I went back to the chat history from last year (the above chat so far was from a clean ChatGPT thread) and executed a similar prompt there.

Input:

Please write a Sigma detection rule for these indicators of compromise.

Output:

Here’s a Sigma detection rule for the provided indicators of compromise:

title: Suspicious IoCs Related to Turian Backdoor
status: experimental
description: Detects suspicious activity related to the Turian backdoor
author: Your Name
date: 2023-03-22
references:
    - https://example.com/research_on_turian_backdoor
logsource:
    product: network
    service: any
detection:
    selection:
        dst_ip:
            - '158.247.222.6'
        domain:
            - 'portal-Share.mfa.new'
            - 'www.delldrivers.in'
    timeframe: 2022-07-07 .. 2022-10-11
    condition: selection
falsepositives:
    - Legitimate traffic to the mentioned IPs or domains
level: high
tags:
    - attack.network
    - attack.t1043
    - attack.t1071
    - attack.t1102
    - malware.turian

Review:

It’s still not perfect, however this time around the syntax of the detections is now correct.

Personally I’d slightly tweak the detection into two selections, as I did in the previous STIX and Splunk examples.

For example;

detection:
    selection_1:
        dst_ip:
            - '158.247.222.6'
        domain:
            - 'portal-Share.mfa.new'
    selection_2:
        src_ip:
            - '151.248.24.251'
        domain:
            - 'www.delldrivers.in'
        start_time:
            - '2022-07-07'
        end_time:
            - '2022-10-11'
    condition: 1 of them

The additional context from the bundle (e.g. ATT&CK) is also included and assigned correctly as tags to the rule.

TTP based detections

So far the rules shown have been searching for atomic indicators. I don’t need to tell you that using these for detections are good, but can suffer from noise.

For example, www.delldrivers.in, might have be taken down by now. Similarly 151.248.24.251 might be hosting a legitimate site. Detecting on just these values

Alone, they also shed no light on the tools being used either.

Sigma (and other detection rules) real power is in how they enable analysts to express TTP/Behavior based detections that can be shared and implemented as easily as IOC based data.

As an example, in 2018 Palo Alto’s Unit 42](https://unit42.paloaltonetworks.com/unit42-sofacy-continues-global-attacks-wheels-new-cannon-trojan/) reported the ongoing malware activity from Sofacy (also known as APT28, Pawn Storm, Tsar Team, Fancy Bear, Sednit and Strontium).

A SIGMA Rule written by Florian Roth and Jonhnathan Ribeiro, has been available to detect malware masquerading as rundll32.exe since 2018.

title: Sofacy Trojan Loader Activity
id: ba778144-5e3d-40cf-8af9-e28fb1df1e20
status: test
description: Detects Trojan loader activity as used by APT28
references:
    - https://researchcenter.paloaltonetworks.com/2018/02/unit42-sofacy-attacks-multiple-government-entities/
    - https://www.reverse.it/sample/e3399d4802f9e6d6d539e3ae57e7ea9a54610a7c4155a6541df8e94d67af086e?environmentId=100
    - https://twitter.com/ClearskySec/status/960924755355369472
author: Florian Roth (Nextron Systems), Jonhnathan Ribeiro, oscd.community
date: 2018/03/01
modified: 2022/07/07
tags:
    - attack.g0007
    - attack.execution
    - attack.t1059.003
    - attack.defense_evasion
    - car.2013-10-002
    - attack.t1218.011
logsource:
    category: process_creation
    product: windows
detection:
    selection_cli_1:
        CommandLine|contains|all:
            - 'rundll32.exe'
            - '%APPDATA%\'
    selection_cli_2:
        - CommandLine|contains: '.dat",'
        - CommandLine|endswith:
            - '.dll",#1'
            - '.dll #1'
            - '.dll" #1'
    condition: all of selection_*
falsepositives:
    - Unknown
level: high

This rule is detecting activity on machines relating to how them malware executes.

1. the command line contains arundll32.exe AND %APPDATA%\ AND
2. the command line contains
   • dat OR
   • .dll",#1 OR .dll #1 OR .dll" #1

Knowing this, I was intrigued if I could use this information to try and generate the same Sigma rule using GPT-3;

Input:

Write a Sigma detection rule to detect Sofacy Trojan Loader Activity.

The detection behaviour is as follows;

1. the command line contains arundll32.exe AND %APPDATA%\ AND
2. the command line contains 2.1 dat OR 2.2 .dll",#1 OR .dll #1 OR .dll" #1

Output:

Here’s a Sigma detection rule that matches the behavior you described:

title: Detect Sofacy Trojan Loader Activity
description: Detects rundll32.exe usage with %APPDATA% and a .dat file or .dll file loaded as a .dll with #1 as parameter.

detection:
  selection:
    CommandLine:
      - '*rundll32.exe*'
      - '*%APPDATA%*'
      - '*dat*'
      - '*\\.dll #1'
      - '*\\.dll",#1'
      - '*\\.dll" #1'
  condition: selection
  occurrence: 2

This rule will trigger an alert if the CommandLine field of a process contains the specified patterns. The occurrence field is set to 2 to ensure that all three patterns are present in the command line. You can adjust the title and description to suit your needs.

Review:

Here the detection would be way to noisy; if any one of the terms is seen in the logs, a detection would be triggered. This detection would potentially trigger thousands of alerts per day. *%APPDATA%* alone is seen

%AppData% is a hidden folder in Windows. It is to protect user data and settings from any unwanted change or deletion. It contains many important data such as: program settings, IE cookies, IE browsing history, temporary files created by applications, etc. Hence, it will be used for thousands of benign requests for every Windows user. Multiply that by 10,000 employees, and your SOC has a real headache.

Some required properties are also missing from this rule (e.g. logsource). GPT also adds a non-supported property to the rule, occurances, which is not in the Sigma specification.

I also made an error with 2.2, where I forgot to prompt that the command line ends with *.dll* values.

Let me try and reword the prompt for better results.

Input:

Thanks, but the rule is to open in terms of the data that it will trigger a detection on. For example, matching on %AppData% will match to many benign Windows events.

Instead the detection should be broken down into two logical parts.

1. the command line must always contain the string rundll32.exe AND %APPDATA%\
2. the command line must also contain .dat, OR if it does not contain dat, it must end with one of the following strings .dll",#1 OR .dll #1 OR .dll" #1

Output:

Thank you for the clarification. Here’s an updated Sigma detection rule based on your requirements:

title: Detect Sofacy Trojan Loader Activity
description: Detects rundll32.exe usage with %APPDATA% and a .dat file or .dll file loaded as a .dll with #1 as parameter.

detection:
  selection:
    CommandLine:
      - '*rundll32.exe*'
      - '*%APPDATA%*'
      - '*\\.dat*'
      - '*\\.dll #1'
      - '*\\.dll",#1'
      - '*\\.dll" #1'
  condition: selection
  selection2:
    CommandLine:
      - '*rundll32.exe*'
      - '*%APPDATA%*'
      - ( '*\\.dat*' and not '*\\.dll*' ) or ( '*\\.dll #1' or '*\\.dll",#1' or '*\\.dll" #1' )
  condition: selection2

This rule will trigger an alert if the CommandLine field of a process contains rundll32.exe and %APPDATA%, and either contains .dat, or if it doesn’t contain .dat, it ends with one of the specified .dll patterns with #1 as a parameter. The rule breaks down the detection into two logical parts to reduce false positives. You can adjust the title and description to suit your needs.

Review:

It’s clear GPT needs more training either via input prompts or future models using more focused data to understand Sigma.

Through trial and errors, it became clear GPT understood the logic, but just didn’t understand how to structure it in a valid Sigma.

This is where OpenAI plugin ecosystem would come in useful (I’m still on the waiting list). Instead of trying to teach GPT the Sigma specification through prompts, this could be done via a plugin with the knowledge of the Sigma schema stored within it.

I want to get to a point where I can take the description of a malware (or campaign, etc.) and get a valid detection from it.

To further demonstrate the need for improvement of GPT’s understanding of Sigma, here is one of the first queries I ever entered to ChatGPT asking it to convert a description from Unit 42 of the Canon Trojan to a Sigma rule;

Input:

Below is a description of the Canon trojan. Write a Sigma rule to detect it please;

1. Cannon gathers system information and saves it to a file named ini. The Trojan sends an email to sahro.bella7[at]post.cz with i.ini as the attachment, S_inf within the body and a subject with a unique system identifier via SMTPS from one of the following accounts: Bishtr.cam47, Lobrek.chizh , Cervot.woprov

2. Cannon takes a screenshot and saves it to a file named ops. The Trojan sends an email to sahro.bella7[at]post.cz with sysscr.ops as the attachment, the string SCreen within the body and a subject with the unique system identifier via SMTPS from one of three previously used accounts.

3. The actors likely log into sahro.bella7[at]post.cz and process the system information and screenshot sent by the Trojan to determine if the compromised host is of interest. If the actor wishes to download an additional payload to the compromised host, they will respond by sending emails in the following steps.

4. The actor sends an email to trala.cosh2[at]post.cz with the unique system identifier as a subject with a secondary email account and credentials in ASCII hexadecimal format within the message body. This secondary email account is unknown at this time, so we will refer to it as “secondary email account” in future steps.

5. The actor sends an email to the secondary email account with the unique system identifier as a subject with a secondary payload attached with a filename of txt.

6. Cannon logs into the trala.cosh2[at]post.cz account via POP3S looking for emails with a subject that matches the unique system identifier. Cannon opens the email with the correct subject and decodes the hexadecimal data in the body of the message to obtain the secondary email account.

Output:

Here is a Sigma rule for the Canon Trojan:

title: Trojan.Cannon
description: Detects the Cannon Trojan sending system information and screenshots to a remote email address and receiving commands via email to download and execute a payload.
status: experimental
references:
    - https://www.example.com/trojan-cannon-analysis
tags:
    - trojan
    - email exfiltration
    - email command and control
    - smtps
    - pop3s
    - file exfiltration
    - file download
    - file execution
logsource:
    category: firewall
    product: any
detection:
    selection:
        src_ip: [192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12] # adjust as needed to match your network
        dest_port: [465, 995] # SMTPS and POP3S ports
        dest_domain: ["post.cz"]
    condition: >
        (event_id == "email_sent" and
         attachment.name == "ini" and
         body == "S_inf" and
         (sender_email == "Bishtr.cam47" or sender_email == "Lobrek.chizh" or sender_email == "Cervot.woprov") and
         recipient_email == "[email protected]") or
        (event_id == "email_sent" and
         attachment.name == "ops" and
         body == "SCreen" and
         (sender_email == "Bishtr.cam47" or sender_email == "Lobrek.chizh" or sender_email == "Cervot.woprov") and
         recipient_email == "[email protected]") or
        (event_id == "email_received" and
         subject == unique_system_identifier and
         sender_email == actor_email and
         attachment.name == "txt" and
         attachment.content_type == "text/plain" and
         length(attachment.data) % 2 == 0) or
        (event_id == "email_received" and
         subject == unique_system_identifier and
         sender_email == secondary_email_account and
         attachment.name == "txt") or
        (event_id == "email_received" and
         subject == unique_system_identifier and
         sender_email == "[email protected]" and
         attachment.name == "txt" and
         attachment.content_type == "text/plain" and
         length(attachment.data) % 2 == 0) or
        (event_id == "email_sent" and
         attachment.name == "s.txt" and
         body == "ok" and
         (sender_email == "Bishtr.cam47" or sender_email == "Lobrek.chizh" or sender_email == "Cervot.woprov") and
         recipient_email == "[email protected]") or
        (event_id == "email_sent" and
         attachment.name == "l.txt" and
         body == "ok2" and
         (sender_email == "Bishtr.cam47" or sender_email == "Lobrek.chizh" or sender_email == "Cervot.woprov") and
         recipient_email == "[email protected]") or
        (event_id == "email_sent" and
         attachment.name == "s.txt" and
         body == "ok3" and
         (sender_email == "Bishtr.cam47" or sender_email == "

Review:

You can see here the condition above contains a detection. The detection, in addition to being under the wrong property, does not conform to the Sigma specification (and contains a lot of messy logic).

Give it a few months (or weeks!) and I suspect this output will be much improved!

More at FIRST TC in Amsterdam

p.s I will be presenting the work from the last four posts (and more) at some upcoming conferences (next up, FIRST TC in Amsterdam tomorrow).

Hopefully there will be some recordings I can share at a later date.

Update 2023-04-19: You can grab a copy of my slides from the event here.

Next up: using GPT to write software

In the past few months I have seen people trying to build entire software products using GPT, so I wanted to see if I could recreate my, by comparison, simplistic requirements for paging through the CPE API…

---

« STIX 2.1 109: Choosing a UUID version to generate STIX Object IDs Building cyber-security software using GPT-4 (Part 5) »

---

Similar Posts You Will Enjoy Reading...

Building cyber-security software using GPT-4 (Part 5)

Writing intelligence reports using GPT-3 (part 3)

More experiments with threat intelligence enrichment using GPT-3 (part 2)

Using GPT-3 to create structured threat intelligence (part 1)

---

Discuss this post

JOIN US

Never miss an update

Sign up to receive new articles in your inbox as they published.