new places to go solo Interest area – OSINT, Network Pentest, Malware analysis, Social engineering , DevSecOps, Geopolitics & Quantum physics Professional CS GO & Fortnite Player : Nick : GodWA Certified ICS Security skills from US Homeland Security & CISA Reported Scada bugs for BSNL, Railtel & other National critical infrastructures Provide OSINT training and consultancy to govt agencies & Private entities Work closely with CyberPeace NGO helping Indian masses to stay safe in cyberspace. 2 Website – https:/cyberkalki.com/ [ Work in Progress]
Security patches Applied regularly on standard systems Only recently provided by vendors. Applied once a year tops Antivirus Deployed on all Windows machines, centrally managed Not managed Administration Centralized, dedicated teams, standard operations and procedures Lack of local skills, heterogeneous environments, lots of different tools to use, vendor support is mandatory IAM Nominative accounts Generic, shared accounts, no password policy Availability Service interruptions are ok, especially outside business hours Real-time operations, downtime is unacceptable or very costly Protocols Standard, TCP/IP protocols that include authentication and encryption Lot of vendor-specific protocol, no security built into the protocols Impact No people endangered Possible impact of people, environment, industrial gear
network protocol implementation 3. Plain text traffic 4. Weak protection of ICS systems from the enterprise IT network 5. Vulnerable web services 6. Insecure remote connectivity to ICS networks 7. Poor patch management 8. Lack of cyber security considerations in network architecture/segmentation 9. Weak network component configuration 10. Insecure encryption and authentication for wireless ICS networks 11. Poor programming and code quality 12. Poor passwords practices and weak authentication 13. No integrity checks at critical asset level 14. Least user privilege violation
confidential information (product formulations, trade secrets, production schedules, etc.) 2. Loss of integrity or reliability of process/production information 3. Loss of system availability and/or accessibility 4. Process upsets leading to compromised process functionality, inferior product quality, product contamination, lost production capacity, compromised process safety, or environmental releases 5. Equipment and/or facility damage 6. Personal injury or death 7. Violation of legal and regulatory requirements (e.g. environmental) 8. Risk to public health and confidence 9. Threat to a nation’s security
all connections to ICS networks. 2. Disconnect unnecessary connections to the ICS network. 3. Harden SCADA networks by removing or disabling unnecessary services. 4. Do not rely on proprietary protocols to protect your system. 5. Implement the security features provided by device and system vendors. 6. Establish strong controls over any medium that is used as a backdoor into the ICS network. 7. Implement internal and external intrusion detection systems and establish 24-hour-a-day incident monitoring. 8. Perform technical audits of ICS devices and networks, and any other connected networks, to identify security concerns. 9. Conduct physical security surveys and assess all remote sites connected to the SCADA network to evaluate their security. 10. Establish ICS “Red Teams” to identify and evaluate possible attack scenarios 11. Restrict access to control room(s), portable devices, and removable media, which should be locked down and physically secured
Schneider Electric aka Modicon 2. The most common Modbus functions allow to read and write data from/to a PLC 3. Undocumented Modbus function codes can also be used to perform specific actions t common Modbus functions allow to read and write data from/to a PLC
communicate than your standard IT systems. The most widely used and the de facto standard is the • Modbus protocol. First developed by Modicon (now Schneider Electric) in 1979 as a serial protocol, it has been modified and updated to run over TCP and is often referred to as Modbus TCP. You can see a diagram of the two packet structures below
master and slave .jar files. Can be run on windows system as well. After executing these two files, you should have a screen that looks like this below.
TCP on port 502. Step #3 Add Slaves Step #4 Add Values to the Coils Step #5 Change the Coil Data Step #6 Adding Values to the Registers Step #7 Write Multiple Registers # The similar process can be followed for holding registers as well.
using a live, functioning SCADA system as my target. This is not a laboratory or VM. It is random system selected from the Internet. I have removed it's IP address to protect the naive and uninformed. No damage was done, and all settings were returned to their original state. Step #1: Search for Modbus Modules To begin, let's use the search function in Metasploit to find Modbus modules. • To begin, let's use the search function in Metasploit to find modbus modules.
protocol is being used on target Now let’s recon some stuffs using other modules like Modbusdetect. When we run this module, it goes to the target system's port 502 and sends a probe to determine whether it is using modbus. As you can see below, it confirms that our target is running modbus and now we can proceed with our modbus-based reconnaissance and exploitation.
ID’s This is similar to a ping sweep in TCP/IP, but the results are slightly less reliable. As you can see, this module was successful in finding each of the Unit ID's of the connected devices.
Writing data on the Modbus Devices Our next modbus module is modbusclient. It enables us to read and write the data from both the coils and registers on these SCADA systems. Reading the data can lead to information leakage, but writing the data is even more nefarious as it could change various setting within the plant and cause a malfunction (pay attention cyber warriors!).
in last screenshot, we have changed value from 0 to 1. In SCADA/ICS terminology, coils are devices on the network that are either ON or OFF. Their settings are either 1 or 0. By changing the values of a coil, you are switching it on or off. This module requires several variables to be set. Most important is the ACTION.
setting for the UNIT_NUMBER is 1 and NUMBER is 1. This means that by default, it will take its action only on the first UNIT ID and only the first unit. In this case, I set the NUMBER variable to 100. This means it will start with UNIT ID number 1 and read 100 registers.
needs to be secured against attackers. Since there is no transport layer security to secure communications between master and slave, a hostile actor can use a variety of methods, like ARP poisoning, to insert themselves into the middle of communications. This attack is a three-step process. ◦ The first is to poison the ARP tables on the master and slave. This forces the network to trust the predefined route for communication. ◦ In the second step, with all traffic between the two is going through the attacker (or man-in-the-middle) machine, certain packets are captured and modified. This is done with Scapy’s sniff function, which allows us to specify a function to apply to every packet that meets the given criteria. ◦ The third step is to clean up the ARP tables. This seamlessly removes our code from the communication, thereby making the post attack analysis more difficult.
receives a Modbus command it stores the resultant slave state locally. It then forwards a modified request to the slave and intercepts its response. The response is then edited to match the expected result. This allows us to change the configuration of the slave without the master being aware of the changes. • Above figure show a request and response being filtered by our software. It shows the master issuing a write request (write value 1 to coil 3), that status being saved by our software, and a different configuration being forwarded (write value 0 to coil 3). • Post that, the response from the slave (coil 3 is 0) is processed. The result of which is the master believing the slave has a different configuration than it has. • This deception will persist until either the software decides to remove itself from the configuration, or the slave is queried by something that has not been ARP poisoned.
PLC and HMI devices 3. Packet sniffing & MITM attacks on field devices 4. Visualizing and exploiting ICS via Dragos 5. Exploiting other ICS & IOT level bugs BE UPDATED !!! Follow my website or blogs for more insights about ICS Pentesting TTP’s
aksc_ck
trafficbrain
akifumi_wachi
masatoto
hiroyaonoe
tam1110
hf149
joisino
gpeyre
0325
upura
holman
jonyablonski
jonrohan
kneath
andyhume
sergeychernyshev
chriscoyier
chrislema
csswizardry
bcantrill
aki_iinuma
