CalédoBank - SISR, May 2022 session

Mission A1 - Centralising logs and metrics

Zabbix monitors in real time but is ill-suited to the continuous analysis of a large volume of logs retained for a year. Elastic Stack meets this need:

Module	Role	Requirement covered
Beats (Filebeat, Packetbeat, Metricbeat)	lightweight collection agents	logs, network traffic, and metrics for each server/asset
Logstash	aggregation, transformation, shipping	normalisation of heterogeneous sources
Elasticsearch	indexing and search	fast searching across large log volumes (retention ≥ 1 year)
Kibana	visualisation, dashboards	real-time streams, categorisation, anomaly detection

Elastic Stack centralises scattered logs, correlates and categorises events, and triggers alerts, complementing Zabbix for retrospective analysis.

a) The server involved is 192.168.134.x (DMZ FTPS server, VLAN 192). The application service is FTPS (FTP over TLS); control port 990, TCP protocol. The log confirms an FTPS session (220 (vsFTPd 3.0.3), TLSv1.3 negotiation).

b) This is a brute force attack on FTP authentication. Supporting evidence:

• a rapid succession of connections from the same source IP 192.168.134.212 over a very short interval (every ~5 s);
• successive login attempts: USER admin, then USER utilisateur, then USER user... each time with a different password;
• each attempt results in a FAIL LOGIN followed by 530 Please login with USER and PASS..

The attack failed: all log entries are FAIL LOGIN / 530 (no 230 Login successful). No authentication succeeded during the observed timeframe.

1. Lockout / delay policy: limit the number of attempts per IP and block after N failures (e.g. fail2ban, vsFTPd's max_login_fails / delay_failed_login). Rationale: breaks brute force effectiveness by slowing down or blocking the attacker.
2. Disable generic accounts and disallow anonymous login + restrict accounts permitted to connect (chroot, strong named accounts). Rationale: the tested admin, user, utilisateur are default/guessable accounts; removing them deprives the attack of targets.

(Accepted alternative: restrict authorised source IPs to known providers only via application-level filtering.)

Mission A2: Vulnerability search (Emotet Trojan)

Detection approach:

1. Emocheck (JPCERTCC) on Windows workstations: compares running processes against the Emotet name dictionary.
2. Search for suspicious processes/services and scheduled tasks matching known IOCs.
3. Detection of malicious links in emails using regexes published by Cryptolaemus.
4. C2 communications: cross-reference firewall/proxy logs with Feodotracker (abuse.ch) C&C servers.
5. Check logs for lateral movement (SMB) and access to browser/email passwords.

Measure	Rationale (targeted Emotet vector)
Filter / inspect email (anti-spam, attachment sandboxing, disabling Office macros via GPO)	Emotet spreads via phishing with Word/PDF attachments and macros
Raise user awareness regarding email thread hijacking	lure emails masquerade as legitimate replies to existing conversations
Keep systems updated / segment (SMB patches, EDR, network segmentation, least privilege)	Emotet exploits SMB vulnerabilities and stolen passwords to propagate

Mission B1: GDPR compliance and risk analysis

Under data minimisation (GDPR Art. 5) and the prohibition of sensitive data (Art. 9), the following are irrelevant or problematic for a credit application:

• community affiliation (Kanak, European, Wallisian...): data revealing ethnic origin → prohibited sensitive data;
• social security number (NIR): strictly regulated use, not required to process a credit application;
• cause of disability of a dependent relative: sensitive health data, not relevant;
• family status details (dates of civil partnership/marriage/divorce) beyond what is strictly necessary to assess creditworthiness.

a) Rights stated on the form ('Data Protection' box): right of access, rectification, erasure, restriction of processing, objection, and the right to lodge a complaint with the CNIL.

b) They are not all present. Compared to document B2, the following are missing:

• the right to data portability;
• the right to withdraw consent at any time (the tick box only mentions obtaining consent).

Scoring scale: Severity = CI + CP, Likelihood = VS + CA (sum below 5 → 1, equal to 5 → 2, equal to 6 → 3, above 6 → 4).

Risk 1 - Tablet theft	Value	Justification
CI	4	name, date of birth, NIR, supporting documents: full identification
CP	3	financial/identity data → significant harm
Severity	4 (maximum)	CI+CP = 7 (> 6)
VS	4	unencrypted tablets, freely accessible at reception
motivated external attacker, but physical access must be organised	2	CA
Likelihood	3 (significant)	VS+CA = 6

Impacts: confidentiality (exposure of personal data) and integrity (alteration). Availability minimally affected (weekly purge).

