In an earlier project, I built a small Python utility for investigating the hidden network activity of a Windows PC. In case you have not read the original article, here is the link: Tracking Your PC’s Hidden Connections with ipconfig /displaydns
The basic idea was simple: Windows maintains a DNS resolver cache, and by running:
ipconfig /displaydns
we can see domains that the computer has recently resolved.
That simple technique is surprisingly useful.
A computer may be communicating with dozens or even hundreds of domains without the user explicitly opening those websites. Browsers, applications, Windows services, update mechanisms, cloud applications, background processes, and potentially malicious software can all generate DNS activity.
However, there is an important limitation.
DNS cache information is not the same thing as live network connection monitoring.
The original program was therefore useful as a lightweight investigation tool, but it can be taken much further.
In this upgraded version, the goal is to build a broader Network Intelligence and Command-and-Control (C2) Detection capability using Python.
Instead of simply asking:
"What domains has this PC recently resolved?"
the program can begin answering:
"Which process is communicating with which destination, what domain is associated with it, is that destination suspicious, and does the activity correlate with other security events?"
1. The Original Approach
The original Python program was based around the Windows DNS cache.
Python can execute:
import subprocess
result = subprocess.run(
["ipconfig", "/displaydns"],
capture_output=True,
text=True
)
print(result.stdout)
This retrieves information from the Windows DNS resolver cache.
A typical record contains information such as:
Record Name . . . . . : example.com
Record Type . . . . . : 1
Time To Live . . . . : 120
Data Length . . . . . : 4
A (Host) Record . . . : 93.184.xxx.xxx
From this information, a Python application can extract:
Domain name
Record type
TTL
IP address
The program can then display the information in a table or export it for further analysis.
For troubleshooting and basic security investigation, this is already useful.
But there is much more information available on a Windows endpoint.
2. DNS Cache Is Not Live Network Monitoring
Before expanding the program, it is important to understand the limitation of ipconfig /displaydns.
The command shows information currently retained in the Windows DNS cache.
It does not necessarily tell us:
Which process made the DNS request
Whether the connection is still active
Which local port is being used
Which remote port is being used
Whether the communication uses TCP or UDP
Whether the process is legitimate
Whether the application connected directly to an IP address
How long the connection lasted
Whether the connection was encrypted
Therefore, the upgraded program should not simply be called a "hidden connection monitor."
A better description is:
Network Intelligence
The objective is to combine several sources of endpoint information.
DNS
│
├── Domain
├── Resolved IP
└── DNS activity
│
▼
Network Connections
│
├── Local IP
├── Local Port
├── Remote IP
├── Remote Port
└── Protocol
│
▼
Process
│
├── PID
├── Process Name
├── Parent Process
├── Command Line
└── File Hash
│
▼
Threat Intelligence
│
├── IOC
├── Reputation
└── Detection Rules
│
▼
Correlation
│
▼
Risk Score / Alert
This produces much richer security information.
3. From a Python Utility to a Security Sensor
The original application was essentially a utility that collected information when the user requested it.
The upgraded architecture can operate more like a security sensor.
Windows PC
│
┌──────────┼──────────┐
│ │ │
DNS Processes Network
│ │ │
└──────────┼──────────┘
│
Python Collector
│
Normalize Events
│
Local Buffer
│
▼
Security Server
│
┌──────────┼───────────┐
│ │ │
Detection Correlation IOC
│ │ │
└──────────┼───────────┘
│
Database
│
▼
Security Dashboard
The important architectural principle is that the endpoint collects telemetry while the central system can perform more expensive analysis and correlation.
4. Collecting DNS Information
DNS information remains one of the most useful sources.
The program can convert raw Windows information into structured events.
Instead of storing:
ipconfig /displaydns
output as a large block of text, the application can generate something like:
{
"event_type": "dns_observation",
"domain": "example.com",
"resolved_ip": "93.184.xxx.xxx",
"timestamp": "2026-08-21T15:32:10"
}
Structured telemetry makes the information easier to:
Search
Filter
Correlate
Store
Enrich
Detect against
The DNS cache therefore becomes one source of network intelligence rather than the entire monitoring system.
5. Adding Live Network Connections
The next major improvement is to collect actual network connection information.
Windows can provide information such as:
Local Address
Local Port
Remote Address
Remote Port
Protocol
Connection State
PID
Conceptually:
TCP
192.168.1.25:52144
│
▼
185.xxx.xxx.xxx:443
│
▼
PID 4216
The PID is particularly important.
It allows the network connection to be associated with the process responsible for it.
For example:
PID: 4216
Process: powershell.exe
Remote IP: 185.xxx.xxx.xxx
Remote Port: 443
Now the program knows considerably more than simply:
"The computer connected to 185.xxx.xxx.xxx."
It knows:
"powershell.exe created a connection to 185.xxx.xxx.xxx:443."
That is much more useful from a security perspective.
6. Process-to-Network Correlation
This is where the project becomes significantly more powerful.
Imagine that the endpoint reports:
Process Created
powershell.exe
PID: 4216
Parent: winword.exe
A few seconds later:
Network Connection
PID: 4216
Remote: 185.xxx.xxx.xxx:443
And DNS telemetry reports:
Domain:
suspicious-example.com
Resolved IP:
185.xxx.xxx.xxx
Instead of treating these as three unrelated events, the detection system can correlate them.
The result could be displayed as:
HIGH RISK ACTIVITY
WINWORD.EXE
│
└──► powershell.exe
│
└──► suspicious-example.com
│
└──► 185.xxx.xxx.xxx:443
This type of relationship is far more useful than a simple list of DNS records.
7. Why Process Attribution Matters
An IP address alone does not tell the entire story.
For example:
chrome.exe → 142.250.xxx.xxx:443
could be completely normal.
But:
rundll32.exe → 185.xxx.xxx.xxx:8080
could deserve investigation.
And:
powershell.exe
│
└──► 185.xxx.xxx.xxx:443
could become highly suspicious when combined with other indicators.
The security question therefore changes from:
"Where is the computer communicating?"
to:
"Which process is communicating, where is it communicating, and what else was happening on the endpoint at the same time?"
That is the foundation of process-aware network detection.
8. Adding IOC Matching
The next layer is Indicator of Compromise matching.
The central detection system can maintain intelligence containing:
Malicious IP addresses
Malicious domains
Malicious URLs
File hashes
Known C2 infrastructure
Threat actor infrastructure
When an endpoint reports:
185.xxx.xxx.xxx
the system can check whether the destination is known.
Conceptually:
Network Event
│
▼
IOC Database
│
├── No Match → Continue Monitoring
│
└── Match → Raise Risk
A matching event can then be correlated with:
Process information
User information
Endpoint identity
DNS activity
Authentication events
File activity
Other network events
This is much more powerful than maintaining a manually checked list of suspicious addresses.
9. Reputation Enrichment
Network destinations can also be enriched using external threat-intelligence and reputation services.
For example:
185.xxx.xxx.xxx
│
├── Local IOC database
├── Threat intelligence
└── Reputation service
│
▼
Risk Result
The resulting information could look like:
Destination:
185.xxx.xxx.xxx
Reputation:
Malicious
Confidence:
92%
Category:
Command and Control
Affected Endpoints:
7
The important point is that reputation should be treated as one signal, not as an automatic declaration that every connection is malicious.
A security product should combine reputation with behavioral evidence.
10. Detecting Potential C2 Activity
The ultimate objective is not simply to display network connections.
It is to identify potentially malicious communication.
Consider this sequence:
Microsoft Word
│
▼
PowerShell starts
│
▼
PowerShell contacts new domain
│
▼
Domain resolves to suspicious IP
│
▼
Connection established
│
▼
Destination has poor reputation
Individually, some of these events might not be enough to trigger a high-severity alert.
Together, however, they form a much stronger behavioral signal.
A detection engine could produce:
Risk Score: 94/100
Severity: CRITICAL
Potential Command-and-Control Activity
Parent Process:
WINWORD.EXE
Child Process:
powershell.exe
Destination:
suspicious-example.com
Remote IP:
185.xxx.xxx.xxx
Remote Port:
443
This is the kind of correlation that makes network telemetry useful for EDR and SOC analysis.
11. Network Intelligence Dashboard
A dedicated dashboard can present the information in a way that is useful to security analysts.
For example:
┌──────────────────────────────────────────────────────────────┐
│ NETWORK INTELLIGENCE │
├──────────────────────────────────────────────────────────────┤
│ Endpoint Process PID Destination Risk │
├──────────────────────────────────────────────────────────────┤
│ PC-001 chrome.exe 4521 142.250.x.x:443 LOW │
│ PC-001 powershell 6214 185.x.x.x:443 HIGH │
│ PC-002 svchost.exe 1120 13.x.x.x:443 LOW │
│ PC-003 rundll32.exe 3384 91.x.x.x:8080 CRITICAL │
└──────────────────────────────────────────────────────────────┘
Selecting a connection could reveal:
Endpoint
Process
PID
Parent Process
Command Line
File Hash
Digital Signature
Local Address
Remote Address
Remote Port
Protocol
DNS Domain
IOC Status
Reputation
MITRE ATT&CK Mapping
Risk Score
Related Events
The analyst can then move from:
Connection → Process → Process Tree → DNS → IOC → Alert → Incident
without manually investigating each data source.
12. DNS Cache Still Has a Place
The original ipconfig /displaydns technique should not be discarded.
It remains useful as one source of information.
The expanded architecture can use:
Network Intelligence
│
├── DNS Cache
├── DNS Events
├── Network Connections
├── Listening Ports
├── Process Attribution
├── IOC Matching
├── Reputation
└── C2 Correlation
The original Python script therefore becomes the foundation of a much broader monitoring system.
The important change is that DNS cache data is now treated as one telemetry source among several.
13. Listening Ports
Another useful addition is monitoring listening ports.
For example:
PID Process Local Address Port
------------------------------------------------
812 svchost.exe 0.0.0.0 135
1040 service.exe 0.0.0.0 8080
4216 powershell 127.0.0.1 5000
A newly opened listening port can become interesting when combined with:
a new process
an unsigned executable
unusual parent process
suspicious service installation
persistence activity
external network exposure
This allows the program to detect changes in the endpoint's network exposure.
14. Network Events Should Be Structured
A network event can be represented as JSON:
{
"event_type": "network_connection",
"agent_id": "HOST-00123",
"timestamp": "2026-08-21T15:32:10",
"process": "powershell.exe",
"pid": 4216,
"parent_process": "winword.exe",
"local_ip": "192.168.1.25",
"local_port": 52144,
"remote_ip": "185.xxx.xxx.xxx",
"remote_port": 443,
"protocol": "TCP"
}
A DNS observation can be represented separately:
{
"event_type": "dns_observation",
"agent_id": "HOST-00123",
"timestamp": "2026-08-21T15:32:08",
"domain": "suspicious-example.com",
"resolved_ip": "185.xxx.xxx.xxx"
}
The detection engine can then correlate these records based on:
Endpoint
PID
Timestamp
IP address
Domain
Process
User
This is considerably easier than attempting to analyze raw command output.
15. PostgreSQL for Centralized Telemetry
For a small standalone Python application, SQLite is perfectly adequate.
As the number of monitored endpoints grows, however, centralized PostgreSQL storage becomes much more attractive.
The architecture can look like:
Endpoints
│
▼
Python Endpoint Collectors
│
▼
HTTPS
│
▼
Central Security Server
│
├── Process Events
├── DNS Events
├── Network Connections
├── Authentication Events
├── File Events
├── IOC Matches
└── Alerts
│
▼
PostgreSQL
This provides a foundation for historical searches across many endpoints.
16. Threat Hunting
Once network telemetry is centrally stored, analysts can perform searches that are difficult to accomplish with a simple local script.
For example:
Which computers contacted this IP?
185.xxx.xxx.xxx
Which processes contacted this domain?
suspicious-example.com
Which PowerShell processes made external connections?
powershell.exe
↓
External destination
Which endpoints contacted an IOC?
IOC
↓
Historical search
↓
Affected endpoints
Which domains appeared for the first time today?
First Seen = Today
This turns the project from a simple monitoring utility into a threat-hunting data source.
17. Offline Collection
Network telemetry should also survive temporary server or network failures.
A robust endpoint collector should therefore use local buffering:
Windows
│
▼
Python Collector
│
▼
Local Queue
│
├── Server Available
│ │
│ ▼
│ Upload
│
└── Server Unavailable
│
▼
Store Locally
│
▼
Retry Later
This is especially important for security telemetry.
Losing an hour of events because a server was temporarily unavailable could mean losing the evidence needed to reconstruct an incident.
18. What the Upgraded Program Can Now Answer
The original program essentially answered:
"What domains are currently in the Windows DNS cache?"
The upgraded architecture can answer much more.
Which process generated the network activity?
powershell.exe
Where did it connect?
185.xxx.xxx.xxx:443
What domain resolved to that address?
suspicious-example.com
Is the destination known?
IOC Match: YES
Is the destination suspicious?
Reputation: Malicious
What launched the process?
WINWORD.EXE
↓
powershell.exe
Did other endpoints contact the same destination?
7 endpoints
What is the overall risk?
CRITICAL
This is a major evolution from a DNS-cache viewer.
19. From Script to Network Security Platform
The progression can be summarized as:
Original Program
ipconfig /displaydns
│
▼
DNS Cache
│
▼
Display Results
becomes:
Upgraded Architecture
DNS
│
├───────────────┐
│ │
▼ ▼
Domains Resolved IPs
│ │
└───────┬───────┘
│
▼
Network Connections
│
▼
Process Attribution
│
▼
IOC / Reputation
│
▼
Behavioral Correlation
│
▼
Risk Scoring
│
▼
Threat Detection
│
▼
SOC / Threat Hunting
The difference is substantial.
The program is no longer simply looking for "hidden connections."
It is building a relationship between:
Process + DNS + Network + Threat Intelligence + Behavior.
20. Future Enhancements
There are several directions in which this project can continue to evolve.
DNS
DNS query monitoring
DNS tunneling detection
High-entropy domain detection
Newly registered domain detection
Suspicious TLD detection
Repeated failed DNS queries
Network
TCP/UDP connection tracking
Listening-port monitoring
Process-to-network mapping
Connection duration
Destination reputation
External versus internal communication
Process
Parent/child process relationships
Command-line analysis
Digital signatures
File hashes
Process reputation
Suspicious process behavior
Detection
IOC matching
Sigma-style rules
Behavioral rules
C2 detection
Beaconing detection
Lateral movement detection
Threat Hunting
Historical search
First-seen/last-seen tracking
Endpoint-wide searches
IOC retro-hunting
Process-to-network investigation
Conclusion
The original Python DNS-cache project demonstrated a simple but useful idea: a Windows computer is constantly communicating with services and systems that may not be obvious to the person using it.
ipconfig /displaydns provides a surprisingly useful window into that activity.
But DNS cache information is only the beginning.
By combining:
DNS + network connections + process attribution + listening ports + IOC matching + reputation + behavioral correlation + centralized storage
a relatively simple Python utility can evolve into a much more capable Network Intelligence and C2 Detection system.
The most important conceptual change is this:
Don't just show me where the computer is connecting. Show me what is connecting, where it is connecting, what domain is associated with it, whether the destination is suspicious, and how that activity relates to everything else happening on the endpoint.
That is the difference between a basic network utility and a security monitoring platform.
The original program started with one command:
ipconfig /displaydns
The upgraded concept turns that single source of information into a complete investigation chain:
DNS
↓
Network
↓
Process
↓
Threat Intelligence
↓
Correlation
↓
Risk
↓
Detection
↓
Investigation
And that is where Python becomes particularly interesting for cybersecurity: a small script can start as a diagnostic utility and, with the right architecture, evolve into a serious security telemetry and threat-hunting component.
