0.6 The Practice Lab and the Sample Month

Introduction

Every search in this course runs in the practice lab: an SPL engine in your browser, reading a fixed month of events from Northgate Engineering, a fictional engineering company. The month is the same for everyone, so every number in the course can be reproduced, and several real attacks are in it, waiting to be found.

The lab behaves like Splunk for the commands this course teaches; where it does not, this section says so, so that nothing learned here has to be unlearned at work.

You will see the month's span across the core sources, count the accounts that sign in, read a time computed by stats in three forms, open a lookup table, and see how the lab decides what now is. By the end you should know what the lab holds, how to use it well, and every place it differs from Splunk that affects a search.

The diagram is the lab in one line, data to engine to page, with its differences beneath. The bottom box is the important one: each difference is small, and each is listed here so that none becomes a habit.

The list is short because the lab was built to match Splunk wherever the course depends on it. Where an early version of the lab differed, matching field names in any case, for instance, it was corrected rather than documented.

The first three lines describe the data, the next four the engine, and the last two features of Splunk the lab does not model. The sections below show the ones that affect searching most, each with a search.

The card is the full list. Most of the differences are in the data, fields the lab's month does not record; a few are in the engine, how it shows times and which commands it runs. None of them changes how a search is written for Splunk.

The sample month runs from the early hours of Friday 13 February 2026 to midday on Sunday 15 March.

| tstats min(_time) as first max(_time) as last count where index=* by sourcetype

The counts per source match Sections 0.1 and 0.3. Every figure in the course comes from this month and can be checked against it, which is the point of a fixed lab.

The month covers four full weeks and a few days, enough for a weekly pattern to repeat four times. Patterns that repeat are what baselines are built from, Module 8's subject.

Sysmon's first event is the earliest, three minutes after midnight on 13 February; Entra ID's last is the latest of the non-Linux sources, at 11:59. The few minutes' differences between sources are normal in real data and rarely matter.

tstats read the counts and the time span from the indexes' own records, the same generating command Section 0.1 used for its map. min and max of _time are a source's first and last events.

The same span for every source. A month is long enough to see what is normal for each source, days, weekdays, quiet nights, and short enough to search quickly in a browser.

max(_time) and min(_time) are statistics like count, applied to the time field. The lab shows both as dates; Section 3 shows what Splunk shows instead.

The exercise's result has a row per sourcetype with its first and last times, the shape of any data inventory. Run over every index at work, it shows how far back each source goes, which decides how far back any investigation can look.

The two sources in the exercise end within a minute of each other, just before noon. Sources that end at different times would mean a search across them reads unequal periods, worth knowing before comparing counts.

The completion exercise is max(_time). min and max of _time by source are the quickest way to learn the span of any data, in the lab or at work.

The month ends at midday on a Sunday, 15 March, which is why the lab's now sits there. Searches over the last few days of the month include a quiet weekend, worth remembering when comparing days.

Northgate Engineering is a fictional engineering company with about 810 staff, offices in Great Britain, Microsoft 365, Windows laptops, a set of Linux servers and a firewall at its edge. Its people, servers and network appear throughout the course, and their names are the ones in the events.

index=azuread category=SignInLogs
| stats dc(user) as accounts count

The identity table's first row is Rachel Okafor, the company's chief information security officer, in Manchester. She is one of the accounts with ten failed sign-ins in the month, an ordinary user's mistakes rather than an attack.

Named people in the company appear throughout: the security team, the IT director, staff whose accounts were attacked. Their names are part of the fiction and are used consistently, so a name met in Module 2 is the same person in Module 10.

The count beside the accounts, 8,203, is the figure Section 0.1 began with. Section 0.5 found 109 of the month's failures from abroad among these, and two attacks inside them.

The accounts include staff, guests from partner firms and service accounts, Section 0.3's three kinds of signer. Each kind behaves differently, and much of the course's work on identity is telling them apart.

101 accounts sign in interactively in the month. A course's data is a sample, chosen so that every kind of event and every attack the course teaches is in it, and small enough to search in a browser.

The 31 days run from Friday 13 February to Sunday 15 March. The three quietest are all weekend days: Saturday 14 February with 72 sign-ins, then 8 and 7 March.

