Vulniverse

Modbus TCP is a layer 7 communications protocol and a de facto standard in the field of industrial control systems. Having recently moved into the utilities sector I wanted to learn more about it. In this post I'll be taking a look at the Modbus TCP challenge included in the ControlThings.io  ICS pentesting distro and hopefully learning a little about Modbus along the way. So let's get started! The challenge itself is located at ~/Samples/Protocols/ModbusTCP. We have some pcaps, some reference material and some instructions as follows: Plant1-ModbusTCP.pcap This is an export of the ModbusTCP packets from the Plant1.pcap file Source: https://www.cloudshark.org/captures/76038eaa4a3b Modbus Challenges: - Which IP address is the master on? - How many slaves is the master talking to? - Is the master writing any data to the slaves? - Does the traffic spike in the middle related [SIC] to modbus? So first of all, we need to understand what are these masters and slaves being referred to

In this post I will explore the  SickOs 1.1  VM by  D4rk  and explain how the Squid proxy enables us to access the Apache server on port 80. This isn't a walkthrough of SickOs as such but instead a deep dive into the proxy exploitation specifically. Although I knew how to compromise the VM, I realised that I didn't have it clear in my own head exactly what was going on with the proxy at the packet level and I wanted to fill in the blanks; hence this post. So we'll go through it step by step and take a look under the hood at what's really going on.  In this article, the two IP addresses in play are: 192.168.166.128: Kali (attacking machine) 192.168.166.138: SickOs (victim machine) So as we know, when we run an nmap scan we find that TCP port 3128 is open and that TCP port 80 most definitely isn't: So for the hell of it, let's try browsing to port 80 and see what happens. Well, no surprises in Firefox; we get a long, very boring wait while it informs us that it is