1. 如何選擇需要感染的PLC。 Stuxnet會(huì)根據(jù)目標(biāo)系統(tǒng)的特點(diǎn)，使用不同的代碼來(lái)感染PLC。 一個(gè)感染的序列包括了許多PLC 模塊（代碼模塊和數(shù)據(jù)模塊），用以注入PLC來(lái)改變目標(biāo)PLC 的行為。這個(gè)威脅包括了三個(gè)感染序列。其中兩個(gè)非常相似，功能也相同，我們將其命名為序列A和B。第三個(gè)序列我們命名為序列C。Stuxnet通過(guò)驗(yàn)證“指紋”來(lái)判斷系統(tǒng)是否為計(jì)劃攻擊的目標(biāo)。它會(huì)檢查： PLC種類(lèi)/家族：只有CPU 6ES7-417 和6ES7-315-2 會(huì)被感染。系統(tǒng)數(shù)據(jù)模塊：SDB 會(huì)被解析；根據(jù)他們包含的數(shù)據(jù)，感染進(jìn)程會(huì)選擇A,B或其它感染方式開(kāi)始行動(dòng)。當(dāng)解析SDB 時(shí)，代碼會(huì)搜索這兩個(gè)值是否存在-- 7050h and 9500h；然后根據(jù)這兩個(gè)數(shù)值的出現(xiàn)次數(shù)，選擇序列A 或B 中的一種來(lái)感染PLC。 代碼還會(huì)在SDB 模塊的50h 子集中搜索字節(jié)序2C CB 00 01, 這個(gè)字節(jié)序反映了通信處理器CP 342-5 (用作Profibus-DP) 是否存在。 而選擇序列C進(jìn)行感染的條件則由其他因素構(gòu)成。

　　2. 感染方法 Stuxnet使用“代碼插入”的感染方式。當(dāng)Stuxnet 感染OB1時(shí)，它會(huì)執(zhí)行以下行為： 增加原始模塊的大小； 在模塊開(kāi)頭寫(xiě)入惡意代碼； 在惡意代碼后插入原始的OB1 代碼。Stuxnet也會(huì)用類(lèi)似于感染OB1的方式感染OB35。它會(huì)用自身來(lái)取代標(biāo)準(zhǔn)的協(xié)同處理器DP_RECV 代碼塊，然后在Profibus (一個(gè)標(biāo)準(zhǔn)的用作分布式I/O的工業(yè)網(wǎng)絡(luò)總線(xiàn)) 中掛鉤網(wǎng)絡(luò)通信。 利用A/B方法的感染步驟如下： 檢查PLC 類(lèi)型； 該類(lèi)型必須為S7/315-2； 檢查SDB 模塊，判斷應(yīng)該寫(xiě)入序列A 或B 中的哪一個(gè)； 找到DP_RECV，將其復(fù)制到FC1869，并用Stuxnet嵌入的一個(gè)惡意拷貝將其取代； 在序列中寫(xiě)入惡意模塊（總共20個(gè)），由Stuxnet 嵌入； 感染OB1，令?lèi)阂獯a可以在新的周期開(kāi)始時(shí)執(zhí)行； 感染OB35, 它將扮演“看門(mén)狗”的角色。

　　3. 感染代碼 被注入OB1 功能的代碼是用來(lái)感染序列A 和B的。這些序列包含了以下模塊： 代碼塊：FC1865 至FC1874, FC1876 至FC1880 （注意：FC1869并非Stuxnet的一部分，而是PLC的DP_RECV模塊的一個(gè)拷貝）； 數(shù)據(jù)模塊：DB888 至DB891。 序列A 和B 用DP_RECV 掛鉤模塊來(lái)攔截Profibus 中的數(shù)據(jù)包，并根據(jù)在這些模塊中找到的數(shù)值，來(lái)構(gòu)造其他的數(shù)據(jù)包并發(fā)送出去。這由一個(gè)復(fù)雜的狀態(tài)機(jī)控制（狀態(tài)機(jī)被建立在上面提到的FC 模塊中）。這個(gè)狀態(tài)機(jī)可部分受控于數(shù)據(jù)塊DB890 中的DLL。 在某些條件下，序列C會(huì)被寫(xiě)入一個(gè)PLC。這個(gè)序列比A和B包含更多的模塊： FC6055 至FC6084；DB8062, DB8063；DB8061, DB8064 至DB8070 （在運(yùn)行中產(chǎn)生）。 序列C主要為了將I/O信息讀寫(xiě)入PLC的內(nèi)存文件映射的I/O 區(qū)域，以及外圍設(shè)備的I/O。 程序A/B 的控制流如下圖所示，在之前的Step7 編輯器的截圖中也有部分顯示（數(shù)據(jù)模塊FC1873）

　　4. Rootkit Stuxnet PLC rootkit代碼全部藏身于假冒的s7otbxdx.dll中。為了不被PLC所檢測(cè)到，它至少需要應(yīng)付以下情況： 對(duì)自己的惡意數(shù)據(jù)模塊的讀請(qǐng)求；對(duì)受感染模塊(OB1 , OB35, DP_RECV) 的讀請(qǐng)求；可能覆蓋Stuxnet自身代碼的寫(xiě)請(qǐng)求。 Stuxnet包含了監(jiān)測(cè)和攔截這些請(qǐng)求的代碼，它會(huì)修改這些請(qǐng)求以保證Stuxnet 的PLC 代碼不會(huì)被發(fā)現(xiàn)或被破壞。下面列出了幾個(gè)Stuxnet用被掛鉤的導(dǎo)出命令來(lái)應(yīng)付這些情況的例子： s7blk_read: 監(jiān)測(cè)讀請(qǐng)求，而后Stuxnet 會(huì)返回：真實(shí)請(qǐng)求的DP_RECV (保存為FV1869)；錯(cuò)誤信息，如果讀請(qǐng)求會(huì)涉及到它的惡意模塊；OB1或OB35的干凈版本的拷貝s7blk_write: 監(jiān)測(cè)關(guān)于OB1/OB35的寫(xiě)請(qǐng)求，以保證他們的新版本也會(huì)被感染。s7blk_findfirst / s7blk_findnext: 這些例程被用于枚舉PLC中的模塊。惡意模塊會(huì)被自動(dòng)跳過(guò)。s7blk_delete: 監(jiān)測(cè)對(duì)模塊的“刪除”操作。 如上文所述，Stuxnet 是一個(gè)非常復(fù)雜的威脅，而其中的PLC 感染代碼令問(wèn)題更加難以解決。僅僅關(guān)于注入的MC7代碼（我們于幾個(gè)月前通過(guò)逆向工程獲得）就可以討論很久。若想了解更多關(guān)于PLC 感染例程和Stuxnet的總體情況，請(qǐng)務(wù)必關(guān)注我們即將于Virus Bulletin會(huì)議中發(fā)布的白皮書(shū)。