ChatGPT for Cybersecurity in 2026: 9 Prompts That Survive Contact With a SOC

Ask ChatGPT which versions of a package a given CVE affects and it will hand you a version range, a severity and a patch status in the same even, confident register it uses for everything else. Part of that answer is reconstructed from the shape of advisories it saw during training rather than read off the advisory you care about, and a reconstructed version range is exactly the kind of near-miss that changes a patching decision without ever looking wrong. Paste the advisory text into the same conversation and ask the same question, and the answer becomes dependable, because the model is now reading instead of remembering.

That distinction, recall versus reading, decides almost everything about where a language model belongs in security work. On the reading side, ChatGPT is genuinely strong: it explains a log line or a PowerShell one-liner faster than you can, converts a plain description of malicious behavior into a syntactically clean detection rule, compresses a messy incident into four paragraphs a director can act on, and writes the regex that pulls indicators out of an unstructured feed dump. On the recall side it is a liability, because it has no vulnerability database, no telemetry, no feed, and no mechanism for telling you which parts of its answer it actually knows.

So the failure modes come first here, before a single prompt. Nine prompts follow, grouped by the kind of work they do rather than numbered into a list, and the account and data question is dealt with at the end, once you can see exactly what you would be pasting.

Three ways it gets security work wrong

Hallucinated CVE detail. This is the failure mode that costs the most and announces itself the least. Asked to recall a vulnerability from memory rather than summarize text you provided, the model can state an affected version range, a CVSS score, an exploitation prerequisite or a patch status that is plausible, specific and wrong. The damage is downstream: "is this exploitable in our environment" is a question whose answer sets patch windows, change-freeze exceptions and who gets paged this weekend. Log4Shell (CVE-2021-44228, CVSS 10.0) is the standing example of why the range matters more than the headline, since the exact affected versions of log4j-core decided whether a given host was a real problem or a ticket you could schedule. Anything you would not accept from a junior analyst who said "I think I read somewhere that", do not accept from a chat window.

Fabricated indicators. Ask it to list known C2 domains, hashes or IP ranges for a named threat actor and it will produce a list. Some entries will be real, some will be transposed from a different campaign, and some were never observed by anyone. They all look identical: correct format, plausible TLDs, right hash length. An indicator with no provenance has no place in a blocklist or a hunt query, and an indicator with a fabricated provenance is worse, because it will be re-cited internally until someone spends a day chasing traffic that never existed. The rule is simple to state and easy to skip under pressure: every indicator you act on traces back to a document you can open.

Quietly incomplete regex. Detection logic and extraction logic written by a model tend to fail in the direction that produces no error message. A regex that matches every example you pasted can still miss IPv6 addresses, CIDR notation, hashes embedded inside longer hex strings, or a defanging convention your feed uses and your samples did not. Nothing throws. You get a shorter list of indicators than you should have, and the gap only surfaces when something you would have blocked gets through. The same applies to a Sigma rule that references a field name your SIEM does not populate: it deploys cleanly, it never fires, and a rule that never fires looks exactly like a rule that has nothing to detect.

Reading: logs, scripts and advisories

This is the category where the model earns its place with the least risk attached, because every one of these tasks is "explain the text in front of you" rather than "tell me what you know". The discipline that makes it safe is the same each time: strip identifying detail before pasting, and replace real hostnames, usernames, internal addresses and customer identifiers with placeholders. The indicators that carry the analytical weight (process lineage, header anomalies, encoded payloads, URL structure) survive redaction perfectly well. That habit also opens up adjacent work such as a fast structural pass over phishing headers, where SPF, DKIM and DMARC results, a Return-Path that does not match the From domain and authority-pressure language in the body all read fine with the recipient's name swapped out.

Explain a suspicious log line

The lowest-risk use case in the whole set, and the one a new analyst benefits from most. Ask for the reasoning, not a restatement of the fields you can already see.

Explain what this log line is doing, step by step, and flag anything
that looks unusual or worth escalating. This is from a Windows Security
event log. I've replaced the real hostname and username with placeholders.

Event ID 4688, New Process Name: C:\Windows\System32\rundll32.exe,
Command Line: rundll32.exe C:\Users\PLACEHOLDER\AppData\Local\Temp\a.dll,Entry
Parent Process: WINWORD.EXE
Creator User: PLACEHOLDER-HOST\svc_backup

