ENGINES ON

darkhex.dev00%

Work

Labs & Reports

Projects from my M.Sc. and hands-on lab work. Each one ended in a written report.

M.Sc. thesis · Applied Cyber Security

Machine-learning DDoS detection, from dataset to working app

Rule-based defences struggle to tell a DDoS flood from a legitimate traffic spike. I built a supervised ML pipeline that learns what attack traffic behaves like, compared two classifiers, and shipped the winner inside a Django web app that classifies new traffic with a confidence score.

0.99cross-validated F1
Random Forest
Network flows
852,585
454,849 normal · 397,736 DDoS
Models compared
2
Random Forest vs Logistic Regression
Validation
5-fold
cross-validation, F1 as the main metric
Dimensions kept
95%
of variance after PCA

Pipeline

  1. CleanDropped source and destination IPs
  2. EncodeProtocol layers to numbers
  3. ScaleStandardScaler on numeric features
  4. BalanceSMOTE on training data only
  5. ReducePCA, 95% variance
  6. TrainRF vs LR, 5-fold CV
  7. DeployDjango app with confidence score

Model comparison (cross-validated F1, axis 0.90 to 1.00)

Random Forest0.99
Logistic Regression0.96

The trade-off: Random Forest took about 525 s to cross-validate, Logistic Regression about 12 s. The accuracy gain was worth it.

What gave attacks away

  • Packet length · strongest signal, correlation −0.92 with the attack label. Floods use short, uniform packets.
  • Highest protocol layer · correlation +0.78. Some protocols showed up far more in attacks.
  • Packet rate · caught the burst-like intensity of flood traffic.
  • Transport layer · helped separate TCP- and UDP-based patterns.

Design decisions

  • No IP addresses as features. A model that learns IPs just memorises a blocklist and misses attacks from new sources. Removing them forced it to learn behaviour.
  • Same preprocessing in production. Encoders, scaler, PCA and model were saved with joblib and loaded once at server start, so live input is transformed exactly like training data.
  • Confidence, not just a label. The app returns "Normal traffic" or "DDoS attack detected" with the model's probability.

Limits & next steps

  • One public dataset, so results need testing on live, mixed traffic.
  • Binary only. Next: tell SYN, UDP and HTTP floods apart.
  • No drift handling yet. Next: monitoring and scheduled retraining.
  • Try gradient boosting and deep learning models.
Pythonpandasscikit-learnimbalanced-learnPCAjoblibDjangoBootstrap
⌕Digital forensics · M57 Patents training case

Insider data theft investigation

An employee was suspected of selling confidential patent data to a competitor. Working only from forensic images of his desktop and USB drive, I rebuilt what happened: who he talked to, what he sent, when, and how he tried to hide it.

What the evidence showed

  • Emails to an outside contact offering company data, agreeing a price and sending a password
  • Web searches for steganography tools, and a data-hiding tool plus a hex editor installed
  • A password hidden inside a JPEG attachment, found by reading the file at byte level
  • 13 USB devices in the registry, with the suspect drive's activity lining up with file access
  • 4 image files recovered from the USB drive and 3 encrypted files flagged

How I worked

  1. Acquire & verifyImages hashed with SHA-256, analysed read-only
  2. Email & keywordsMessages, attachments and indexed searches
  3. Registry & USBUSBSTOR keys, installed programs, recent docs
  4. TimelineFile, USB and web activity in one sequence
  5. Recover & inspectDeleted-file carving and hex-level checks
  6. ReportScreenshots, hashes and chain of custody for every finding
AutopsyFTK ImagerOSForensicsHex analysisNIST SP 800-86ISO/IEC 27037ACPO
◉Malware analysis · Conti ransomware

Taking apart a ransomware sample

I analysed a live Conti ransomware sample in an isolated lab, first without running it, then while it ran, and turned the results into two reports: a technical one for defenders and a plain-English one for leadership.

What I found

  • Flagged by 61 of 72 antivirus engines; high entropy suggested a packed binary
  • Added itself to a Windows Run key to survive reboots
  • Repeated DNS and TLS call-outs using a self-signed certificate
  • Encrypted files and dropped a ransom note threatening a data leak

Mapped to MITRE ATT&CK

  1. T1547.001Persistence via registry Run keys
  2. T1071.004Command and control over DNS
  3. T1573.002Encrypted C2 channel (TLS)
  4. T1055.001Process injection
  5. T1106Native Windows API calls
  6. T1486Data encrypted for impact
PE StudioVirusTotalProcmonProcess ExplorerRegshotAutorunsFakeNetWireshark
⇄Threat intelligence

APT campaign mapped to ATT&CK

Took a public vendor report on a long-running APT intrusion and mapped the attack chain to 18 ATT&CK techniques, from spear-phishing and fileless payloads to persistence and credential dumping.

MITRE ATT&CKThreat intel
@Application security · OSINT

Passive attack-surface review

Mapped an organisation's public footprint from open sources only, with no active testing, and turned it into a prioritised risk list with fixes.

OSINTRisk rating