The quietest day, 72 sign-ins, and the busiest, 425, differ by nearly six times. Any detection that counts per day has to allow for that range, or it will alert on busy weekdays and miss what happens on quiet weekends.

bin _time span=1d put each sign-in in its day, and the first stats counted per day; the second counted the days. Two stats in a row, the second counting the first's rows, is a pattern the course uses often.

The write exercise counts the days with sign-ins: all 31, from 72 sign-ins on the quietest day to 425 on the busiest. Every day has some, the weekends fewer, the ordinary rhythm that makes unusual activity stand out.

The company's names follow its conventions: people as initial and surname at ne.com, laptops named for their users such as NE-BENNETT-LT, servers by role and site. Learning a few of them early makes results quicker to read.

Splunk stores times as seconds since 1970 and shows _time as a date. When a statistic such as min or max is taken of _time, Splunk shows the result as seconds; the lab shows it as a date.

index=azuread category=SignInLogs
| stats min(_time) as first
| eval as_number=first+0, as_text=strftime(first, "%F %T")

The third column uses %F %T, the format the course uses whenever it shows a time as text. A consistent format makes times from different searches easy to compare by eye.

The earliest interactive sign-in is at 02:02 on 13 February, two hours into the month, a night-time sign-in of the kind a company with remote staff and partners abroad sees every night.

first+0 forced the value to be treated as a number, which shows what the lab stores. The display difference matters only when reading the result; it never changes a comparison or a calculation.

The same moment three ways. The difference is only in display: the value is the same number in both, and any search that formats it with strftime, or compares it with another time, gives the same answer in the lab and in Splunk.

The result, 02:02:22 on 13 February, is the same moment Section 3's search showed in three forms. One time, one text form, in any place a search runs.

The broken starter's first+0 is the number Splunk itself would show for min(_time), correct and unreadable. Formatting it is the fix in both places, so the lab's display difference never needs to be worked around.

%F %T writes the date as year, month and day with hyphens, and the time with colons. Splunk's documentation lists every such variable; the course introduces each as it needs it.

The fix formats the number as text, which reads the same in both places. Module 3 teaches strftime and the time formats it uses.

All times in the lab are in UTC. Splunk shows times in each user's time zone, set in their preferences, so the same event can show a different hour at work; strftime with %F %T writes the time in the zone the search runs in.

A lookup is a table of reference data, such as people and their departments, that searches combine with events to add what the events themselves do not record. The lab carries five.

| inputlookup identity
| stats count

A lookup table is only as current as its last update. In the lab the tables match the month exactly; at work, a person who joined last week may not be in the table yet, and a search that depends on it should allow for that.

The asset table holds 225 rows, the company's machines with their owner, operating system, category and priority. Between the two tables, most of the people and machines in the events can be named, which is what a lookup is for.

The identity table holds fewer rows than the 101 accounts that sign in. Some accounts, guests and service accounts among them, have no row, and a lookup on them finds nothing, a gap worth knowing before a search depends on the table.

inputlookup reads a lookup table as if it were events, which is how a table's contents are checked before a search depends on it. Module 5 shows the lookup command that joins a table's fields onto events.

97 rows in the identity table, one per person with a role the course needs. In a real deployment, tables like these come from HR systems and asset inventories; in the lab they are fixed, like the events.

Lookups are where a search adds what the events do not say: a person's department, a machine's owner, an address's country. Module 5 uses them to enrich results; Module 7 shows how they are defined.

In Splunk, now is the clock on the server that runs the search. A fixed month has no clock, so the lab sets now to the time of the newest event among the sources a search reads, and relative times such as the last 24 hours count back from there.

index=linux
| stats count as all_time
| appendcols [search index=linux latest=now | stats count as before_now]

latest=now is written in the base search, like the time ranges Module 2 teaches. A relative range such as earliest=-24h would count back from the same now, the newest event's time.

In a real deployment, the same search at different moments gives different answers, because now moves and data keeps arriving. In the lab it gives the same answer every time, which is what makes the course's figures reproducible.

The appendcols ran the second count as a separate search and put the two side by side. The difference of one is the whole effect of the range's end, which is small here and could be large on a busy source.

