1.如何選擇需要感染的PLC。
Stuxnet會根據目標系統的特點，使用不同的代碼來感染PLC。一個感染的序列包括了許多PLC模塊（代碼模塊和數據模塊），用以注入PLC來改 變目標PLC的行為。這個威脅包括了三個感染序列。其中兩個非常相似，功能也相同，我們將其命名為序列A和B。第三個序列我們命名為序列C。 Stuxnet 通過驗證“指紋”來判斷系統是否為計劃攻擊的目標。它會檢查：PLC種類/家族：只有CPU6ES7-417和6ES7-315-2 會被感染。系統數據模塊：SDB會被解析；根據他們包含的數據，感染進程會選擇A,B或其它感染方式開始行動。當解析SDB時，代碼會搜索這兩個值是否存 在--7050hand9500h；然后根據這兩個數值的出現次數，選擇序列A或B中的一種來感染PLC。代碼還會在SDB模塊的50h子集中搜索字節序 2CCB0001,這個字節序反映了通信處理器CP342-5(用作Profibus-DP)是否存在。而選擇序列C進行感染的條件則由其他因素構成。
2.感染方法。
Stuxnet使用“代碼插入”的感染方式。當Stuxnet感染OB1時，它會執行以下行為：增加原始模塊的大小；在模塊開頭寫入惡意代碼；在惡意 代碼后插入原始的OB1代碼。Stuxnet也會用類似于感染OB1的方式感染OB35。它會用自身來取代標準的協同處理器DP_RECV代碼塊，然后在 Profibus(一個標準的用作分布式I/O的工業網絡總線)中掛鉤網絡通信。利用A/B方法的感染步驟如下：檢查PLC類型；該類型必須為S7 /315-2；檢查SDB模塊，判斷應該寫入序列A或B中的哪一個；找到DP_RECV，將其復制到FC1869，并用Stuxnet嵌入的一個惡意拷貝 將其取代；在序列中寫入惡意模塊（總共20個），由Stuxnet嵌入；感染OB1，令惡意代碼可以在新的周期開始時執行；感染OB35,它將扮演“看門 狗”的角色。
3.感染代碼。
被注入OB1功能的代碼是用來感染序列A和B的。這些序列包含了以下模塊：代碼塊：FC1865至FC1874,FC1876至FC1880（注 意：FC1869并非Stuxnet的一部分，而是PLC的DP_RECV模塊的一個拷貝）；數據模塊：DB888至DB891。序列A和B用 DP_RECV掛鉤模塊來攔截Profibus中的數據包，并根據在這些模塊中找到的數值，來構造其他的數據包并發送出去。這由一個復雜的狀態機控制（狀 態機被建立在上面提到的FC模塊中）。這個狀態機可部分受控于數據塊DB890中的DLL。在某些條件下，序列C會被寫入一個PLC。這個序列比A和B包 含更多的模塊：FC6055至FC6084；DB8062,DB8063；DB8061,DB8064至DB8070（在運行中產生）。序列C主要為了將 I/O信息讀寫入PLC的內存文件映射的I/O區域，以及外圍設備的I/O。程序A/B的控制流如下圖所示，在之前的Step7編輯器的截圖中也有部分顯 示（數據模塊FC1873）
4.RootkitStuxnetPLCrootkit代碼全部藏身于假冒的s7otbxdx.dll中。
為了不被PLC所檢測到，它至少需要應付以下情況：對自己的惡意數據模塊的讀請求；對受感染模塊(OB1,OB35,DP_RECV)的讀請求；可能 覆蓋Stuxnet自身代碼的寫請求。Stuxnet包含了監測和攔截這些請求的代碼，它會修改這些請求以保證Stuxnet的PLC代碼不會被發現或被 破壞。下面列出了幾個Stuxnet用被掛鉤的導出命令來應付這些情況的例子：s7blk_read:監測讀請求，而后Stuxnet會返回：真實請求的 DP_RECV(保存為FV1869)；錯誤信息，如果讀請求會涉及到它的惡意模塊；OB1或OB35的干凈版本的拷貝s7blk_write:監測關于 OB1/OB35的寫請求，以保證他們的新版本也會被感染。s7blk_findfirst/s7blk_findnext:這些例程被用于枚舉PLC中 的模塊。惡意模塊會被自動跳過。s7blk_delete:監測對模塊的“刪除”操作。如上文所述，Stuxnet是一個非常復雜的威脅，而其中的PLC 感染代碼令問題更加難以解決。
粵公網安備 44030402000745號 