Falade Favour

Attacks do not always follow a step by step or neat sequence, hence they should be mapped based on actual evidence. This week class was all about Threat intelligence, OSINT tools, MITRE ATT&CK framework, IOCs, detection engineering, practical attacks scenario, and custom Wazuh rules. Here are some of the things I learnt during the session: Mitre ATT&CK Framework: I learnt the tactics and techniques used to classify attacker behaviour and objectives. Indicators of Compromise(IOCs): Observable clues that may indicate that a malicious activity has occurred. Detection engineering: I learnt the difference between logs, events, and alerts, and how to write and tune custom rules in Wazuh to minimize false positives and false negatives. Just like every other week, my team and I were given a hands-on project. Stay tuned for my documentation on it. A huge thank you to our instructors and @ccfairfuta for this enlightening session. #CCFBootcamp #CCFSOCAccelerator #ThreatIntelligence #MITREATTACK #Wazuh #DetectionEngineering

You can only investigate what your logs recorded and your logs only record what it was configured to record. A SIEM platform is only good as the telemetry feeding it. For our Week 2 & 3 @ccfairfuta SOC Bootcamp project, my team and I worked on telemetry evaluation and visibility assessment using Wazuh against Windows and Kali Linux endpoint. During the exercise, we simulated an activity; an admin account executing suspicious PowerShell scripts designed to bypass local security execution policies and establishing persistent background services configured to launch automatically on system boot. We realized that although the activity was suspicious, it was a legitimate and controlled admin lab exercise. While we used default OS logging inside Wazuh, we could only see that something ran, but we lacked the full details especially with the absence of the commandLine arguments in the logs. We observed an enriched telemetry during Wazuh when we deployed Sysmon on Windows endpoint and AuditD on the Linux endpoint. It showed what happened exactly, exact command line execution details, parent-child process relationships, all of which were sufficient enough to explain the incident. It closed the visibility gap completely. I learnt that an SOC analyst must not rely solely on default OS logging, but also on enriched telemetry as it transform vague alerts into defensible evidence. #CCFBootcamp #CCFSOCAccelerator #Wazuh #CyberSecurity

No one talks about how hard it is to try something repeatedly, only for it not to work This was exactly my experience this week. After installing Wazuh on my ubuntu server, I encountered authentication problems when i wanted to access my dashboard. I decide to try a new method by installing the OVA file so that I could have Wazuh as a virtual machine. Even with that, my web browser did not even show the Wazuh authentication interface. To my surprise, I found out that the issues I had been experiencing were result of inappropriate RAM and storage allocation. #CCFbootcamp #CCFSOCbootcamp #Wazuh #SIEMtools @ccfairfuta

No telemetry, no visibility. No visibility, no investigation. If you don't have enough data, you would not have enough clues on what to investigate when an incident occurs. This was the core theme of Week 2 at the CCF SOC bootcamp, which focused on building visibility and getting enough telemetry. A few key highlights I learnt from the session: Telemetry: The automated collection of data from different endpoint sources as they operate. SIEM: The importance of these tools in correlating events, centralizing logs, and solving data scaling problems. Wazuh tool: The introduction to Wazuh, an open source SIEM platform for active threat detection. We were also split into Breakout rooms where my team had to discuss telemetry sources for a complex, real world scenario. My team has been assigned our next hands-on project based on this, so stay tuned for my upcoming project documentation. #Cybersecurity #BlueTeam #SOCBootcamp #SIEM #Wazuh

You cannot determine what is suspicious without deeply understanding what a completely normal activity looks like. Last week, I took a massive step forward in my cybersecurity goals by joining the Security Operations Centre (SOC) bootcamp run by Cyber Career Fair (CCF). Paired with an incredible team, we built an isolated three-node IT lab environment, generated controlled activity, analyzed resulting evidence, and carried out security monitoring. To keep our environment safe and isolated, we configured each machine's network adapter to host-only mode. Here is a breakdown of our project: 1. We deployed Windows VM (as our endpoint), Kali-Linux VM (as our controlled security testing node), and an Ubuntu server (as our administrative server) and we verified connectivity using ping. 2. We monitored running services, expected logins, and active processes on the Windows VM to determine what a normal baseline looks like. 3. We put the Principle of Least Privileged and Role Based Access Control(RBAC) into action on our Ubuntu server. We created users, group, tested group memberships, assigned strict directory permissions, and deliberately performed normal logins and controlled failed logins. We analyzed the evidence of our activities on the both VMs based on the logs. 4. We also used Wireshark to capture baseline network traffic like ICMP, DNS, SSH, and HTTP, while identifying the source or destination IP. 5. Using Kali-Linux VM, we ran a controlled Nmap port scan and simulated SSH password brute-force attack against our Ubuntu users account to capture the attack evidence. 6. We compared our baseline during normal system operation against the traffic captured after the simulated attack. This project made me realize that, unusual activity does not automatically mean a malicious attack and evidences does not prove a successful compromise. As an analysts, true detection requires correlating timestamps, source addresses, and connection outcomes. #Cybersecurity #SOCAnalyst #HandsonSOCproject