Signs of compromise, the limits of detection tools and the role of honeypots.
A network scan can be a routine maintenance check or the first step of an attack. An unusual login can come from a reconfiguration or from compromised credentials.
Security tools can detect many of these events, but detecting an anomaly does not necessarily mean recognizing a threat.
How can you tell whether your company network has been breached, and how do you separate the signals that matter when you have no Security Operations Center (SOC) or staff dedicated to continuous alert analysis?
In short: no single indicator proves a breach. The most useful signs are unknown accounts or devices, security tools switched off, internal scans, logins to unusual systems and files that suddenly become inaccessible, to be assessed together and in context. Without a SOC, one more signal is any access to a decoy resource (a honeypot), which nobody should use.
There is no single signal
Initial access is not always obvious. A threat can use valid credentials, exploit services that are already there or perform operations that look like normal administration.
The monthly Operational Summaries of Italy's National Cybersecurity Agency (ACN) list, among the most common initial access routes in the incidents analyzed, the use of valid credentials that were previously compromised, exploitation of vulnerabilities and compromised remote-access services.
For this reason, no single indicator is generally enough to show that a network has been compromised.
Detection tools such as EDR (Endpoint Detection and Response), IDS (Intrusion Detection System) and NDR (Network Detection and Response) can spot anomalous behavior. However, the meaning of an event often depends on context: who performed the operation, from which system, at what time and in relation to which other activities.
The distinction matters: a logged event is not necessarily an anomaly, an anomaly is not necessarily an attack, and an alert is not, on its own, proof of compromise.
Signs of intrusion in a company network: what to look for
Some behaviors deserve particular attention, especially when they do not match the usual activity of the network.
Signs visible to users:
- unknown devices or accounts;
- passwords changed for no reason;
- security tools switched off;
- files suddenly inaccessible or encrypted;
- unusual slowdowns.
They can have mundane causes, but they should be checked.
Signs visible only in logs and security tools: host and port scans, logins to unusual systems, requests to many shares, unexpected access to files and credentials, anomalous directory queries. They are the typical behavior of someone who, after gaining a first foothold, explores the network: the phase the MITRE ATT&CK framework calls Discovery, where the adversary tries to figure out the environment. Each one is described in detail in Internal reconnaissance: how to tell when someone is exploring your network.
Detecting them requires logs, monitoring systems and security tools, as long as the necessary collection and visibility are in place. Their relevance grows when several events occur in sequence or do not fit normal business operations.
Detection is not enough: interpreting alerts in an SME without a SOC
An IT manager who receives a notification about an internal scan has to check the source, the device, the scheduled activities and the logs. The scan may be legitimate, or it may show that someone, after a first foothold, is looking for other systems. The technology detected the event, but the assessment still requires human intervention or further correlation tools.
In an organization with a SOC, this work can go to specialized analysts. In an SME, it may fall to one or a few people who also run day-to-day IT.
The problem becomes operational: how many signals can realistically be checked, and how quickly?
A high number of alerts does not guarantee a better ability to detect attacks. If notifications are too many or too hard to interpret, the risk grows that the important ones get overlooked.
This is why the quality and specificity of the signal matter as much as the quantity of events collected.
Honeypots: a high-confidence signal
There is a different approach, complementary to traditional detection: the honeypot. A honeypot is a decoy resource: a system that looks interesting to a potential threat but that nobody in the organization has any reason to use. Placed in the network, it turns any contact with it into a signal worth checking.
Imagine a server that appears to hold company backups. It is visible on the network but performs no real operational function. No employee should use it and no business application should connect to it.
If someone tries to access it, the event takes on a particular meaning.
Unlike a connection to a normal company server, contact with a decoy should not be part of the organization's daily activity.
An interaction can still come from an authorized scanner or from a mistake, but the possible legitimate explanations are far fewer.
This makes it possible to generate signals that are generally high-confidence, reducing the work needed to tell suspicious activity from the normal running of the network.
A honeypot does not automatically recognize every intrusion and cannot detect a threat that never interacts with the decoys. Its value is in adding a different kind of signal, particularly useful when the time available for analysis is limited.
How Hoxey applies deception: honeypots, decoys and breadcrumbs
Hoxey is an Italian cyber deception solution for SMEs: it detects threats already inside the company network through interactive honeypots, hosted in its own cloud infrastructure but presented inside the customer's network as local resources.
A connection device forwards traffic destined for the decoy through an encrypted tunnel. The architecture allows responses to return to the connections received, but blocks any new connection from the decoy toward the company network.
This isolation is designed to prevent a compromised honeypot from being used as a starting point to reach other customer systems.
The platform also includes breadcrumbs: clues and decoy resources placed on endpoints, which can draw the attention of a threat or generate a signal when they are accessed.
A deception network then makes it possible to extend the interaction with further fictitious systems, keeping the threat's activity away from real resources.
The goal is not to monitor all company traffic, but to increase the chances that hostile activity meets a controlled resource and produces a meaningful signal.
The isolation architecture is explained further in the Hoxey Security Model.
To understand how this differs from traditional tools, see also Honeypot vs IDS: what each one actually detects, and why you may need both.
What to do if you suspect a breach: five checks
If a possible sign of compromise emerges, the first steps are to isolate the suspect system, preserve the logs and notify whoever manages IT. If the alert comes from a Hoxey honeypot, the guide Identify a compromised host explains how to trace the device from the IP address in the event. How to assess an out-of-hours alert is covered in Security alert at 3 a.m.: act now or wait?.
Even without an in-house SOC, you can assess your ability to recognize suspicious activity with a few questions:
- Visibility: can we spot internal scans, unusual logins and unexpected access to resources?
- Reconstruction: do the available logs let us link different events and reconstruct a sequence of activity?
- Responsibility: who receives and checks the alerts? Is there a procedure to decide which ones need immediate attention?
- High-confidence signals: do we have credible decoy resources that can flag unexpected interactions?
- Response: do we know which checks to start and which actions to take when a possible sign of compromise emerges?
The first three questions are about the ability to observe and interpret what happens. The fourth introduces a complementary detection channel. The fifth is about turning a signal into an operational response.
You do not need the same security infrastructure as a large organization. But it is important to know your visibility limits and to decide how to handle the events that may indicate a threat.
Frequently asked questions
How can I tell if my company network has been breached?
Possible signs include unusual scans, anomalous login attempts, unexpected access to files and systems, resource enumeration and activity that does not fit an account's usual behavior. None of these on its own proves a compromise: you need to consider the context and, where possible, correlate them with other events.
What should I do if I suspect my network has been breached?
Isolate the suspect system without switching it off, preserve the logs, note the time and host involved and notify whoever manages the infrastructure. In-depth analysis can follow later.
Can a honeypot detect a threat inside the network?
A honeypot can flag an interaction with a resource that should not be used in normal business activity. This generally makes the signal more specific than many anomalies detected by traditional tools. It cannot, however, detect activity that does not involve the decoys.
Does a honeypot replace EDR, IDS or NDR?
No. Traditional tools observe endpoints, traffic or behavior to identify suspicious activity. A honeypot adds a detection channel based on interaction with a decoy resource. The two approaches are complementary.
Can you improve detection without a SOC?
Yes. Better alert selection, adequate log collection, defined verification procedures and the use of high-confidence signals can make threat detection more manageable. The most suitable solution depends on the size of the infrastructure and the resources available.
Summary
Noticing that someone has entered the company network does not depend only on how many events you manage to log.
It also depends on being able to recognize the significant ones, interpret them and step in in time.
Traditional tools give visibility into many activities, but they can require a considerable amount of analysis. Decoy resources introduce a different signal: an interaction with a system that should not be used.
Deception does not remove the need to monitor and protect the network. But it can help make some hostile activity easier to recognize, even in organizations with limited security resources.
To assess the characteristics of a deception solution, see the five questions to ask before choosing a honeypot.