The value is in the "why". A rundll32 child process spawned by Word, running under a service account that has no business opening documents, is a pattern worth a plain-English note in the ticket so the next person on the queue does not have to rebuild the reasoning from scratch. Where the model helps most is turning a lineage you recognize into a sentence a reviewer who has not seen it will understand.

Deobfuscate a suspicious script

Decoding a base64 PowerShell one-liner by hand is tedious and error-prone. The model decodes and explains in a single pass, which is a genuine time saving on a task nobody enjoys.

Decode and explain this PowerShell command. Show the fully decoded
script, then explain what it does step by step, and flag any network
calls, persistence mechanisms, or obfuscation techniques used (e.g.
string concatenation to evade signature matching).

powershell.exe -enc [base64 string]

Cross-check the decoded output yourself, especially where encoding is nested (base64 inside base64, or base64 wrapped in gzip). The decode is usually correct, and "usually" is not a standard you can put in an incident report. Ask explicitly for the obfuscation techniques as a separate list: naming them forces the model to account for the parts of the script that exist purely to defeat signature matching, which is often where the interesting behavior is hiding.

Summarize a pasted advisory

Never ask for a CVE from memory. Paste the advisory and constrain the model to the text, and it becomes a fast, accurate reader of exactly the document you need read.

I'm pasting the NVD/vendor advisory text for a CVE below. Summarize:
1) the vulnerability class (e.g. auth bypass, RCE, path traversal),
2) the exact affected versions as stated in the text, 3) what an
attacker needs (authenticated access? network position? user
interaction?) to exploit it, 4) whether a patch or workaround is
listed, quoted directly. Do not add any detail that isn't in the
text I pasted, and flag anything ambiguous rather than guessing.

[paste the advisory text, e.g. from NVD, vendor security bulletin, or CISA KEV]

The instruction that does the work is "flag anything ambiguous rather than guessing". Advisories are frequently vague about the exploitation prerequisite, and an unconstrained summary will resolve that vagueness in whichever direction reads more smoothly. You want the ambiguity preserved, because the ambiguity is the thing you need to go and resolve with the vendor. Run this against the primary document every time: the NVD entry, the vendor bulletin, or the CISA Known Exploited Vulnerabilities catalogue entry, not a secondhand write-up of it.

Writing detections

Here the model produces something that will run in your environment, which raises the stakes considerably. Treat every output in this section as a first draft from someone who has never seen your log schema, because that is precisely what it is.

Draft a Sigma rule

Converting a plain description of malicious behavior into correct Sigma YAML is a task the model handles well. Field mappings are where it cannot help you.

Write a Sigma rule (YAML) that detects rundll32.exe being spawned as a
child process of any Office application (WINWORD.EXE, EXCEL.EXE,
POWERPNT.EXE). Use logsource category process_creation, product windows.
Include a title, description, tags mapping to the relevant MITRE ATT&CK
technique, level high, and a falsepositives section listing legitimate
reasons this might fire.

Ask for the falsepositives section by name, every time. Without it you get a rule that is technically correct and operationally hostile, one that fires on a legitimate deployment tool at 09:00 every Monday and gets muted within a fortnight. Requiring the model to enumerate benign triggers forces the same thinking a detection engineer does before shipping. Then validate every field name against your own schema and run the rule against historical data before it goes anywhere near a live queue.

Draft a YARA rule

Good for turning behavior described in a public write-up into a starting rule. Useless for anything genuinely novel, since it can only work from what you describe.

Based on this description of a malware family's behavior, draft a YARA
rule: it drops a file to %TEMP%\svchost_update.exe, sets a registry
Run key named "WindowsUpdateSvc," and beacons via HTTP POST to a C2
with a static User-Agent string "Mozilla/5.0 (compatible; WinUpd/2.1)".
Include string matches for the User-Agent, the registry key name, and
the dropped filename pattern. Add a condition requiring at least 2 of
3 strings to match, to reduce false positives from any single benign
overlap.

The two-of-three condition is doing real work: a rule built from a two-paragraph description will otherwise anchor on incidental strings that appear across large amounts of benign software. Test the result against a clean baseline of your standard build before it goes near a production scan, and be honest about what the rule actually covers, which is the specific artefacts described in the write-up and nothing else.

