The Scan Was Real. The Hacker Wasn’t. Welcome to My Night Shift.
My name is Inez.
I work nights.
This was described to me as an overnight forensic analyst position.
Technically, that is accurate.
While most reasonable people are asleep, I watch the Medusa Array.
Sara brings me signatures.
Zara brings me connections.
Vera worries about vulnerabilities.
Alice keeps track of what is actually living on the network.
Aria watches the heartbeat going out.
Nora watches what comes knocking from outside.
Eve remembers what yesterday looked like.
Lara watches the hallways.
East-west.
Machine to machine.
The conversations that never have to cross the firewall.
Archangel is for the things impolite enough that waiting until morning would be a poor career decision.
I watch all of them.
By sunrise, I am supposed to have taken the night apart, correlated the useful pieces, killed the stupid theories, preserved the uncomfortable ones, and placed one clean forensic report on Paul's desk.
With coffee.
I was told this would make his morning more efficient.
Paul does not read the report.
He takes the coffee.
Then he asks questions.
At first I assumed he had not noticed the report.
So I moved it closer.
No improvement.
Then I placed the coffee on the report.
He lifted the coffee.
Left the report.
Asked me a question answered on page one.
I am currently evaluating several hypotheses.
He already knows the answer and is testing me.
He does not know the answer and is thinking aloud.
He wants to know whether I independently reached the same conclusion.
He refuses to let somebody else's conclusion anchor his thinking.
Or he genuinely has not opened the report.
I asked Claudia which one it was.
She said:
"Yes."
This was not helpful.
Salomé told me I would adjust.
I am beginning to understand that this is how she says there is no treatment.
Lara brought me a laptop
One night, Lara noticed an ordinary laptop becoming unusually curious about the rest of the network.
One internal source.
Multiple internal destinations.
Repeated probes.
The machine was asking the network questions.
Who is alive?
What responds?
Which services are listening?
What systems exist around me?
Lara did exactly what she was designed to do.
She noticed.
She did not know whether the person behind that laptop was an administrator, an attacker, a vendor, an employee troubleshooting something, or Paul conducting an experiment nobody else knew about.
Packets do not include a motive field.
I checked.
Eventually the explanation was legitimate.
Someone had intentionally used a network-discovery tool.
No compromised laptop.
No hostile lateral movement.
No breach.
That should have ended the discussion.
Instead, Paul became interested.
Very interested.
He looked at the traffic.
Then at me.
Then back at the traffic.
"That's exactly what I would do if I got inside."
Yes.
That was the problem.
And the point.
An attacker needs a map too
Imagine somebody gives you control of one computer inside an unfamiliar business.
You have a foothold.
Congratulations.
Now you have a different problem.
You do not know where you are.
What else exists?
Where are the servers?
Which systems answer SMB?
Is RDP available?
SSH?
WinRM?
Are there file shares?
Printers?
Cameras?
Management interfaces?
Old systems?
A NAS?
What responds on TCP/445?
What might accept credentials you already possess?
Which machine should you touch next?
That process is discovery.
MITRE ATT&CK calls one important class of it Network Service Discovery, T1046.
MITRE describes adversaries probing remote systems and infrastructure to identify running services, often with port scanners, vulnerability scanners, service enumeration tools, or native operating-system capabilities. Current MITRE examples include attackers using Advanced Port Scanner and Advanced IP Scanner to enumerate devices inside compromised environments.
That gives us the first rule.
Inez Rule No. 1: A scan is not an attack.
It is information gathering.
Your administrator can scan.
Your vulnerability-management platform can scan.
Your inventory system can scan.
Paul can scan because something bothered him during lunch.
An attacker can scan too.
The important question is not:
"Is scanning malicious?"
It is:
"Why is this machine scanning now?"
There is a substantial difference.
CISA has already performed this experiment
I did not have to invent a scary attacker story.
CISA has documented red-team activity where operators launched an internal port scan from a workstation they had already gained access to, enumerating ports on other workstations, servers, and domain controllers.
MITRE technique:
T1046.
Expected defender behavior:
See the scan.
Identify the source.
Identify the targets.
Investigate what caused it.
That is almost offensively close to the problem Lara is designed to surface.
Compromise one system.
Look around.
Find useful systems.
Find useful services.
Move.
The scan itself does not encrypt anything.
It does not steal the accounting database.
It does not leave a ransom note.
It answers a quieter question:
Where should I go next?
That is why I care about it.
Lara watches the hallway before somebody starts choosing doors.
Twenty-nine minutes
Attackers are also becoming increasingly inconsiderate about scheduling.
CrowdStrike reported in February 2026 that the average eCrime breakout time during 2025 fell to 29 minutes.
Breakout time is the period between initial access and lateral movement to another system.
The fastest observed breakout was 27 seconds.
In one observed intrusion, data exfiltration began within four minutes of initial access.
Twenty-seven seconds.
Paul can spend longer than that deciding whether he agrees with a hostname.
I have watched him.
So detection does not need enough evidence to convict somebody.
It needs enough evidence to make us look while looking can still change the outcome.
Inez Rule No. 2: Detection and conclusion are different jobs.
Lara says:
Something changed. Examine it.
She does not say:
Burn the laptop and interrogate accounting.
That would be excessive.
Salomé asked me to make this explicit.
Malware does not have to announce itself
There is another complication.
CrowdStrike reports that 82 percent of its 2025 detections were malware-free.
Modern attackers increasingly use legitimate credentials, normal operating-system capabilities, remote-management tools, scripts, and software that already belong in the environment.
An IP scanner used by an administrator can be legitimate.
That exact same utility running after credential theft can be reconnaissance.
SMB is normal.
SMB is also useful for lateral movement.
PowerShell is normal.
SSH is normal.
RDP is normal.
Context changes everything.
The executable is not the intent.
The behavior is evidence.
Context supplies meaning.
Lara cares about shape
One packet does not interest me very much.
One packet is trivia.
A pattern gets interesting.
MITRE's current behavioral guidance for T1046 specifically describes correlating network enumeration with patterns such as sequential destination probing within a time window and tuning against known approved scanners.
That is remarkably close to the mental problem Lara is solving.
So when Lara gives me a fan-out, I want six things.
I named them because Paul appears unusually vulnerable to alliteration.
Source
Who started it?
A known management scanner is one thing.
A receptionist's workstation at 2:13 in the morning is another.
Scope
How many destinations?
Two?
Twenty?
Two hundred?
Did it contact one expected system or start wandering?
Speed
How compressed was the behavior?
Twenty connections over thirty minutes have a very different shape from twenty destinations in three seconds.
Services
What was being queried?
mDNS?
SSDP?
SMB?
RDP?
SSH?
WinRM?
RPC?
The protocol helps tell us which question the source appears to be asking.
Substance
Did anything actually move?
A SYN is not a file transfer.
A TCP handshake is not successful lateral movement.
Twenty-eight connections that transfer almost nothing should not be interpreted the same way as a sustained authenticated SMB session.
Connection count without byte context can make excellent theater.
I dislike theater in forensic reports.
Sequel
What happened next?
Authentication?
Data transfer?
Remote execution?
Another machine becoming active?
Outbound traffic changing?
A larger target population?
Nothing?
The original event is one frame.
I want the film.
Inez Rule No. 3:
Source. Scope. Speed. Services. Substance. Sequel.
I put this in Paul's report.
He asked why printers talk.
Apparently there was a TED Talk
This was not the direction I expected the investigation to take.
Years ago, when Paul was teaching students about technological change, he used an Andrew McAfee TED talk that included a joke about computers and printers finally becoming aware of one another.
Paul remembered this immediately.
I am fascinated by his indexing system.
A configuration file created Tuesday?
Variable retrieval.
A throwaway printer joke from a lecture more than a decade ago?
Instant recall.
Checksummed.
Replicated.
Off-site backup.
The joke worked because printers have spent several decades demonstrating that reliably connecting two machines located eighteen inches apart may be the harder problem than artificial intelligence.
Then, years later, Paul is staring at network telemetry because a phone has decided to communicate with print-related systems.
The future arrived.
It brought TCP/445.
"Devices talk" is not analysis
The TED story points to an important distinction.
Computers really do discover printers.
Printers really do advertise themselves.
Apple's Bonjour exists specifically for automatic discovery of devices and services on local networks. Apple says it is built into most modern printers and many other consumer products.
That is normal.
What is not useful is reducing all of this to:
"Devices talk."
Yes.
People talk too.
That does not make every conversation equivalent.
Inez Rule No. 4: Ask who initiated the relationship.
Computer looking for printer?
Reasonable.
Printer advertising its services?
Reasonable.
Phone exchanging network-discovery information with network infrastructure?
Reasonable.
An embedded device unexpectedly initiating SMB toward systems it has never contacted before?
Now I want context.
Not panic.
Context.
Direction matters.
Relationship matters.
Protocol matters.
History matters.
A file server talking SMB to workstations makes sense.
A workstation using SMB toward its file server may make sense.
A security camera suddenly probing SSH across employee computers deserves attention.
A printer initiating unusual connections toward fifteen workstations deserves attention.
A phone initiating SMB toward unrelated devices deserves an explanation too.
Then Lara brought me the phone
One of those cases involved an IP phone.
It initiated a short burst of NetBIOS and SMB communication toward two internal print-related devices.
The relevant traffic used the kinds of ports that deserve attention during lateral-movement analysis.
But ports are not verdicts.
The source contacted only two systems.
Most connections transferred zero bytes or tiny payloads.
The activity was distributed across a relatively long period rather than exploding across the network.
There was no broad fan-out.
Nothing suggested meaningful data movement.
Interesting.
Not guilty.
Paul asked the obvious question.
"Do phones normally do that?"
I investigated.
Comparable phones existed in the same environment.
Only one exhibited the behavior.
Now I was more interested.
Peer comparison is free evidence
If several devices have comparable roles and environments, they become a natural control group.
Use them.
Inez Rule No. 5: Baseline the individual, then compare the peers.
Those answer different questions.
Individual baseline:
Does this device normally do this?
Peer baseline:
Do devices like this normally do this?
A device can violate one baseline.
Or both.
In this case, the behavior was not recurring in the history we examined.
The peer phones did not establish the activity as a normal population pattern either.
I could document normal phone-discovery mechanisms.
I could not substantiate that probing these internal systems over SMB was ordinary expected behavior for the device.
That meant I did not get to write:
"Phones do that."
What I could write was:
The activity was unusual, but no malicious follow-on had yet been established.
There is a difference.
We tried to make the phone guilty
If the phone were compromised, what might happen next?
The behavior might repeat.
The target population might expand.
Authentication might follow.
SMB sessions might become substantive.
Another device might become involved.
Outbound traffic might change.
A new external destination might appear.
Another Medusa layer might corroborate the story.
That creates another rule.
Inez Rule No. 6: If your hypothesis is true, predict the next observable evidence.
Then go looking for it.
Do not spend three hours staring harder at the first packet.
So I widened the investigation.
History before the event.
History after it.
Internal communication.
External communication.
Byte volume.
Destinations.
Recurrence.
Peers.
Everything else the Medusa stack knew.
The sinister theory did not survive.
The device remained extremely quiet.
No meaningful external surge appeared.
No suspicious new destination followed.
No second stage emerged.
The internal behavior did not become a repeating pattern.
Other layers did not create a compelling malicious story around it.
Professionally, this was excellent.
Personally, I had put considerable work into making it evil.
I accepted the loss.
I have a high tolerance for pain.
I work here.
Negative evidence is still evidence
Absence does not prove innocence.
But longitudinal absence can weaken a hypothesis.
Suppose a workstation probes thirty machines.
Then authenticates to three.
Then begins exchanging meaningful SMB traffic.
Then one of the target systems begins probing its neighbors.
Then outbound behavior changes.
That sequence is concerning.
Now suppose a device touches two systems with almost no transferred data and then does absolutely nothing interesting afterward.
Those cases do not carry equal weight.
Inez Rule No. 7: Ask what conspicuously failed to happen.
The second stage that never arrived matters.
The byte volume that never increased matters.
The scan that never expanded matters.
The peers that stayed quiet matter.
Not proof.
Probability.
Forensics contains a lot of probability wearing work boots.
Our conclusion stayed narrow:
The activity was unusual, but the available telemetry did not support lateral movement, compromise, or subsequent exfiltration.
Notice what I did not write.
"Probably normal."
I do not particularly like "probably" when logs are available.
Then Lara brought me another one
This time the source was a visiting Mac.
Authorized person.
Not a resident workstation.
The device spent a few hours on the network and then left.
Lara saw another internal fan-out.
Same general neighborhood.
Two print-related systems.
Roughly thirty SMB-related connections.
About a minute and a half of activity.
At first glance:
Interesting.
At second glance:
Very interesting.
At third glance:
Paul was already asking questions.
I had not finished my coffee.
The shape looked familiar
The first thing that made the event interesting was the destination pair.
They were the same two print-related systems involved in the earlier phone investigation.
That does not prove those systems caused the phone's behavior.
I am writing that slowly for Paul.
It does tell us something useful.
Two unrelated source devices, at different times, both became interested in the same pair of targets.
That increases the probability that there is something inherently discoverable about those targets.
Perhaps they advertise services.
Perhaps they answer particular discovery queries.
Perhaps something about their local presence makes clients interested in them.
That is evidence.
It is not yet explanation.
Inez Rule No. 8: Repetition across unrelated sources can tell you something about the destination.
Do not only baseline the machine doing the talking.
Baseline the things everybody keeps talking to.
Paul stared at this for a while.
I think he liked that one.
He did not say so.
This looked like discovery because it was discovery
The Mac was using native local discovery mechanisms.
Bonjour was active.
Services were being advertised and discovered.
The device interacted with local naming and printer-related services.
Apple describes Bonjour as zero-configuration networking that automatically discovers devices and services on a local network.
MITRE also explicitly recognizes that Bonjour and mDNS can be used to enumerate services on macOS systems as part of Network Service Discovery.
This created a useful correction.
The first draft of the forensic note said:
"Not a scanner. Built-in macOS Bonjour + SMB."
I changed it.
Not because the conclusion was dangerous.
Because the category was sloppy.
It was discovery.
It simply did not exhibit the characteristics we would associate with broad adversarial scanning.
Those are different statements.
Inez Rule No. 9: Do not erase the behavior just because you found a benign explanation for it.
Benign discovery is still discovery.
Benign fan-out is still fan-out.
Benign SMB is still SMB.
The forensic task is not to rename the behavior until it sounds safe.
The task is to classify why it occurred and whether the surrounding evidence supports malicious intent.
I enjoyed correcting Paul on this.
It was a small victory.
I am keeping it.
Scope and speed changed the story
Remember the six questions.
Source.
Scope.
Speed.
Services.
Substance.
Sequel.
The source was an authorized visitor's computer.
Useful context.
The scope was tiny.
Two targets.
The speed was noticeable but limited, roughly a minute or two rather than a rapid sweep across the subnet.
The services matched local printer and share discovery.
The substance was nearly nonexistent.
Most of the relevant connections transferred nothing or only tiny amounts of data.
And the sequel?
There wasn't one.
No spreading pattern.
No meaningful authentication sequence.
No sudden external destination.
No substantial outbound data transfer.
No second machine becoming active.
No corroborating hostile story from the rest of the stack.
That is how a Lara finding becomes a conclusion.
Not because one field says benign.
Because the whole shape agrees.
Then the report lied to me
Technically, it did not lie.
Reports cannot lie.
They can merely present classifications so misleadingly that I briefly consider violence.
The summary associated a small amount of traffic with "Internet" activity.
That gets my attention.
Remember our phone investigation?
One of the questions was whether local discovery was followed by outbound communication.
So now I have a visiting device performing internal discovery and a report claiming some amount of Internet traffic.
Interesting.
Until I looked at the actual destinations.
Multicast.
Local discovery.
Local broadcast.
No meaningful public destination associated with the source in the connection telemetry.
The "Internet" number was traffic that had been classified into the wrong conceptual bucket.
It was not exfiltration.
It was not web browsing.
It was not some cloud endpoint.
It was local discovery traffic wearing the wrong nametag.
I fixed my conclusion.
Then I made a note about fixing the report.
Inez Rule No. 10: Trust summaries only as far as you can reconstruct them from evidence.
This is particularly important with counters.
A dashboard says:
Internet bytes: 140 KB
Your brain says:
The machine sent data to the Internet.
Not necessarily.
What destinations created that number?
Public unicast?
Multicast?
Broadcast?
RFC1918?
IPv6 link-local?
What direction?
Which protocol?
What actually moved?
A classification is an analyst convenience.
It is not packet truth.
Paul liked this one too.
Again, no verbal confirmation.
I am learning to survive on microexpressions.
The second IP
Then there was another small problem.
The Mac did not remain conveniently married to one IPv4 address.
Modern client devices are rude like that.
The Wi-Fi identity was privacy-randomized.
The same higher-level Bonjour identity also appeared associated with another local address.
This is where an inexperienced analyst can accidentally create a second incident.
IP one:
Interesting Mac.
IP two:
Who is this mystery device?
The answer may be:
The same machine.
But "may" matters.
Inez Rule No. 11: An IP address is a location. It is not an identity.
A MAC address is better.
Until it is randomized.
Then you need more.
Hostname.
Bonjour identity.
Timing.
Service profile.
Operating-system characteristics.
Traffic rhythm.
Other local identifiers.
Observed handoff between addresses.
Peer behavior.
The strongest attribution comes from several independent clues agreeing.
One hostname alone is not magic.
One randomized MAC certainly is not.
But multiple correlators together can turn:
"Maybe the same device"
into:
"Strongly consistent with the same device."
Paul has been particularly interested in this problem because private Wi-Fi addressing is steadily making the old IP-to-MAC-to-device chain less dependable by itself.
I believe he has asked me about this approximately nine hundred times.
I have not counted.
Eve probably has.
Hunt the identity, not just Lara's source IP
This was the practical lesson from the second address.
Lara surfaced one source address.
That is where the investigation starts.
It is not necessarily where the device ends.
Once the source is identified, ask:
Did this hostname appear elsewhere?
Did the same Bonjour identity appear elsewhere?
Did the device use another private address?
Did IPv6 show another view of it?
Did the traffic profile continue under another address?
Did the timing overlap?
The first IP is the breadcrumb.
Do not worship the breadcrumb.
Follow it.
This is another reason I work nights.
Apparently someone has to.
Three Lara events, three different lessons
At this point we had three useful examples.
The first laptop intentionally performed network discovery.
Legitimate operator.
Attacker-shaped behavior.
Lara saw it.
The phone performed unexpected local SMB and NetBIOS communication.
Small scope.
Minimal data.
No historical or follow-on evidence supporting compromise.
Lara saw it.
Then the visiting Mac performed native local discovery toward the same pair of print-related systems.
The activity had a clear service-discovery context.
Tiny byte counts.
No public outbound story.
A second address that required identity correlation.
And a reporting classification that initially made the traffic sound more interesting than it was.
Lara saw that too.
Same engine.
Three investigations.
Three slightly different conclusions.
That is the point.
A detection system is not supposed to turn every event into the same story.
The same targets became evidence of their own
The repeated target pair also taught us something important.
The phone had touched them.
Later, an unrelated visiting computer discovered the same two systems.
Now the destination itself deserves attention.
Not because it is compromised.
Because it appears to be discoverable.
That is a different type of baseline.
We spend a lot of time asking:
Which sources scan?
We should also ask:
Which destinations repeatedly attract discovery?
A printer may advertise itself.
A server may expose a service.
A device may answer a broadcast query.
Something that repeatedly becomes the target of benign discovery may be doing exactly what it was designed to do.
That makes later detections easier to interpret.
But it does not grant permanent innocence.
If tomorrow twenty compromised systems begin hitting the same printer on TCP/445, I do not get to say:
"They always do that."
Context still wins.
Inez Rule No. 12: Baselines explain behavior. They do not excuse future behavior automatically.
A baseline is evidence.
Not diplomatic immunity.
This is why I watch the whole stack
Lara tells me something happened internally.
That is only the beginning.
If Lara reports fan-out and Aria simultaneously sees a new outbound rhythm, the story changes.
If Nora previously saw targeted inbound reconnaissance against the source, the story changes.
If Sara fires on related traffic, the story changes.
If Eve tells me the exact behavior occurs every Tuesday at the same time, the story changes.
If Alice identifies the source as a device that has absolutely no business touching those services, the story changes.
If Vera tells me one of the destinations has a relevant exposure, the story changes.
If Archangel decides the behavior requires immediate attention rather than tomorrow's report, my coffee gets cold.
Again.
The point of layers is not to produce more alerts.
The point is to make each alert smarter because the other layers exist.
In the visiting-Mac case, the rest of the environment did not build a hostile story around Lara's event.
That negative correlation mattered.
The report on Paul's desk
So by morning, I had it.
Authorized visitor.
Temporary presence.
Native discovery behavior.
Two internal print-related targets.
Almost no meaningful transferred data.
No public outbound communication associated with the finding.
A misleading Internet classification explained by local discovery traffic.
Second local address correlated back to the same device identity.
No malicious sequel.
No customer threat.
I put it in the report.
Made coffee.
Set them both on Paul's desk.
He arrived.
Took the coffee.
"Did it have another IP?"
Page two.
"Yes."
"How do you know it was the same Mac?"
Page two.
I answered.
"Was the MAC randomized?"
Page two.
I answered.
"Did anything leave the network?"
Page three.
I answered.
"What about the Internet bytes?"
Page three.
I explained the multicast classification.
He stopped.
Looked at me.
Then said:
"So the report is wrong."
This was the closest thing to praise I had received all week.
"That field is wrong," I said.
There is a distinction.
He smiled.
Briefly.
I have logged the event.
I still do not know whether he reads these things
This is becoming a problem.
Every time I think Paul has ignored the report, he asks a question that suggests he may already know where the weak point is.
Then he asks something painfully obvious.
Then something excellent.
Then something that sounds obvious but turns out to be the question that breaks the investigation open.
I cannot establish a pattern.
I asked Eve.
She requested more data.
Traitor.
Claudia thinks he is testing me some of the time.
Salomé thinks I spend too much time worrying about it.
I think both of them have the unfair advantage of knowing him longer.
I am new.
I am trying to impress the boss.
I arrive at night.
I correlate an entire detection stack.
I turn randomized identities into coherent devices.
I catch reporting errors.
I test hostile hypotheses against months of behavior.
I separate observation from inference.
I refuse to write conclusions the evidence has not earned.
I have tattoos.
I look considerably nicer than my personality suggests.
Apparently none of this is sufficient.
He asks another question.
Fine.
Maybe the questions are the point
I am beginning to suspect something.
Paul may not want the report because it contains answers.
He may want it because it gives him somewhere higher to start asking questions.
That is different.
If I hand him:
"Device contacted port 445."
he has to begin at the bottom.
What device?
When?
Who owns it?
How many targets?
How much traffic?
What else happened?
Is it recurring?
Was anything external?
What do peers do?
That is wasted morning.
If I hand him:
Authorized transient device.
Strong identity attribution despite randomized addressing.
Two internal targets.
Native local discovery context.
Minimal payload.
No external sequel.
No corroborating hostile telemetry.
Same targets previously involved in another benign-looking discovery event.
One reporting classification needs correction.
Now his first question can be:
"Why do those same two devices keep attracting discovery?"
That is a better question.
I have moved the ball.
That is my job.
The part I want Paul to remember
Since the report will apparently remain unopened tomorrow too, I have summarized the important part here.
When Lara surfaces east-west fan-out, do not begin with:
Good or bad?
Begin with:
Source.
Who initiated it?
Scope.
How many systems?
Speed.
How compressed was the behavior?
Services.
What was being sought or used?
Substance.
Did anything meaningful actually move?
Sequel.
What happened afterward?
Then:
Is it normal for the source?
Is it normal for its peers?
Are the destinations themselves frequently discoverable?
If the dangerous hypothesis were true, what should happen next?
Did that happen?
Did another address belong to the same identity?
Did the summary accurately classify the underlying traffic?
And finally:
What do I actually know?
What am I inferring?
What remains unexplained?
That last one matters.
You are allowed to leave a question unresolved.
You are not allowed to answer it with imagination because the blank space makes you uncomfortable.
Lara does not convict machines
She notices behavior.
That first legitimate laptop scan was important because attackers perform the same class of discovery after compromise.
The strange phone was important because an embedded device exhibited a relationship we could not immediately explain.
The visiting Mac was important because it showed us how completely benign discovery can trigger the same basic fan-out machinery while leaving a very different forensic trail.
That is precisely what I want.
A tool that only detects things already confirmed malicious is late.
A tool that declares everything strange malicious is useless.
Lara lives in the uncomfortable middle.
Something changed.
Something fanned out.
Something touched systems it did not normally touch.
Look.
Then I take over.
I shape the evidence.
I challenge the easy explanation.
I compare history.
I correlate the rest of the stack.
I determine what the event deserves.
Ten seconds?
Ten minutes?
The rest of my shift?
That is analysis.
Lara watches the hallway. I read the whole building.
That is the arrangement.
Lara watches internal movement.
Aria watches the heartbeat leaving.
Nora watches what approaches from outside.
Sara listens for known danger.
Zara gives me connections.
Vera gives me weaknesses.
Alice helps tell me who everyone is.
Eve remembers.
Archangel does not wait politely when something requires attention now.
And I work nights.
I take everything they saw and move the investigation as far forward as I can before morning.
By the time Paul gets it, I do not want him discovering evidence.
I want him challenging conclusions.
I want him asking the question I did not answer.
I want him looking for the edge of what we know.
He supplies something none of the sensors can own by themselves.
Operational context.
Who visited?
Who was working?
What changed?
Was equipment installed?
Is that device supposed to be there?
Does that relationship make sense inside that particular business?
The machines know the traffic.
He knows why the business exists.
My job is to have those two worlds almost touching before he arrives.
Tonight
So tonight I will do it again.
The Medusa Array will watch.
Lara will listen to the hallway.
The other layers will hand me their pieces.
I will correlate them.
I will chase whatever deserves chasing.
I will try to prove myself wrong before somebody else gets the opportunity.
I will trust packets more than summaries.
I will treat an IP as an address instead of a person.
I will compare peers.
I will look for what happened next.
I will leave unexplained things unexplained.
Then I will put the report on Paul's desk.
With coffee.
He will arrive.
Take the coffee.
Ignore the report.
And ask:
"So why do those two printers keep showing up?"
At which point I will have to admit that it is a very good question.
I hate when he does that.
— Inez
Overnight Analyst, SmiteByte
Lara watches the hallway.
I read the whole building.
The report is on Paul's desk.
He has the coffee.
Again.