CU-GIR: How to Use the Cyber Underground General Intelligence Requirements to Get Ahead of Cybercrime

Corporate VPN access. A domain user account. A mid-size retailer. All of it priced according to what the victim can afford to pay.

Cybercrime forums sell access like this before a ransomware crew ever logs in. Your indicator of compromise (IOC) feed only sees what happens after the fact. So how do you spot that listing early enough to revoke the session before anyone buys it?

This is where the CU-GIR comes in. Intel 471’s Cyber Underground General Intelligence Requirements framework turns infostealer logs and access broker listings into a structured menu of intelligence requirements your team can actually fulfill.

This guide will teach you how the cybercrime supply chain works, how the CU-GIR maps onto it, and how to turn its requirements into priority intelligence requirements, collection plans, and metrics that prove your value.

Let’s get started!

---

Why Your IOC Feed Will Always Be Late

Most teams treat the gap between an underground listing and a ransomware incident as a tuning problem. A detection deficit. Faster feeds and better blocklists will fix it, right?

Wrong.

It is a structural problem, and it starts with how you decide what to collect.

Let me introduce you to the Pyramid of Pain. Hashes, IP addresses, and domains sit at the bottom. They are the cheapest things an attacker can burn and replace. Every indicator in your feed was born after somebody else’s incident.

An IOC feed is your adversary’s receipts, delivered by a third party after the transaction has cleared. Useful, but not foresight.

To be fair, IOCs still earn their keep. They scope incidents, drive retro hunts, and block commodity noise for free (see the indicator lifecycle for how to manage them well). But IOCs tell you what touched you. Intelligence requirements tell you what is being prepared against you.

---

Where the CU-GIR Came From

Military scouts hit this exact wall. They got huge amounts of input, no priority list, so they tracked the obvious and missed the enemy.

The U.S. Marine Corps answered with a military antecedent: an urban intelligence requirements handbook (the UGIRH) from the Marine Corps Intelligence Activity, listing standard questions about buildings, populations, transport, and communications that fed a commander’s decisions.

Michael DeBolt, a Marine Corps infantry veteran and former Naval Criminal Investigative Service (NCIS) special agent, saw that the underground has streets too. Now President and Chief Intelligence Officer of Intel 471, he introduced the commercial framework in a 2020 Intel 471 blog post, adapting the military’s UGIRH model into Intel 471’s Cyber Underground General Intelligence Requirements (CU-GIR) and its handbook, the CU-GIRH, for corporate cyber security.

The insight? The underground runs on repeatable infrastructure: escrow services, bulletproof hosting, exploit marketplaces, botnets, and access brokers. Repeatable infrastructure leaves repeatable traces, and you can write a checklist to find them.

Threat actor is the wrong unit of analysis for most of the cybercrime ecosystem. Affiliates rotate, and brands rebrand, but the services persist: the broker role, the log shop, the crypter. Organize your program around group names, and you are tracking employees while ignoring the org chart. 

Key Definitions: GIRs, PIRs, EEIs, and RFIs

• General Intelligence Requirements (GIRs): A standing, generic question set for a domain. Think of it as a menu. The CU-GIR is that menu for the cybercrime underground.
• Priority Intelligence Requirements (PIRs): What your organization picked from the menu, tied to a decision someone in your business owns. This is the order. No stakeholder sign-off, no PIR.
• Essential Elements of Information (EEIs): The specific information that answers a requirement: the who, what, when, where, why, and how. This is the checklist item a collector works against.
• Requests for Information (RFIs): A one-off question from a stakeholder. You answer it from what you already hold or task a new collection.

If you get three RFIs on the same topic, you have an unregistered PIR. That is a gap in your requirements list, and you should probably add it formally. Common challenges in creating intelligence requirements often start right here. 

Reading the CU-GIR Framework

The CU-GIR sorts the underground into six pillars:

1. Malware
2. Vulnerabilities and Exploits
3. Malicious Infrastructure
4. Fraud, Identity Theft and Unauthorized Access
5. Adversary Tactics and Activities
6. Threats Impacting Industry or Region

For the access broker problem, two pillars matter most. Pillar one (malware) and pillar four (fraud, identity theft, and unauthorized access). That is where the stealers, brokers, and credentials live.

Requirements nest like a category tree. Malware is 1. Malware variants are 1.1. Ransomware malware is 1.1.1. Each child inherits its parent’s context, so answering a child requirement also feeds its parent.

PDF or STIX? Two Ways to Use the CU-GIR

