This blog will be one in a series of blogs to discuss the above topic. We will take specific Microsoft Defender for IoT alerts and try to understand what initiated the alert and if the issue is one needing further investigation or remediation or not. We will follow a basic sequence to start the analysis. This initial sequence will be used for all the investigations.
As the blog progresses, if you have an alert of concern and you are willing to provide a pcap, we can follow this process for your alert. Any examples used would be scrubbed and addresses anonymized.
The sequence is below:
Alert: PLC Scan Detected
Notice that there seem to be two devices involved with 192.168.2.166 being the initiator. We might filter on this IP address in the Alerts list to see if all the alerts are related to scanning.
There are three different types of alerts associated with this source address.
Well known protocols used include 21 (FTP), 22 (SSH), 23 (Telnet), 80 (HTTP), 135 (RPC Endpoint Mapper), 443 (HTTPS), 514 (Remote Shell), 4000 (Emerson ROC), 7001 (SPA), and 20000 (DNP3) among others.
6. Microsoft Defender for IoT makes the filtered pcap available for this alert. Loading the filtered pcap into Wireshark, found many attempted sessions followed either by RST, ACK or by Fin, ACK. This pcap showed only scans targeting 192.168.88.60
7. Follow the streams associated with the identified protocols
Use filters in Wireshark to select each protocol, for instance tcp.port==21. This shows that there is one FTP attempt and it receives a RST/ACK. See below…
Going on to the next protocol, SSH is a little more interesting. The filter is tcp.port==22. If you note the ‘[‘ lines to the left of the packet window, this is a way to see the packets involved in the various streams. I look for a ‘meaty’ stream (having a number of related packets) and follow the stream.
To follow the stream, right-click on the starting packet (or any packet in the stream), select ‘Follow’, then ‘TCP Stream’ as shown below:
Note that this shows a console attempt over SSH to a MOXA switch.
Moving on to Telnet on port 23 and adding one more Wireshark method, we will first filter on port 23 with tcp.port==23 to show this filtered data.
Now we will utilize the Statistics – Flow Graph option to look at this data in a different way.
The result shows all streams as seen below:
Check the box to Limit the Flow Graph to the selection in the main window to tcp port 23, and the Flow Graph now shows only traffic involving Telnet below.
This shows some actual data passing as shown. Since this data is in plain text, we want to see what is flowing in this stream. Clicking on any line in this Flow Graph highlights the associated packet in the main Wireshark display in the background. And from here we can follow the stream as we did above. This results in the following…
Now, this is really interesting. This query yields some potentially important information tabulated below.
Following a similar process for HTTP yields an attempt to determine if the host 192.168.88.61 supports the http POST method.
No similar success was found in any of the other ports with exception of 4000 and 4001. These yielded a ‘JDWP – Handshake’ followed by some binary then ‘J.WP’. Not sure what this means but is related to Emerson ROC.
So, to summarize, Microsoft Defender for IoT identified a potential issue on this network. We used some of its inherent tools to decide if the alert appears to be a real concern. Then we used Wireshark to gain insight into what information the potential attacker may have learned about the devices on this network.
This provides us insight into how to defend this network, by preventing this type of access, possibly via firewall rule improvement. We can certainly change passwords on scanned devices. We can eliminate, if possible, open text communication modes like ftp or build up secondary defenses if this is not possible.
Hope you enjoyed this!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.