LetsDefend level 2 alert SOC154 - Service Configuration File Changed by Non Admin User event-id 102
- Details
- playbook
- Connect Machine
- Verify
- Determine whether alert was TP or FP
- Choose Incident Type
- What is the initial access method used in the attack?
- Determines Scope of Threat/Risk to the Organization
- What is the persistence method used in the attack?
- Were privilege escalation techniques used in the attack?
- Which technique was used in the credential access tactic?
- Does the device need to be isolated?
- End
Details
EventID : 102
Event Time : Sep, 04, 2021, 02:30 PM
Rule : SOC154 - Service Configuration File Changed by Non Admin User
Level : Incident Responder
Hostname : Brian
IP Address : 172.31.34.46
EDR Action : Allowed
Service Name : //lib//systemd//system//project.service
Tier 1 Note : I found that the permission of the file named project.service is set to 777. The file appears to have been modified on 04.09.2021 but I could not detect which user changed it.
playbook
Connect Machine
Incident Responderのアラートで扱うホストには直接アクセスして調査することができるようだ．
Verify
Alarms escalated from Tier1 to Tier2 should be caused by a truly harmful event, but escalated alarms by Tier1 analysts are not always True Positive due to technical inadequacy, faulty/incomplete analysis, and authorization problems. Tier1 から Tier2 にエスカレーションされるアラームは、真に有害な事象が原因であるべきだが、Tier1 アナリストによるエスカレーションアラームは、技術的な不備、誤った/不完全な分析、権限の問題などにより、必ずしも True Positive ではないことがある。
確かに，自分でも今までのアラートで間違った判断をしたことはある．こういうところも考慮して現実のシチュエーションを意識する(私は実践未経験です)というのは，letsdefendの良いところ．
Determine whether alert was TP or FP
件のアラートの元になったファイルの中身には，/tmp/shell.shという謎のシェルスクリプトが結びついている．
cat: /tmp/shell.sh: No such file or directory
/tmpだからか．詰まった．どうしようかと手がかりを捜索．
その後色々見ていて，気になったのはrootのhistoryのこの部分
盗まれてますね．何て言っていたら，このサーバ/var/www/htmlあると気づき．
すでに怪しさ満点である．
これをアップロードしたやつを見つければ良さそう．apache2ではなくて，nginxのaccess.logを見るとアップロードはfileadmin.phpで行ったよう．
そして発火してるもの．
やはり，18.217.124.122が今回悪さしているやつのようだ．この後，LinEnumのダウンロードや実行もwebshellで行っていた．そして，bashやpythonでリバースシェルを試みて結局perlのリバースシェルが上手くいったのではないだろうか．
Answer: True Positive
Choose Incident Type
Answer: Generic
What is the initial access method used in the attack?
nginxのサービス？から来たようなので
Answer: Exploit Public-Facing Application
Determines Scope of Threat/Risk to the Organization
何て書けばいいか分からん．
Answer: Web service has been hacked into the server and stolen the credentials on this server.
What is the persistence method used in the attack?
ここで，今回のアラートにやっと戻ってくる．侵入後にサービスを作成し，/tmp/shell.shが永続性を確保するものだったのか．/tmp/shell.shは再起動後には消えてしまう訳だが，そこら辺はどう考えていたのか分からない．project.serviceは現在は動いていないが．
ちゃんと動いていたときもあった．
Answer: Scheduled Task/Job
Were privilege escalation techniques used in the attack?
rootにアクセスしてるので
Answer: Yes
Which technique was used in the credential access tactic?
権限の緩いサービスを変更してroot実行させた．
Answer: None
Does the device need to be isolated?
Answer: Yes
End
PersistenceがScheduled Task/JobではなくてCreate or Modify System Processだったのはミスだった．よく考えたら，cronだったら合っていたがserviceだったか．
Credential Access がNoneではなくOS Credential Dumpingなのは問題の意味を分かっていなかったからかと．あそこで問われていたのは，rootへの権限昇格のために資格情報をどうやって取ってきたかだと思っていたが他の資格情報も含めてということだった？