Risk 2 - Wi-Fi interception	Value	Justification
CI	4	same personal data transmitted (identity, supporting documents)
CP	3	financial data → significant harm
Severity	4 (maximum)	CI+CP = 7 (> 6)
VS	3	WPA2/TKIP Wi-Fi, weakened/obsolete encryption
motivated external attacker, but physical access must be organised	2	wireless interception: skills/proximity required
Likelihood	2 (limited)	VS+CA = 5

Main impact: confidentiality of data in transit.

Risk 1 (tablet theft): full encryption of the tablet (and data); secure locked storage / locked locker instead of open access; strong authentication + MDM enabling remote lock/wipe and automatic purging.

Risk 2 (Wi-Fi interception): migrate to WPA2-AES (CCMP) or even WPA3, phasing out TKIP; end-to-end application-level encryption (TLS) for tablet↔server communications; dedicated/segmented Wi-Fi network (VLAN) with 802.1X authentication rather than a shared key.

Mission B2 - Digitisation of the loan offer

No. The procedure (password + SMS code) is multi-factor authentication, but ANSSI (doc B6.1) points out that multi-factor ≠ strong. Strong authentication relies on a robust cryptographic mechanism (SSH/PGP key pair, smart card...). However:

• the password is a weak factor;
• SMS is a vulnerable channel (interception, SIM swapping, redirection).

As neither factor is cryptographically robust, the authentication cannot be classified as strong.

From the ephemeral certificate srvdbapp.crt, the signature contrat.sig, the document contrat_test.pdf, and the original hash contrat.dgt:

1. Extract the public key from the certificate: openssl x509 -pubkey -noout -in srvdbapp.crt > srvdbapp.pem
2. Verify (decrypt) the signature with the public key → retrieve the signed hash: openssl rsautl -verify -in contrat.sig -pubin -inkey srvdbapp.pem -out verif.dgt
3. Compare the hash from the signature with the original hash: diff verif.dgt contrat.dgt

If diff returns nothing, the hashes are identical: the signature is authentic (the private key matches the certificate) and the document is intact (unmodified). openssl dgst -sha512 can also be recalculated on the PDF to confirm the hash.

1. Never click on a link or open an attachment without verifying the sender; CalédoBank never asks for credentials by email.
2. Check the sender's actual address and the URL (hover over the link, check domain caledobank.nc); watch out for spelling errors and a sense of urgency.
3. If in doubt, log in directly to the customer portal by typing the address yourself (not via the email) and report the suspicious message to the bank.

Mission B3 - Securing the DMZ (ANSSI recommendations)

a) The current architecture is inadequate: all exposed servers (proxy, reverse proxy/WAF, web, business applications, database, FTPS, NFS storage) are in a single 'flat' DMZ (192.168.134.0/24). However, ANSSI (PA-066) requires an external firewall (Internet↔DMZ) and an internal firewall (DMZ↔internal network), as well as separating services and data into distinct zones. Here, compromising a single server (e.g. web) grants access to the database on the same subnet - with no protocol break or segmentation. The DMZ is no longer 'expendable'.

b) The new infrastructure splits the DMZ into three tiers behind perimeter firewalls (ANSSI principle: services ≠ data): an attacker entering the external zone must cross a firewall to reach exposed services, then another to access data. Attack surface and propagation are significantly reduced, without adding hardware (reusing existing firewalls and the subnetted /24).

a) Distribution of the 7 virtual servers across the three zones:

Zone (subnet)	Assigned servers	Justification
External DMZ - relay services / protocol break 192.168.134.128/26	proxy server, reverse proxy / WAF	first exposed to the internet, providing filtering and protocol break
Intermediate DMZ - exposed services 192.168.134.64/26	web server, business application server, FTPS server	application services reachable via the WAF, with no direct contact with data
Internal DMZ - data 192.168.134.0/26	database server, NFS storage server	data accessible only by exposed services, never from the internet

b) Firewall operations

• Interface addressing ("last available IP" of each /26, excluding broadcast):
  • dmz1 interface (internal DMZ, …0/26): 192.168.134.62;
  • dmz2 interface (intermediate DMZ, …64/26): 192.168.134.126;
  • dmz3 interface (external DMZ, …128/26): 192.168.134.190. Each firewall thus hosts the gateway for its zone.
• Filtering rule principles (and not the rules themselves):
  • the external firewall only allows HTTP/HTTPS traffic from the internet to the external DMZ reverse proxy (everything else blocked);
  • from the relay to the intermediate DMZ, only open necessary application traffic (web, FTPS) after protocol break;
  • from the intermediate DMZ to the internal DMZ, only allow application → database / NFS traffic (specific ports), no direct internet → data access;
  • apply the principle of least privilege: any traffic not explicitly allowed is denied by default; no incoming traffic from the DMZ to the internal network beyond what is strictly necessary.