Malware in a PLC?

Typical customer who have a working machine but nitpick to not pay or delay payment. I have never done it but I guess I would overwrite and delete some unwritten initial values in protected blocks that would render useless most functions and would insert a lot of blocks loops to obscurate the issue.

Also, remove all the comments and tags names.

The "malware" would probably not be malware in the sense we know from PCs, but more like a "logical time bomb", i.e. somewhere in the code is a condition that triggers at a set time and does something, or merely blocks the machine from working.

To have such a time-bomb would be illegal in most cases I know of, especially if you have not been informed about it before the contract was signed.

Regarding the dependency of payment based on pending issues, then it should be stated in the contract. So it depends.
For example, the last payment may based on all pending issues being solved or at least there is a plan for solving them. Sometimes there is a maximum time for how long a customer can withhold the last payment.

You say none of it is connected to the internet.

Do they have a way of remote access to the PLC or HMI?

If not, I would say unless it was already in there, there is no way they could 'set off' anything that would corrupt the program.

If it was already in the software, then without them removing it somehow, the 'time bomb' was going to happen anyway.

If you could post the PLC code, I am sure we could have a look into it and tell you if we find anything.

Cheers

Mark

Yes I agree about the logical timebomb, some years ago I started with a company and my first task was to take backups of all the plc's, HMI's and Scada systems, where possible, contact the OEM's & request documented copies of the code. I came across one installation that a local system integrator had put in where the system stopped working i.e. it just stopped & would not run although the PLC was in run mode just would not start. The operator informed me that this had happened a number of times during the life of the system & they would call in the integrator who would spend a few hours & get it going again. Looking through the code, I found that there was a counter driven off the E-stop signal to the PLC, when it reached a value the counter was compared to a value and if higher set a bit, this bit was then used elsewhere in the program to set another bit that was indirectly addressed, this bit disabled the run signal, It became obvious that after a significant number of E-stops, the run signal was disabled. the bits concerned were retentive so a power down & up would not reset them, the amount of code to generate the fault was pretty clever in the way the integrator had tried to hide it by multiple logic & indirect addressing so it would not be easy to find. Needless to say he never was allowed on-site again. This was the only integrator we found had done this, however, I was told about a time he was called in to look at a large Siemens system that controlled a manufacturing plant, this was not his equipment but claimed that the profibus network had damaged cables, over a 3 day period he replaced the cables at a heavy cost, we had an issue where some profibus valve islands were showing fault, the engineering manager said this is what happened a year ago, the cables were replaced. It turned out that the fault was actually an e-stop on the plant that removed the 24v supply to the valve islands, therefore no communication, I suspect this was the case when the integrator attended last time but decided to make some money out of the companies ignorance.

Iner said:

Typical customer who have a working machine but nitpick to not pay or delay payment. I have never done it but I guess I would overwrite and delete some unwritten initial values in protected blocks that would render useless most functions and would insert a lot of blocks loops to obscurate the issue.

Also, remove all the comments and tags names.

Click to expand...

Plant has not been handed over to client, so no "working machine". Hence the predicament.


Not handing over a symbols table I've had to deal with before. From what I can see, this does not seem to be the case. Then again, it is the first time I've opened a Mitsubishi PLC program. Coming from a Siemens and Rockwell background, the software layout seems a bit stupid.

MarkNightingale said:

You say none of it is connected to the internet.

Do they have a way of remote access to the PLC or HMI?

If not, I would say unless it was already in there, there is no way they could 'set off' anything that would corrupt the program.

If it was already in the software, then without them removing it somehow, the 'time bomb' was going to happen anyway.

If you could post the PLC code, I am sure we could have a look into it and tell you if we find anything.

Cheers

Mark

Click to expand...

Remote little plant somewhere in the bush. No internet or WiFi. No connection to the outside world. No remote access.



Yup, I agree. If there is anything in there, it must have been put in there at the beginning, or when things started going pear-shaped. As it is such a remote location, you don't just swing by on your way to the office.


How would I upload the code to here? It is only 790kB, but only usable to someone with Mitsubishi software.


Martin

I think the accurate term for what you describe is ransomware.

As for actual malware, perhaps Stuxnet fits in that category?

I haven't used Mitsubishi HMI, but I'd probably do it there as it's a lot simpler to hide a script than something in the PLC. In a SCADA this would be even easier to hide.

JesperMP said:

The "malware" would probably not be malware in the sense we know from PCs, but more like a "logical time bomb", i.e. somewhere in the code is a condition that triggers at a set time and does something, or merely blocks the machine from working.

To have such a time-bomb would be illegal in most cases I know of, especially if you have not been informed about it before the contract was signed.