Write an IOC extraction regex

Pure pattern matching on text, with no claim about the world attached, which makes this one of the strongest uses in the set.

Write a regex that extracts the following from a block of text, each
as a separate pattern: IPv4 addresses (including defanged formats like
185[.]220[.]101[.]45), MD5 hashes (32 hex chars), SHA256 hashes (64 hex
chars), and domain names (including defanged like malicious-domain[.]com).
Show each pattern separately with a one-line explanation, then combine
them into a single Python script using the re module that reads a text
file and outputs matches grouped by type.

Asking for each pattern separately with an explanation before the combined script is not cosmetic: it gives you something you can actually review line by line, instead of a wall of escaped characters you either trust or do not. Then test it against your own defanged and non-defanged conventions, plus a deliberately awkward sample containing IPv6, CIDR ranges and hashes embedded in longer strings. Extraction regex fails silently, so the test set is the only thing standing between you and a short list you believe is complete.

Writing for humans

The last three are pure language work, which is where the model is at its least dangerous and most immediately useful. Nothing here touches your telemetry. What it touches is how clearly your work reads to people who will never see the underlying logs, and that is worth more time than most teams give it.

Draft an executive incident summary

Leadership summaries need a register most analysts do not write in daily: plain language, no unexplained jargon, explicit business impact. Give it the facts and the shape of the argument.

Draft a 4-paragraph executive summary of this incident for a leadership
audience with no security background. Structure: what happened (plain
language, no jargon like "lateral movement" without explaining it),
what was affected and for how long, what we did to contain and remediate,
and what we're changing to prevent recurrence. Facts to use, don't add
others: a single workstation was compromised via a phishing attachment,
contained within 40 minutes of alert, no evidence of lateral movement or
data exfiltration based on EDR telemetry, endpoint reimaged, and MFA
enforcement being expanded to the affected team.

The "don't add others" constraint is load-bearing. Left unconstrained, the model smooths over gaps in the narrative with confident connective language, and the result reads like a finding your team confirmed when it is really a sentence the model needed to make the paragraph flow. Read the draft specifically hunting for claims you never made.

Map behavior to MITRE ATT&CK

Useful when a report needs accurate technique IDs rather than a loose description. Make it justify each mapping so wrong IDs are easier to catch.

Map this attacker behavior to MITRE ATT&CK techniques and sub-techniques,
with the specific technique ID for each: initial access via a phishing
email with a macro-enabled attachment, execution via PowerShell running
a base64-encoded downloader, persistence via a scheduled task, and
command and control over HTTPS to a domain generated by a DGA pattern.
For each technique, give the ID, the technique name, and one sentence
on why this behavior matches it.

Check every ID against the framework itself before publication. A confidently stated wrong technique ID reads as correct to every reader who does not look it up, and technique IDs have a habit of being copied forward into the next report, the next metrics deck and eventually into a control coverage claim nobody re-derives.

Draft a playbook step

Strong at turning a rough runbook idea into a structured, reviewable checklist. Not a substitute for running the thing in a tabletop.

Draft a playbook section for responding to a suspected ransomware
encryption event in progress. Structure as numbered steps under:
immediate containment (first 15 minutes), investigation, communication
(internal and, if needed, external), and recovery. Include a decision
point for when to engage law enforcement or outside incident response,
and note which steps require approval above the on-call analyst level.

Asking it to mark which steps need approval above the on-call analyst is the part that turns a generic checklist into something usable, because the delay in a real incident is rarely technical. Then have someone who has actually run an incident review it. The output reads well and reliably omits the operational detail that only comes from experience, starting with who genuinely holds authority to isolate a production segment outside business hours.

Which account you can actually paste into

Free is a fine place to learn the tool against synthetic or generic examples. It is the wrong place for anything carrying your organization's fingerprints, since personal accounts default to using conversations to improve future models unless you change that yourself under Data Controls.

Plus ($20/month) is where most individual analysts land: higher usage limits, and Advanced Data Analysis, which runs real Python against a file you upload rather than inferring what the file probably contains. It is still a personal account with the same default handling as Free until you opt out.

Business (roughly $20-25/seat/month, two-seat minimum) is the meaningful step for a team, mainly because conversations and uploaded files are excluded from training by default rather than by a setting each analyst has to remember. Enterprise (custom pricing) adds a signed DPA, admin-controlled retention and full conversation logs you can audit yourself.