Intel 471 publishes the CU-GIR in two formats, and each suits a different job.

The CU-GIRH is a PDF handbook built for people. Every requirement sits alongside its definition, EEIs, typical stakeholders, and common use cases, so you can read it cover to cover or take it into a stakeholder interview.

The Structured Threat Information Expression (STIX) bundle on GitHub is built for machines. It holds the same requirements as linked STIX objects, each tagged with its GIR ID, so tools can filter, tag, and route intelligence automatically.

Most teams get the best of both. Use the handbook to plan your requirements with stakeholders, then use the STIX bundle to operationalize them in your tooling.

Intel 471 updates the PDF handbook more often than the GitHub file, so the two can drift apart. If the wording matters, check the handbook first. 

However, even with a structured framework like the CU-GIR in hand, teams can easily stumble if they misuse it.

Only the second one buys you time.

---

The Four-Stage Cybercrime Supply Chain Behind Ransomware

To see where requirements fit, look at how most ransomware incidents actually start. Four stages, each a separate underground business.

1. The stealer. Developers rent out infostealer malware as a subscription service, complete with builds and admin panels. Their customers spread it through malvertising or phishing, and an employee gets infected. The stealer lifts browser cookies, saved credentials, and VPN profiles. No ransomware yet, and nothing your feed can flag.
2. The log shop. The stolen logs get packaged and sold on automated shops. Think Russian Market, or Genesis Market before law enforcement shut it down.
3. The access broker. A broker buys logs in bulk, tests which sessions still work, and lists verified corporate access on forums like Exploit. The price scales with the victim’s revenue and the privilege on offer.
4. The ransomware affiliate. An affiliate buys the listing, logs in with a valid session, escalates privileges, exfiltrates data, and encrypts everything.

Stage four is where your detection stack lights up. But by the time your endpoint detection and response (EDR) tool fires, three other criminal businesses have already been paid.

You only ever meet the last one.

Genesis Market is a textbook example of stage two. The U.S. Department of Justice described it as a key ransomware enabler when Operation Cookie Monster, an FBI-led effort involving law enforcement from 17 countries, seized its domains in April 2023. 

Laying the CU-GIR Over the Chain

Every stage of that chain has a matching CU-GIR requirement:

Supply chain stage	CU-GIR ID	Requirement
Stealer infection	1.1.5	Information-stealer malware
Log shop	4.2.2	Compromised credentials
Access broker listing	4.2.5	Compromised network or system access
Access broker listing	4.7	Access classification
Ransomware deployment	1.1.1	Ransomware malware

So what can you actually see? Stealer builds and panels for sale. Log shops indexing victims by domain. Access listings stating revenue band and privilege. Then the leak site posts, once it’s too late.

The first three are readable before anyone gets encrypted.

Your EDR measures time to detect inside your network. A requirements-driven program measures the gap between the underground listing and the attacker’s first move.

This is the power of a well-functioning CTI team.

What about 4.1, fraud supply chain monetization? Its children cover what happens to the money after an attack: cashout, money laundering, mules, and drop accounts. Track it if your fraud team needs to follow the proceeds, but it isn’t where stealer logs are sold. 

---

Two Failure Modes to Avoid

Before you rush off to buy dark web monitoring, beware of two failure modes I see over and over again.

Failure One: Keyword Alerting on Your Brand

Alerting on your brand name across the dark web is just a panic generator.

Leak sites don’t always tell the truth. Ransomware brands relaunch, and some sites repost old or fabricated victim claims to look bigger than they are. If a keyword hit can trigger incident response without any validation, you have just handed the adversary a lever to pull.

Failure Two: Collecting More and More

The second trap is chasing volume. Thousands of forums, Telegram channels, and marketplaces. Millions of messages a day.

Collection without questions just produces volume. And volume produces an analyst who stops reading.

You don’t need more data. You need the question the data is supposed to answer…

Format	Best for	Watch out for
PDF handbook	Planning workshops, stakeholder interviews, onboarding new analysts	Static, so you can’t query or automate it; download is behind a request form
STIX bundle	Importing into a threat intelligence platform like MISP or OpenCTI, tagging reports, routing by GIR ID	Needs engineering effort to ingest; hard to read raw because it’s mostly relationships; updates can introduce breaking changes

---

Where the CU-GIR Fits in Your Intelligence Lifecycle

So where does the CU-GIR slot into the threat intelligence lifecycle? You’ll use it in four stages.