Regarding the dependency of payment based on pending issues, then it should be stated in the contract. So it depends.
For example, the last payment may based on all pending issues being solved or at least there is a plan for solving them. Sometimes there is a maximum time for how long a customer can withhold the last payment.

Click to expand...

Personally I think the whole thing is a bluff, and told them to call it. I mean Stuxnet happened, so malware is possible, but for this size operation, I think not.


Knowing the contractor, I would guess the contract is sound and fair. We have worked together before, and he is definitely not an a-hole. Well, not that I know of. Things can go wrong, and that is why you have contracts. If the subbie is not bluffing, then this time bomb was installed long before.

First of all, Works 3 if you do not have the source code and they have not downloaded the symbol table to the plc you will not be able to re-construct the code as FBD/LAD & structured code, uploading it will produce some form of ladder, however this becomes rather un-readable. In pure ladder i.e. GX Developer, the code is usually one long block consisting of ladder segments, however, in GXWorks, the compiler uses tasks so the main code is small and there will be hundreds of conditional jumps outside the main ladder to pointers and return functions. This is to be compatible with the IEC language. Many functions that are naitive to Mitsubishi are not the same as the IEC, so the compiler code generates the equivalent Mitsubishi code but displays as the IEC blocks, an example is a TON timer, the Mitsubishi timer is a simple coil with a value etc, the TON function for IEC uses reserved variables, jumps to a subroutine and returns, so is not a true timer as normally displayed in ladder.
There are also possibilities that some code if uploaded as ladder does not translate correctly although the logic works, however, the FX5 is one of the new generation of PLC's and you will notice the editor is different to the older FX range so it may be more in-line when compiled with the IEC functions. I do not have an FX5 so cannot check, however, I have works 2 & 3 & the simulator so if you could upload it try zipping it I could possibly have a look, I'm not sure what your supplier may say though.

From my perspective, the acceptableness of a logic time bomb mostly rests in semantics and what you call it. If the contractor literally said "I put malware in there and I'll trigger it if you don't pay" that sounds pretty bad. If he said "the software requires a license to run, and we won't give it to you until you pay" I think most people would think that is reasonable.


In the end, they mean essentially the same thing, and have the same effect, but cause people to have very different attitudes towards them. Also, one is usually an ad hoc "oh ****" response when a project goes sour, and one is usually spelled out in the contract and everyone knows it's coming. That really ends up being the key distinction to me.

parky said:

First of all, Works 3 if you do not have the source code and they have not downloaded the symbol table to the plc you will not be able to re-construct the code as FBD/LAD & structured code, uploading it will produce some form of ladder, however this becomes rather un-readable. In pure ladder i.e. GX Developer, the code is usually one long block consisting of ladder segments, however, in GXWorks, the compiler uses tasks so the main code is small and there will be hundreds of conditional jumps outside the main ladder to pointers and return functions. This is to be compatible with the IEC language. Many functions that are naitive to Mitsubishi are not the same as the IEC, so the compiler code generates the equivalent Mitsubishi code but displays as the IEC blocks, an example is a TON timer, the Mitsubishi timer is a simple coil with a value etc, the TON function for IEC uses reserved variables, jumps to a subroutine and returns, so is not a true timer as normally displayed in ladder.
There are also possibilities that some code if uploaded as ladder does not translate correctly although the logic works, however, the FX5 is one of the new generation of PLC's and you will notice the editor is different to the older FX range so it may be more in-line when compiled with the IEC functions. I do not have an FX5 so cannot check, however, I have works 2 & 3 & the simulator so if you could upload it try zipping it I could possibly have a look, I'm not sure what your supplier may say though.

Click to expand...

As I've mentioned before, I am not familiar with Mitsubishi at all. I was sent a *.GX3 file that opened with GX Works3.



As for the supplier, I am not involved in this at all. I am sitting on a different continent to them. As I have worked with the PM before, I must have made an impression along the way. He contacted me via LinkedIn and asked If I could help. No money involved for me. I did mention, after my initial checks came up blank, that I would ask for a second opinion here, and he had no objection. So I can send the file I guess.

Years ago I had a client do this on a machine going down to Mexico at a plant that had a reputation for not paying their bills. They created a module in the HMI that timed out and put up a screen requiring them to put in a maintenance code to operate. I checked back later to see how it went. The plant did not pay. The screen came up with maintenance screen 2 months later. Funny thin is, the plant installed the spare and went another couple of months. They did end up paying the final invoice to operate their machine.

Yes, if it is a GX3 file then I could have a look I'm quite fluent in Mitsubishi having used them for over 30 years.
EDIT: sometimes it is best to save it as a single file format if it is not already then zip it I believe it zips up tighter.

This threat from the subsupplier, do you have it in writing ? It is totally illegal unless it is specifically mentioned in the contract.