Now the part that matters more than the tier. Security work runs on chain of custody, and a chat window is a place where chain of custody ends. Once a raw log excerpt, a live-investigation indicator, a credential, an internal hostname or an IP range from your address space leaves your environment, you have handed a third party a copy of evidence you may later need to account for, and you cannot un-hand it. Log excerpts in particular are worth treating as hostile: a single line you pasted for its process lineage can carry a session token, an internal share path or a customer email address you never looked at. So the working rule is sanitise before you paste, not after you regret it. Placeholder hostnames, fake IPs, hashed identifiers, redacted usernames. Do it on Business and Enterprise too, because the training default changes what OpenAI does with the data, not the fact that the data left your perimeter. Where NDAs or regulator-notifiable material are in scope, that decision belongs to security and legal, made in advance and written down, not made by an analyst three hours into an incident.

Get the sanitised-input habit in place while nothing is on fire. (Cyberpresso publishes on AI and security most days if you want to keep up with how these tools are shifting.)

What the software actually costs

There is no single price for security tooling, so the useful reference is what comparable software costs. We price every tool we review: 293 of 429 publish a price, 33% offer a free tier, and the median entry plan across all of them is $24 a month. 169 of them cost under $25, and only 28 cost more than $100.

Category changes that number more than any other factor. The gap between the cheapest and the most expensive category median is $8.13 against $59, a factor of 7.3.

Category	Median entry price	Tools priced
SEO	$59	6
HR	$39	19
Finance	$37	16
Data	$29.50	8
Marketing	$29	53
Sales	$29	31
Developer	$24.50	18
Operations	$24	29
Customer support	$24	22
Content creation	$15	23
Design	$15	13
Productivity	$14	38
Education	$9.16	8
Project management	$8.13	8

FAQ

Can I deploy a Sigma or YARA rule ChatGPT wrote straight to production?

No. Treat it as a first draft that has never seen your environment. A Sigma rule needs every field name validated against your own log schema and a backtest against historical data to see what it would have fired on. A YARA rule needs a run against a clean baseline of your standard build. The model does not know your field names, your log volume or your false-positive tolerance, so a rule that is syntactically perfect can still flood the queue or, worse, sit silently for months without matching anything.

Our incident data falls under customer NDAs. Does that rule ChatGPT out?

It rules out pasting the data, not using the tool. Almost everything above works on sanitised input: placeholder hostnames, fake IP ranges, hashed identifiers, redacted usernames. The analytical shape of a log line or a script survives redaction. Where you genuinely need real data in the prompt, that is a decision for security and legal to make before the incident, ideally recorded as a documented approval covering a specific plan tier and a specific class of data, rather than a judgment call made under deadline pressure.

Why does it get CVE details wrong when it sounds so certain?

Because it is generating a plausible continuation rather than looking anything up. It has no vulnerability database attached, and it has a training cutoff, so anything disclosed or revised since then does not exist for it. The confident tone is a property of how the model writes, not a signal of how well grounded a particular claim is. The fix is mechanical: pull the primary source (NVD, the vendor bulletin, the CISA KEV entry), paste the relevant text, and instruct the model to work only from what you pasted and to flag anything ambiguous.

Should we use ChatGPT or the AI copilot built into our security stack?

They solve different problems. A copilot inside your XDR or SIEM has live access to your telemetry, your asset inventory and current feeds, which is exactly what ChatGPT lacks. ChatGPT is stronger on the language layer around that: explaining an unfamiliar log line, drafting a rule from a description, deobfuscating a script, writing the executive summary nobody wants to write. Most mature teams run both and keep the boundary clear, with the chat window doing drafting and explanation and the integrated tool doing anything that requires knowing what is actually happening on your network.

Can it take tier-1 triage off an analyst's plate?

It can take the writing and explaining off, not the deciding. It speeds up the first read of a log line, the first draft of a rule and the summary at the end, which is a real reduction in the least interesting parts of the shift. What it cannot do is see your environment, weigh a finding against what is normal for your business, or carry accountability for a missed detection. The escalation call, the containment decision and the sign-off stay with the analyst, and any workflow that quietly moves them into a chat window is one you will regret auditing later.