The newest Linux event is a session closing on a web server at 12:46, later than any other source's last event. That makes the lab's now for Linux searches about three-quarters of an hour later than for others, a detail that matters only to searches with relative time ranges.

5,331 of the 5,332 Linux events are before now. The newest one, at 12:46 on 15 March, is now itself for this search, and a time range ends just before its end time, as it does in Splunk. Searches that read other sources, whose newest events are just before noon, have a now a little earlier.

The third habit only affects reading. A first or last time shown as seconds in Splunk is the same value the lab shows as a date, and formatting it once removes the difference.

The second habit matters most when a search moves from the lab to a live deployment. A relative range there counts back from the moment it runs, so a search written for the lab's month with -24h would read yesterday at work, not 14 March.

The first habit is easy to avoid once known: the course never filters on source, and its searches name index and sourcetype instead, which works the same in both places.

All three habits come from the lab being a fixed, finished month. The course writes absolute dates where a time range matters, and formats times with strftime wherever it shows them.

The course writes absolute dates in its time ranges, earliest="03/05/2026:00:00:00" and the like, so that its searches mean the same day whichever sources they read. Relative ranges appear where the lesson is about relative ranges.

The lab runs the commands this course teaches, from search and stats to tstats, transaction and streamstats. A command it does not run stops the search with a message naming the command, rather than returning something wrong. Splunk has many more commands, and those in this course are the ones an analyst uses most.

The fourth rung is this section's purpose. Nine small differences, each known, cost nothing; any of them unknown could cost an afternoon at work.

The second rung is how the course's own lessons were written: one change, one run, one comparison. It is slower than writing a whole search at once and much faster than debugging one.

The third rung costs nothing in the lab and a little caution at work. In the console, a search that reads everything or sorts a month is harmless; on a shared Splunk, the same search uses resources others need, a point Module 10 makes with counts.

The first rung is the most important. A prediction written before a search runs turns every result into feedback: right, or wrong in a way that shows what was misunderstood.

The lab's engine is checked against Splunk's documentation for every command it runs, and its record of what it supports, and why, is kept with the course. When the lab and Splunk disagree on something this course teaches, the lab is fixed, as it was several times while this course was written.

Each search on a page has a Run button that runs it against the month. Many ask for a prediction first: choose the answer you expect, then run, and the explanation compares. The console button opens the search in the lab's query console, where it can be edited and run as often as you like; nothing you do there changes the month.

index=azuread category=SignInLogs
| eval weekday=strftime(_time, "%a")
| stats count by weekday
| sort - count

The count is of sign-ins, not people. A busy Friday could be more people signing in, or the same people signing in more often, and a distinct count by day would say which.

The weekend's two days together hold fewer sign-ins than any single weekday. Attacks that run at weekends, when fewer people are watching and fewer sign-ins hide them, stand out more against that quiet.

strftime with %a wrote each sign-in's day as a three-letter name, and stats counted per name. The sort put Friday first; sorting by the day's order instead would need the day's number, %u, a refinement later modules use.

The prediction is the point of the exercise. Friday leads by a margin, which few would guess without looking; being surprised by the month's own rhythm is a good first lesson in letting the data answer.

Exercises on each page ask you to complete, fix or write a search, and check the answer against the month. Practice questions at the end of each section ask for a number, which the search you write should produce.

The month holds several attacks: password guessing, a password spray, prompts sent to wear down a user's resistance to multi-factor sign-in, data taken from SharePoint, preparation for ransomware, and data sent out of the network. The course finds each with the searches it teaches, one module at a time.

Section 0.7 describes how the course climbs from first searches to the hardest, and Section 0.8 what it builds. From Module 1 onwards, every section is a set of searches on this month, and every number in the text came from running them.

The habits are four. Predict before you run, every time. Change one thing at a time and run again. Explore freely in the console. And remember the card of differences when you take a search to work.

Practice

Three questions about the lab, its people and its idea of now.

The second question is the lab's now in one number. Run it with and without latest=now and the difference is the one event at now itself.

Next, Section 0.7 describes how to learn SPL, and how the course climbs from basics to mastery.