1. Direction and planning. Interview your Chief Information Security Officer (CISO), Security Operations Center (SOC) lead, incident response team, and fraud team. Have each pick GIRs tied to a decision they own. Collect them, rank them, and turn them into PIRs.
2. Collection. Match each requirement to a collector, be it a machine, a human, or a data source.
3. Production. Tag finished reports with the GIR ID so they route to the right owner and you can measure what you produce.
4. Feedback. Review each quarter: was the requirement answered, and did anyone act on it?

The menu is the framework. The ranking is the strategy.

---

A Worked Example: From GIR to PIR to RFI

Let’s see how you would use the CU-GIR in practice.

Step One: Select and Rank Your GIRs

Say your stakeholder interviews produce five GIRs to focus on: infostealers (1.1.5), compromised credentials (4.2.2), compromised network access (4.2.5), access classification (4.7), and ransomware (1.1.1).

Record them in a six-column requirements table. My intelligence requirements template gives you a head start. Here is what one row looks like:

GIR	Priority	Stakeholders	EEIs	PIR	RFIs
4.7 Access classification	High	SOC lead, identity team, incident response	Listings matching our sector, size band, VPN or SSO vendor; wholesale or specified	Is access to our network being sold? (see Step Three)	Which sites sell access? Is the access real?

Step Two: Define the EEIs

For GIR 4.7, the EEIs are listings that match:

• Your sector
• Your revenue or size band
• Your VPN or single sign-on (SSO) vendors
• Whether the access is wholesale (unverified) or specified (the seller has shown it works)

Step Three: Draft the PIR

Combine your interviews, the CU-GIR, and your EEIs into a PIR like this:

“Determine whether access to our corporate network, via our VPN or Okta SSO, has been advertised for sale on cybercrime forums or marketplaces within the last 30 days.“

Now that is a specific question a team can answer.

Step Four: Break the PIR Into RFIs

Next, break the PIR down into individual RFIs that must be completed to answer it:

1. Which underground sites sell initial access?
2. Which sites focus on our geography, sector, and technology stack?
3. How can we gain access to these sites?
4. How can we verify whether the advertised access is legitimate?
5. How can we verify whether the affected accounts have already been used?

Step Five: Build the Collection Plan

Finally, build an intelligence collection plan that maps your data sources and delivery needs to these requirements. Ask:

• What internal or external threat intelligence sources can answer these EEIs?
• What is the scope of the intelligence: tactical, operational, or strategic?
• Which intelligence products will contain the answers?
• What is the delivery cadence?

A collection management framework helps you track which sources cover which requirements.

---

Measuring Success: Decisions Changed, Not Reports Shipped

Your CTI program’s headline key performance indicator (KPI) isn’t reports shipped. It’s decisions changed.

If you can’t name the patch, the reset, or the block that happened because of a report you delivered, you are just running a newsletter and hoping someone reads it. And I say that as someone who runs one.

Here are three CTI metrics you can track from your requirements document:

1. Lead time. The days between your team spotting the listing and the attacker’s first move, or your preemptive fix if they never get one. Example: listing spotted on day zero, session revoked on day two, no intrusion. That head start is what you show your Chief Financial Officer (CFO) when asking for budget.
2. Preemptive actions. Revoke sessions and rotate credentials before anyone uses them. This is your decisions-changed count.
3. PIR fulfillment rate. Resolved EEIs divided by tasked EEIs. Requirements that sit unfulfilled for quarters signal a collection blind spot or a requirement nobody needs. Streamline them.

The Catch With Fulfillment Rate

Fulfillment rate is the vanity metric of a requirements program. Write soft EEIs or PIRs, and you can hit 95% while the hard questions, the ones that move the needle, rot away.

You are grading your own homework here. You wrote the requirements, and you are ticking the boxes.

Fulfillment tells you how much you answered. It can’t tell you whether you asked the right questions or whether anyone acted on the answers.

Requirements tell you what to ask. They don’t tell you how well your program answers. That is where the Cyber Threat Intelligence Capability Maturity Model (CTI-CMM) comes in, a vendor-agnostic model for measuring how mature your CTI capability really is.

---

Conclusion

This guide has taught you why IOC feeds arrive late, how the four-stage cybercrime supply chain feeds ransomware, and how the CU-GIR maps a requirement to every stage. You can now walk from a GIR to a PIR, a set of RFIs, and a collection plan.

The listing is where you start. If you know which questions to ask, you can revoke that VPN session before anyone buys it.

Pick one GIR this week, tie it to a stakeholder decision, and see what you find. Good luck!

Frequently Asked Questions