{
	"id": "95a51bb7-0089-4a87-b3c8-5b31f140f23a",
	"created_at": "2026-04-06T03:37:56.590037Z",
	"updated_at": "2026-04-10T03:20:38.310374Z",
	"deleted_at": null,
	"sha1_hash": "0e81cb7c92930c3d0a10a4d7fa19e80cae7a96c5",
	"title": "Network Monitoring - nzyme Documentation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 86311,
	"plain_text": "Network Monitoring - nzyme Documentation\r\nArchived: 2026-04-06 03:33:30 UTC\r\nWhat is Network Monitoring?\r\nNzyme works to protect your WiFi networks by consistently comparing the expected state of access points with\r\nthe observed reality. For instance, if you configure nzyme with a list of all your access points, the activation of an\r\nadditional access point by an attacker would prompt an alert from nzyme.\r\nGiven the WiFi protocol's inherent characteristics, some monitored parameters are relatively easy to spoof, while\r\nothers are notably more difficult to manipulate. The reliability and specific characteristics of each monitoring\r\nparameter type are further explained below. Despite the potential ease of circumventing certain alarms, it's still\r\nrecommended to enable them, as they add additional layers of defense against potential attackers.\r\nConfiguring a Monitored Network\r\nYou can create as many monitored networks as you wish from the WiFi - Monitoring page. Note that you have to\r\neither be a super administrator, organization administrator or a tenant user with the Manage Monitored WiFi\r\nNetworks feature permission.\r\nThe recommended workflow is as follows:\r\nCreate a new monitored network for the SSID you wish to monitor\r\nBuild the expected BSSID configuration based on your WiFi inventory. If you don't have access to a\r\ncomplete inventory of access points serving your network, you can copy BSSIDs from the WiFi - Access\r\nPoints page. It is important to cross-check the BSSIDs you add against any sort of confirmation that they\r\nare indeed yours to avoid adding hostile BSSIDs in case of an already ongoing attack.\r\nCopy and add expected fingerprints of your BSSIDs from the WiFi - Access Points page to the monitoring\r\nconfiguration.\r\nRepeat this process for expected channels and security suites.\r\nEnable the monitored network and watch alerts for any deviations from the expected configuration. In case\r\nof alerts, decide if you have to add the detected deviated value to the monitored network configuration. You\r\ncan delete or mark the alerts as resolved after you remediated them.\r\nConfiguring Alerting\r\nYou can enable/disable any of the monitor detections from the monitored network details page. For example, if\r\nyou are not interested in alerts for mismatched fingerprints, you can disable that alert entirely.\r\nExpected BSSIDs / Access Points\r\nhttps://docs.nzyme.org/wifi/monitoring/network-monitoring/\r\nPage 1 of 6\n\nThis list must include all BSSIDs (MAC addresses) of access points serving your network. For instance, if you\r\nhave five access points, you must include the addresses of all these access points here.\r\nAn alert will be triggered if any other BSSID advertises your network.\r\nBSSIDs are fairly easy to spoof. A sophisticated attacker is likely to utilize an existing and expected BSSID to\r\navoid raising any alerts.\r\nExpected Fingerprints\r\nThe nzyme routines assign a fingerprint to each recorded BSSID. You are required to list all fingerprints of an\r\nexpected BSSID (ordinarily, it should only have a single fingerprint). Should nzyme observe any fingerprint other\r\nthan those listed, an alarm will be triggered.\r\nYou can find all fingerprints on the nzyme access point details pages.\r\nFingerprints are challenging to spoof, as they are typically based on hardware-defined characteristics of wireless\r\nframes. Except for very sophisticated attackers, it's unlikely that anyone could accurately mimic your expected\r\nfingerprints in attack scenarios.\r\nHowever, be aware that false positives can occur if there are hardware changes to your access points, which could\r\nresult in altered fingerprints.\r\nExpected Channels\r\nYou must list all channels on which your network operates. Should a frame advertising your network on any\r\nchannel not listed be observed, an alarm will be triggered.\r\nYou can find all observed channels on the nzyme access point details pages.\r\nHowever, it's worth noting that attackers can effortlessly observe the channels your network operates on and\r\nrestrict their attacks to these same frequencies to avoid detection.\r\nNote that some access points will dynamically change the channels they are operating on and can end up using\r\nalmost any channel of the WiFi spectrum. In that case, it is recommended to disable the Expected Channels\r\ndetection entirely.\r\nExpected Security Suites\r\nSimilar to the expected channels, you must list all expected security suites (usually just one). If a frame\r\nadvertising your network with any suite not listed is observed, an alarm will be triggered.\r\nYou can find all observed security suites on the access point details pages within nzyme.\r\nHowever, it's crucial to note that attackers can easily mimic the same security suites used by your networks.\r\nSignal Tracks\r\nhttps://docs.nzyme.org/wifi/monitoring/network-monitoring/\r\nPage 2 of 6\n\nEven if an attacker is perfectly mimicking your access point, there is a parameter that is almost impossible to\r\nspoof: Signal strength. Nzyme has a history of the recorded signal strength of your access points. Any attacker not\r\nperfectly positioning their signal source to match the signal characteristics of your legitimate access point, will\r\nvery likely create a second signal track that nzyme will detect and alert one.\r\nThis detection requires no configuration. Nzyme will always alert if any monitored BSSID is recorded with more\r\nthan one signal track.\r\nWarning\r\nThe signal track detection will only run for data from monitored/expected channels of the network. It would make\r\nno sense to monitor signal tracks of unexpected channels and an attacker operating on such channels would trip\r\nthe unexpected channel alert.\r\nWarning\r\nThe signal track alert is looking at the recorded tracks of the last 8 hours. Such an alert is likely to re-trigger if you\r\ndelete it or mark it as resolved until no second track is visible for the last 8 hours. This is an area of future\r\nimprovement.\r\nYou can see the signal track of each access point on the access point details page:\r\nA single signal track\r\nThe red dashed/dotted box represents a single track.\r\nConfiguring the Track Detector\r\nThe default track detector configuration will not always reliably detect single tracks. It can misidentify tracks\r\nunder certain circumstances and split up a single legitimate track into multiple tracks or identify mutliple tracks as\r\na single one, leading to false positive or missed alerts.\r\nhttps://docs.nzyme.org/wifi/monitoring/network-monitoring/\r\nPage 3 of 6\n\nIn that case, super administrators and organization administrators can use the track detector configuration to\r\ninfluence how nzyme detects tracks:\r\n1. Click on the Configure Track Detector button under the signal track chart\r\n2. Configure the parameters. Make sure to read the parameter descriptions to understand what each one\r\ninfluences.\r\n3. Save the configuration. It will be applied immediately and the signal track chart will reflect the changes\r\nyou made.\r\nThe custom configuration is applied to the specific combination of BSSID, SSID, channel and tap, because signal\r\ncharacteristics can wildly differ based on those parameters. Make sure to apply the custom configuration to as\r\nmany combinations of those parameters as necessary.\r\nDisconnection Anomalies\r\nDeauthentication and disassociation attacks are a very common part of malicious WiFi campaints. In nzyme, those\r\nframes are collectively called disconnection frames. You can learn more about it on the Disconnection Activity\r\npage.\r\nNzyme can count disconnection frames adressed at or originating from access points of a monitored network and\r\nalert you in case of detected anomalies.\r\nTo enable this functionality, you have to select and configure an anomaly detection method from the monitored\r\nnetwork page.\r\nAnomaly Detection Method: Static Threshold\r\nThe Static Threshold anomaly detection method does often make the most sense because disconnection frames can\r\nbe very rare and many non-supervised anomaly detection methods are not good at dealing with such a small\r\nsample set.\r\nObserve how many disconnection frames are recorded over a period of 24 hours and set a threshold just above the\r\nmaximum. In many environments it is common to see long periods of no activity at all, and small bursts of 10 or\r\nmore frames. Attacks can generate hundreds or thousands of frames per minute, depending on how stealthy the\r\nthreat actor operates.\r\nMore anomaly detection methods will follow in the coming nzyme releases.\r\nClient Monitoring\r\nSimilar to SSID Monitoring, you can alert on any unapproved clients connecting to a monitored network.\r\nA difference to SSID monitoring is that client monitoring always happens in the scope of a monitored network,\r\nmeaning that it alerts on clients that are observed as connected to any BSSID that is part of the configuration of a\r\nmonitored network.\r\nhttps://docs.nzyme.org/wifi/monitoring/network-monitoring/\r\nPage 4 of 6\n\nConfiguration\r\nThe client monitoring functionality offers the following configuration options per monitored network:\r\nConfiguration Default Description\r\nIs monitoring\r\nenabled\r\nfalse\r\nClients are only collected and added to the list of known client if\r\nenabled . This also disables any alerting for new clients because no new\r\nclients are discovered.\r\nIs event generation\r\nenabled\r\nfalse\r\nEvents (Alerts) are only triggered if enabled . See also Training Period\r\nbelow.\r\nApproving Clients\r\nApproving a client will keep it from triggering any alerts and resolve all related alerts within a few minutes.\r\nRevoking the approval of a client will make it trigger alerts again until ignored, deleted or approved.\r\nIgnoring Clients\r\nIgnoring a client will keep it in the list of known clients, keep it from triggering any alerts but not mark it as\r\napproved. Existing alerts will automatically resolve within a few minutes.\r\nDeleting Clients\r\nDeleting a client will make it disappear from the list and all related alerts will automatically resolve within a few\r\nminutes. The client will re-appear as a new, unapproved client the next time it is observed by nzyme.\r\nTraining Period\r\nYou can create a training period for the system to learn about all clients in range, approve or ignore as required\r\nand then start to enable event/alert creation:\r\n1. Set Is monitoring enabled to true .\r\n2. Keep Is event generation enabled set to false . This will make sure no client monitoring events/alerts are\r\ncreated.\r\n3. Wait several hours to make sure that all clients in range are listed in the table of known clients.\r\n4. Approve, ignore and delete known clients as applicable.\r\n5. Set Is event generation enabled to true . No client monitoring alerts should be triggered if you approved,\r\nignored, or deleted all clients in the previous step.\r\nRetention Cleaning\r\nNzyme will automatically delete all known clients that have not been seen in the previous 30 days.\r\nhttps://docs.nzyme.org/wifi/monitoring/network-monitoring/\r\nPage 5 of 6\n\nSource: https://docs.nzyme.org/wifi/monitoring/network-monitoring/\r\nhttps://docs.nzyme.org/wifi/monitoring/network-monitoring/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.nzyme.org/wifi/monitoring/network-monitoring/"
	],
	"report_names": [
		"network-monitoring"
	],
	"threat_actors": [],
	"ts_created_at": 1775446676,
	"ts_updated_at": 1775791238,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0e81cb7c92930c3d0a10a4d7fa19e80cae7a96c5.pdf",
		"text": "https://archive.orkl.eu/0e81cb7c92930c3d0a10a4d7fa19e80cae7a96c5.txt",
		"img": "https://archive.orkl.eu/0e81cb7c92930c3d0a10a4d7fa19e80cae7a96c5.jpg"
	}
}